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