T48G with WIFI auto provision bug

[freak]

When you are using auto-provision with a T48G the phone looks for a file {MAC}.cfg on a tftp server where {MAC}.cfg is a file which matches the mac address of the ethernet adapter. This works great until you install a yealink wifi dongle. When you install the dongle the phone gets a new mac address from the dongle. Not only is the mac incorrect when you log into the web interface (It's still the wired mac address) it's also wrong on the phone menu system and worst of all the phone still uses the wired mac address to find it's .cfg file. This of course doesn't work at all. The firmware needs fixed to use the proper mac address of the wifi adapter. I've verified this using tcpdump.

[Jensen_Yealink]

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.
second, the difference of using wired or wifi dongle is the way to obtain the IP address.

regarding the issue, may i know if the phone obtain the IP address while using wifi dongle?

---

on the other hands, why you need the change of the MAC? May i know the type of the phone to obtained the IP address: static IP, DHCP? if using DHCP, how you set up your DHCP server?

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.

[freak]

(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.

It's confusing to someone setting up the phones but ok.

(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.

Not sure what you are trying to say here.

(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?

Yes the phone gets an ip address using the wifi dongle.

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

I don't need to change the mac. I need the phone to request the proper configuration file based on the mac address like any other phone does.

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

It's DHCP.

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

It's set up like any other dhcp server. But again the phone gets an ip address that is not the problem.

(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.

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?

[jolouis]

(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.

[freak]

(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.

I understand how it works quite well. Sure it could use some random number as long as the phone system knows about it. The phone system uses arp to get the mac to create the configuration file. What's the problem tftp request using the correct mac address? That's what every device I've ever seen does. You also need the mac if you want static dhcp addresses. The only way to get the actual mac on these phones is to arp them or look through the dhcp leases.

(BTW - the "preview post" button below doesn't work)

[Jensen_Yealink]

Hi Freak,

Your understanding of the flow of provisioning is correct.
But the generate of MAC.cfg file is based on the 12-digit MAC address of the phone(You can obtain it from the bar code on the back of the IP phone, the format is 001565xxxxxx, the previous six digit 001565 is the same to all Yealink phone). when the phone sends provision request, the MAC of the phone(001565xxxxxx) will contain in the request. So the phone system should recognise it and generate the MAC.cfg file.

[freak]

The phone system, Freepbx in this case, arps for the mac to create the config file. Arp will get the correct mac but the phone will use the incorrect mac. If you use the wifi dongle you cannot get the mac anywhere on the phone or in the web admin.

[Jensen_Yealink]

hi Freak,

the ARPS result is the physical address of the Wifi dongle, it is not the MAC of the Phone.
please kindly note that the MAC of the phone will not change at any time. so not matter what method the phone using(the wired or Wifi), the MAC.cfg file will keep the same file name.
the user-agent in request to provisioning will contain the MAC of the phone(wired or wifi with the same user-agent), refer to picture 3 in below Google drive.
i upload the testing on my side to Google drive.
https://drive.google.com/open?id=0B7RIYa...TM1a243S0U

[jolouis]

(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.

[freak]

(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.

In your example the phone is telling the provisioning server the mac address of an interface that it's not using. That is not accurate IMO. I can see it both ways but would rather that mac was accurate. I'll relent but it would be nice if at least you could find the mac of the wifi adapter in the web interface wifi section.