I recently started having issues with phone provisioning phones on our network using TFTP. I have the Firewall enabled and configured with the our local network zone configured as “Local,” and the TFTP service configured to allow “Local.”
Our endpoints are Grandstream GXP21xx. I captured the network traffic during a provisioning attempt on one of the phones, and it showed the TFTP read request to the correct IP address for the config file, but then immediately received an ICMP response “Destination unreachable (Port unreachable)”. I note that I then switched to HTTP and attempted a provisioning request, and it worked as expected.
Where should I go digging? Is there a specific log file in FreePBX where I should start?
TFTP is off by default on the FreePBX server. Unless you’ve turned it on (through the Sysadmin Module, for example), the service is off and will not deliver files from the TFTP boot directory.
TFTP is enabled in the Sysadmin module. Everything had been working as expected up until a few weeks ago. I thought the issue was related to a change that I made to Option 66 in DHCP and that I had resolved it (and maybe the first round was, indeed, a different issue; I can’t say for certain), but the phones are again having issues picking up their configurations, and it does not appear related to DHCP settings this time around.
For debugging, TFTP reports to /var/log/messages. Anything hinky in there?
Not sure I know what to be looking for, but I don’t see anything that seems to reference TFTP; most of what I see is related to PHP, similar to the following:
php: /sbin/iptables -w5 -W10000 -A fpbxregistrations -s [ipaddress] -j fpbxknownreg
Should I see successful attempts provisioning attempts in here, or just errors?
Everything that TFTP does should be getting reported in /var/log/messages. If you aren’t seeing TFTP messages in there, either the “-v” (verbose) option in the RC file for TFTP is not on, of TFTP isn’t actually getting enabled.
There are two ways to enable TFTP - the new way (through the SysAdmin module) or “old school” (by setting “disabled = off” in the rc config file).
If TFTP is enabled and you aren’t seeing the server serving up files, the problem is somewhere else.
Switch to HTTP provisioning if you are able to. It will make your life easier. So many routers are difficult with TFTP.
Something must have been in a weird state. I tried turning off TFTP through SysAdmin, and the interface seemed to hang. After a while I forced a refresh on the page, then turned TFTP back on. The log now has entries for TFTP. I don’t have time to investigate further at the moment, but will report back once I can confirm if my endpoints are properly receiving their configs.
Agreed that HTTP is preferred. My Grandstream endpoints are compatible with setting DHCP Option 66 to an HTTP value, but I am not certain about my other (mostly legacy) endpoints. I will need to do more investigation and testing before I can fully flip the switch.
Well, in between other things I have been periodically checking that log. It looks like TFTP just exited; not sure why. I am assuming that this should stay running?
xinetd: EXIT: tftp status=0 pid=26984 duration=1046(sec)
That’s normal - tftpd doesn’t run full time; only when it’s needed.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.