Yealink Firmware Time Out

Hello,

I have recently setup a cloud based FreePBX server. I am currently having problems upgrading a Yealink phone with the selected Firmware to the template assigned a user. I have done and checked the following:

  1. TFTP Server is enabled and running
  2. Firewall Rules, Extra Services Tab, TFTP is selected for Internet access
  3. Template being used has the correct model I am using selected, Yealink T42S, with firmware slot 1 selected, currently with 1.18. It says that the firmware is successfully installed and when I double check the directory (/tftpboot/yealink/1/t42s.rom) exists, among other files.

It successfully downloads the config file fine. When I tail the /var/log/messages, I see the following entries as the phone boots up:

May 19 01:24:30 freepbx in.tftpd[21642]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:32 freepbx in.tftpd[21647]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:34 freepbx in.tftpd[21651]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:38 freepbx in.tftpd[21676]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:40 freepbx in.tftpd[21681]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:42 freepbx in.tftpd[21686]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:45 freepbx in.tftpd[21642]: Client x.x.x.x timed out
May 19 01:24:46 freepbx in.tftpd[21694]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:47 freepbx in.tftpd[21647]: Client x.x.x.x timed out
May 19 01:24:48 freepbx in.tftpd[21698]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:49 freepbx in.tftpd[21651]: Client x.x.x.x timed out
May 19 01:24:50 freepbx in.tftpd[21703]: RRQ from x.x.x.x filename yealink/1/t42s.rom
May 19 01:24:53 freepbx in.tftpd[21676]: Client x.x.x.x timed out
May 19 01:24:55 freepbx in.tftpd[21681]: Client x.x.x.x timed out
May 19 01:24:57 freepbx in.tftpd[21686]: Client x.x.x.x timed out
May 19 01:25:01 freepbx in.tftpd[21694]: Client x.x.x.x timed out
May 19 01:25:03 freepbx in.tftpd[21698]: Client x.x.x.x timed out
May 19 01:25:05 freepbx in.tftpd[21703]: Client x.x.x.x timed out

I also noticed that after a few minutes, the TFTP service exits with code 0/success, so it just stops running for no reason.

I have a Sangoma phone that successfully installed it’s firmware update without issues, but this Yealink keeps getting hung up. I could just as easily update the firmware myself manually, but this should be updating automatically. Anything I should check or try?

Current Firmware Version on T42S: 66.83.0.35
Firmware 1.18 version: 66.84.0.15

FreePBX 14.0.11
Current Asterisk Version: 13.22.0

Thanks!

Don’t use tftp over the internet. Use http or https.

One could add that http is not much more secure than tftp. A badly formed guessable file name is actually more easily read over port 80. If you use either, have strict IP routing rules .

Ideally, one would limit access only to trusted hosts, but if you don’t have that luxury, then setting Apache credentials for http(s) provisioning is easily done with System Admin Pro. Repeated 401’s will then get banned by fail2ban.

1 Like

All of that is understandable. If I strictly use HTTPS, do I need to point the phones then to https://x.x.x.x:1443 or add /tftpboot at the end?

Are you referring to the Provisioning Protocols page for HTTP authentication? If I use that, can’t I just structure the Option 66 on the local network with the phones to use [username]:[password]@[host]:[port]?

Sorry can’t answer that, my guess is that the distro redirect rules combined with the distro firewall would not need too much massaging.

I was just qualifying generically.

Yep, that’s how it works.

So taking all of the advice into consideration here. I disabled the TFTP internet access, enabled HTTPS only authentication and updated my test network option 66 accordingly. The phone still wouldn’t update or even download the config at that point. Finally I broke down and manually updated the firmware to the current, and after that, it pulled the config and registered as expected. Must have been something with that particular firmware not allowing https authentication? Either way, it is working, and thanks to you guys, definitely more secure.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.