TFTP server not starting FreePBX 14 - HELP!

I was wondering why phones at a new 14 install weren’t provisioning - this is an ISO install, plain vanilla. Turns out TFTP isn’t running on reboot.

I have to manually start the service, and then everything works, phones provision.

Any idea why TFTP isn’t starting… and how do I go about fixing this without breaking anything?

My /etc/init.d looks dramatically different than 13:

drwxr-xr-x.  2 root root   108 Aug 10 14:22 .
drwxr-xr-x. 10 root root  4096 Jul  7 16:57 ..
-rwxr-xr-x   1 root root  4130 Jul 27 18:46 asterisk
-rwxr-xr-x.  1 root root  8496 Oct 12  2016 dahdi
-rwxr-xr-x.  1 root root   119 Jun  1 11:21 fail2ban
-rw-r--r--.  1 root root 15131 Sep 12  2016 functions
-rwxr-xr-x.  1 root root  2989 Sep 12  2016 netconsole
-rwxr-xr-x.  1 root root  6643 Sep 12  2016 network
-rw-r--r--.  1 root root  1160 May 25 21:22 README

I noticed this as well

[[email protected] log]# service xinetd status
Redirecting to /bin/systemctl status  xinetd.service
● xinetd.service - Xinetd A Powerful Replacement For Inetd
   Loaded: loaded (/usr/lib/systemd/system/xinetd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-08-14 18:12:57 UTC; 29min ago
 Main PID: 718 (xinetd)
   CGroup: /system.slice/xinetd.service
           └─718 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid

Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing discard
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing echo
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing echo
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing tcpmux
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing tftp
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing time
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: removing time
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: xinetd Version 2.3.15 started with libwrap loadavg labeled-networking options compiled in.
Aug 14 18:12:57 pbx.axcoadhesive.local xinetd[718]: Started working: 0 available services
Aug 14 18:12:57 pbx.axcoadhesive.local systemd[1]: Started Xinetd A Powerful Replacement For Inetd.

While I cannot answer your actual question I would suggest that you try out HTTP provisioning sometime as it works much smoother than TFTP and I’ve had less problems with it.

1 Like

TFTP doesn’t run all the time, but you should be able to enable it by updating the tftpd file in /etc/xinetd.d. Remember that the option is backwards )“disable = false” turns it on). Once you have that, xinetd will manage your TFTP sessions.

Why wouldn’t TFTP run all the time in a PBX environment? You need it to provision phones.

Every other FreePBX install (v13) the TFTP server was always running?!

Not in my experience. It’s always run out of xinetd (and inetd before that). In fact, that’s the primary reason for having xinetd installed. I’ve never seen a Unix-like system where TFTP ran all of the time. Of course, I could be wrong, I’ve only been doing this kind of work since the 1980s.

Well I don’t know as much as you, but how are phones supposed to provision via TFTP if they can’t receive the configs as the service isn’t running? Or am I missing something?

Xinetd starts an instance of TFTP for every request, thereby preventing a single instance from locking everyone else out. This is a more appropriate use of resources than trying to have one, and only one, TFTP running trying to respond to phone config (or other file transfer) requests.

IIRC, Commercial EPM resets the xinetd TFTP server to start on demand. If it isn’t, I think it’s a bug. We (the list) talked about this a couple of months ago and I recall that being the way forward.

Having TFTP enabled “be default” is not an industry best practice. We normally want the server disabled and turn it on “on purpose”, which is why I suggested updating the /etc/xinetd.d/TFTP file to “enable” the TFTP service so that you can get the software downloads working.

So we should not be using TFTP to provision phones any more? Re: “The way forward”

This is what I know:

  1. Reboot server
  2. Default a phone
  3. It can’t get a config via TFTP unless I start the service.
    ^^^^ This is normal behavior now

As a FreePBX user myself I expect it to just “work”… but maybe again I’m missing something in the change from 13 to 14 in terms of TFTP provisioning not being the way to go.

EDIT: I want to do it the “right” way, so please let me know what that is now.

No, we should not be turning the TFTP service on by default.

Setting the service up to work is perfectly reasonable and is a well-understood and necessary way to configure certain phones. Some phone manufacturers (Polycom comes to mind) prefer their customers use FTP or HTTP. IIRC, Sangoma prefers HTTP. Other manufacturers have other preferences, so the phone you are using will determine which protocol you are going to have to use.

The more I think about it, it might have been a Firewall thing instead of an EPM thing. Rob @xrobau would probably remember better since he’s one of the firewall gurus.

If you’re using TFTP, you are likely to be working by hand in the TFTPBOOT directory (EPM notwithstanding). Setting up the files needed in the TFTP directory isn’t always drag-and-drop and sometimes requires access through the CLI.

The TFTP service should be starting under xinetd. That’s why the config file for the service is in the /etc/xinetd.d/ directory. For whatever reason, your TFTP is disabled. Enable it (I think I’ve told you how twice now) and move on.

For security reasons we do not have TFTP start on boot as its very insecure. In sysadmin module in the PBX you can tell it to start under provionsing protocols.

@tonyclewis

That is the answer I was looking for. I get it.

Although the wiki does still state:
Define what Provision Server Protocol you want to use to have your phones receive their config files:
TFTP should be used when phones are local to the PBX, as it’s easy to use and requires no setup.

We bought all Sangoma equipment and don’t really have a need for the commercial sysadmin module. I suppose I have to buy it to turn TFTP on, or do it manually? Or look to other provisioning protocols?

Thanks to all who replied.

1 Like

I knew there was someplace where we tell the system to do that. Turns out it’s the sysadmin module.

Can you open a feature request to have us enable tftp by default on new installs and we can evaluate as we use to do that but in SNG7 that is not the detault

For anyone who stumbles upon this.

Use http provisioning.
Direct your option 66 to “http://yourpbxip:83” <- If using the default FreePBX config.

That’s what I did. Case closed.

Again thanks community for the help

2 Likes

@tonyclewis

No need. I worked around my issue via HTTP and since TFTP seems out of favor with you/Sangoma (again I get why) HTTP/HTTPS will be my new “default”

It’s just something new which why I was confused.

2 Likes

There is an hour and a half out of my life that I’ll never get back. Updating the lessons learned section in my FreePBX implementation documentation…

1 Like

vi /etc/xinetd.d/tftp.rpmnew

(Find the line that reads “disable = yes” and change it to “disable = no”)

:wq

systemctl restart xinetd.service

Not sure why it’s in tftp.rpmnew instead of just tftp; both files are there, but one was enabled and the other wasn’t. Whatever. They’re both enabled now, and it’s working again.

IMNSHO, if tftp is going to be disabled by default, then enabling it via the sysadmin GUI should not require the commercial version. Many phones don’t support http for various things (not only provisioning, but custom backgrounds, ringtones, etc.).

Hi!

From https://serverfault.com/questions/48776/why-do-i-have-rpmnew-file-after-an-update

If a file was installed as part of a rpm, it is a noreplace-config file (i.e. marked with the %config(noreplace) tag), you’ve edited the file afterwards and you now update the rpm then your old config file will stay in place (i.e. stay active) and the new config file (from the newer rpm) will be copied to disk with the .rpmnew suffix.

Have a nice day!

Nick

Well, the “tftp” file that didn’t get replaced was also not respected by the upgraded system, because it already said “disable = no” but tftp was most certainly not working until I made the edit to the tftp.rpmnew file. So maybe this is a bug in the FreeBSD SVN7 distro.

I deleted the tftp.rpmnew file (after determining that its contents were identical to the tftp file), restarted xinetd again, and it’s still working. So apparently all I really needed to do post-upgrade was delete the “rpmnew” file.