(12-13-2016 03:15 AM)Jensen Wrote:  Hi Freak,

first, I would like to share with you that the MAC showing on Yealink phone(Menu - Status - General - MAC) is permanent, Every phone with a Unique MAC address. So it is not relate with the method the phone obtained the IP address.

(12-13-2016 03:15 AM)Jensen Wrote:  second, the difference of using wired or wifi dongle is the way to obtain the IP address.

(12-13-2016 03:15 AM)Jensen Wrote:  regarding the issue, may i know if the phone obtain the IP address while using wifi dongle?

(12-13-2016 03:15 AM)Jensen Wrote:  on the other hands, why you need the change of the MAC?

(12-13-2016 03:15 AM)Jensen Wrote:  May i know the type of the phone to obtained the IP address: static IP, DHCP?

(12-13-2016 03:15 AM)Jensen Wrote:  if using DHCP, how you set up your DHCP server?

(12-13-2016 03:15 AM)Jensen Wrote:  for the auto provisioning, 1): the phone obtained the IP address, 2): the provisioning server is accessable for this IP 3): there are two files on the provisioning server for the phone(MAC.cfg, common.cfg). then the phone can autop normally.

(12-13-2016 01:27 PM)freak Wrote:  This is all correct. The problem is that when the phone system presumably arps the ip address, arp returns the mac address of the current used interface which now is the wifi interface. To explain this lets say the mac address of the built in ethernet adapter is 11111111 and lets say the mac address of the wifi adapter is 22222222. Arp returns 22222222 so a config file is created by the phone system that is called 22222222.cfg. Good so far. Now the phone boots. When it boots it looks at the tftp server and should be looking for a file called 22222222.cfg because that is the active interface. But's it's not. Instead it is looking for 11111111.cfg which is not created because it's not the active interface. Can you see the problem?

(12-13-2016 09:14 PM)jolouis Wrote:  

(12-13-2016 01:27 PM)freak Wrote:  This is all correct. The problem is that when the phone system presumably arps the ip address, arp returns the mac address of the current used interface which now is the wifi interface. To explain this lets say the mac address of the built in ethernet adapter is 11111111 and lets say the mac address of the wifi adapter is 22222222. Arp returns 22222222 so a config file is created by the phone system that is called 22222222.cfg. Good so far. Now the phone boots. When it boots it looks at the tftp server and should be looking for a file called 22222222.cfg because that is the active interface. But's it's not. Instead it is looking for 11111111.cfg which is not created because it's not the active interface. Can you see the problem?

I would argue that the real issue is not what the phone is doing but what the phone system is. Why on earth would a PBX try to arp a phone's IP?.. What if the phone's on another subnet? Or remote somewhere? etc... there are a million reasons this would fail.

I think you have a basic mis-understanding of how provisioning is supposed to work.Although the phones use the MAC address for their CFG requests, it's really just a way of ensuring each phone has a unique identifier.

In a typical provision setup, this is the flow:
1) Phone decides where to send provision requests. If you are not dealing with RPS, then the most typical example would be DHCP options. So let's assume that's the case, then:
a) Phone requests IP address from local DHCP server.
b) DHCP server replies with IP address for phone to use
c) DHCP server also supplies additional options telling phone about TFTP server address.
OR, you manually set a provisioning server address into the phone. Or you use PNP, or any number of other options. End point is that after this, the phone knows where to send the provision request to.

2) Phone sends initial provision request for general config file (y00000xx.cfg) file. Provisioning server sees this request, generates the file, replies back to the phone with it.

3) Phone then sends provision request for [mac].cfg config file. Once again provisioning server sees this request, generates or reads the file, and replies back to the phone with it.

4) Phone loads configs, updates, and hopefully registers with your PBX as a SIP Peer.

So at what point in this process, or in the future, do you ever need to do ARP or use the ARP tables? Again remember the phone is only using [mac].cfg as a convinience mechanism, it could just as easily have been [serialNumber].cfg or anything else... as long as it's a unique value for each phone you use it doesn't have any other real use.

(12-14-2016 02:15 PM)freak Wrote:  The phone system, Freepbx in this case, arps for the mac to create the config file.

(12-15-2016 02:10 PM)jolouis Wrote:  

(12-14-2016 02:15 PM)freak Wrote:  The phone system, Freepbx in this case, arps for the mac to create the config file.

Once again I would point out that doesn't make any sense, as the phone could be on another subnet or behind a NAT somewhere where the ARP would report incorrect information but the phone would work.

As Jensen pointed out, the phone sends it's MAC info in the Provisioning request itself... there is no reason for the server to try and guess the MAC based on the source IP address.

It would be like me saying "Hi, my name is Jim I'm from the 4th floor", and you replying "Hmm Jim you say... I think there's a Jim that works here... *check company directory* Oh yea, he's up on the 4th floor". I told you I was on the 4th floor in my opening statement (i.e. the phone tells the server it's MAC address as part of the provisioning request), but instead you ignore that information and instead try to guess based on other information which may or may not be accurate.