I have had several yealink phones stop auto provisioning for no apparent reason. I verify the Mac.cfg file exists in /tftfboot/ and everything looks fine. If I manually configure the phone it works but I’m adding more phones and want to make sure they are going to work reliably.
I have about 50 other devices on the network wired & wireless all getting IP addresses just fine and the other 14 Yealink phones auto provision just fine. So far three of the phones just stop getting provisioned. If I configure them manually they work but they get reset often so its not a real long term fix.
I now have 5 phones that have stopped working now. I added the -vv (dash veevee) to the args and restarted the service. Then I rebooted the phone and I saw… nothing in the log.
Connecting to the tftp server manually and requesting a file works fine but when I reboot the phones I get nothing. I checked the TFTP option in my router/gateway config and it is fine.
PBX End Point Manager 2.10.3.
The latest firmware has been downloaded using EPM.
The Yealink phones have their own built-in syslog server that is very helpful in troubleshooting this kind of problem. In many cases I’ve had them fail to refresh their configs, only to find that they’ve done the auto Provision but detected the provisioning file to be invalid or incorrect and simply ignored it. If your TFTP logs aren’t showing any requests, it’s more likely that the Yealinks decided to use a higher priority AutoP method than DHCP/TFTP option 66.
So: 1) Check syslog on one of the not-working phones. Power up one of the phones, wait for about 1 minute after the phone finished booting (autoP is a lower priority service so it doesn’t run until after the rest of the SIP stuff is done).
Log into the phone’s web server using the “admin” account.
Go to “Upgrade”, then click on the “Advanced” section at the top of the page.
Under “Export System Log”, make sure type is set to “Local” (default), and hit the export button.
You’ll be prompted to save the syslog.tar file. Save it somewhere, and open it using either WinRAR (Windows) or TAR (Linux). Inside will be one or more files showing the full boot and running log of the phone.
Look for any entries that are marked with [AutoP]. They will tell you what the phone is trying to do… If you can’t figure it out, post the logs here and I can tell you (I’m very familiar at troubleshooting these phones).
Based on what you find in 1) above, you may discover that there is some other autoP option taking priority over your TFTP server. The syslog will tell you, but remember that Yealink phones follow this AutoP priority:
Zero Touch (Manually done on the phone at boot)
PnP Server (Multicast SIP messaging)
DHCP Custom option (configured on the Upgrade/Advanced page, telling the phone which DHCP option value it should be looking for)
DHCP option 66
DHCP option 43
AutoP configuration URL entered into web interface.
The phones process those methods in the order listed, and will stop trying once any of them are established. i.e. if you have DHCP custom option set to 150, and your DHCP server is sending out a DHCP option 150 value of “IHateYou”, the Yealink will get to Step 3, find the value, fail (assuming “IHateYou” is invalid on your network), and stop trying to Auto Provision.
I was reading this thread as I have a similar issue. Yealink phones that used to provision fine before now no longer do so. What I found (with the help of Rob’s instructions - thanks) was that where before the IP address of the phone server was enough to get the phones to pull the config using option 66, now for some reason, I can only assume its because of newer firmare, I had to put “tftp://{fully qualified domain name}” (I presume that "tftp://{ipaddress} would also work) to get the phone to pull the configs. I figured this out because if you look at the web interface from the phone, the default URL for auto provision is “http://yealink.etc…”