FreePBX 17 GA Issues Encountered

After migrating to FreePBX 17, I have encountered the following issues that forced us to move back to 16 until they are addressed:

  1. Outbound routes no longer work when we prepend for us the 9 to separate calls between two outbound numbers on the same trunk at voip.ms
  2. when Sangoma phones (we use S500s) are hard reset, it no longer is able to get the configuration from the FreePBX server which is on the default VLAN but if it were able to get the configuration file, it would configure the S500s to a separate VOIP VLAN.

Our network has no switch ports specifically assigned to a VLANā€¦just use tagging to allow the router to pick up the tagged traffic whichever port is the source/destination. It works and is uncomplicated ā€“ at least in 16.

Two big issues that have caused us to move back to version 16 until they are fixed/addressed.

Thank you!

Neither of these would seem to be issues with FreePBX 17.

#1 - examine your outbound routes & add the 9 prefix where you want to use it as a selector.

#2 - isnā€™t described clearly but sounds like a network configuration issue. FreePBX does not configure your network.

My two observations are based on a backup and restore from v16 to v17. As such nothing has changed that would make the two observations not work. Network configuration has NOT changed. We are currently back on v16. On bullet #2, our phones are, again, able to get their provisioning configs from FreePBX 16 via tftp. They reboot and work again. Whereas, in v17, they arenā€™t able to get their configuration. What troubleshooting can we do?

Similarly, our phones outbound route for a second line which uses a prefix of ā€˜9ā€™ to signal to send the call to another outbound number, works again in v16. But itā€™s not working v17. I hope these help clarify.

For us, we feel that v17 has bugs but are open to keep trying to work out the bugs if Sangoma has new versions to try.

I have used backup/restore in the past to do migrations from one major version to the next. My experience is that backup/restore as a migration tool is not perfect; it should be considered a starting point. Some fix-up is always necessary. Especially in this case where the underlying OS and dependencies are all different, it would be my expectation that some clean-up is required.

Thanks for the reply. What do you reckon us to do in order to at least be able to our phones to provision assuming that tftp isnā€™t working.

OR, how do we go about address the prepending a ā€˜9ā€™ to properly fix the outbound routing issue?

Shouldnā€™t that be bugs that Sangoma should fix first? We are happy to test.

Make sure the S500 phones are on the latest firmware. Change from tftp to http or https registration, thatā€™s the preferred method.

Thank you for your reply.

Are you saying that tftp isnā€™t supported in v17? Therefore, we need to move to http/https with authentication?

@ozarktech Would you please advise on how to change these settingsā€¦is it from setting on the phone or DHCP so it works internally rather than portal.sangoma.com redirect server service?
Iā€™ve tried to simply set the following from FreePBX sysadmin module:

  1. turned off tftp
  2. set http authentication method to both and the password and username can be changed. I left it as it was.
    These didnā€™t work. Do I have to set the port, username and password from the S500 settings?

Note: that not all my phones are showing on portal.sangoma.com ā€“ even if your suggested that we use the Sangoma redirect service to point internally?

What about the issue with routing and prepending a ā€˜9ā€™ to route the calls to another outbound route?

Thank and look forward to your next post.

In FreePBX17, YOU not the FreePBX project, are responsible for building the operating install that FreePBX runs on. The install script does NOT do everything. For example it does not install a ftpd server which if you provision phones via ftp you will need.

You can check to see if tftpd is installed and active once the install script has finished for example:

tedm@phony:~$ dpkg -l | grep tftp
ii  tftpd-hpa                                        5.2+20150808-1.4                            amd64        HPA's tftp server
tedm@phony:~$

and if itā€™s not there then install it. However, when I ran the install script not only did it install /tftpboot it installed all the Sangoma firmware for their phones:

tedm@phony:/$ ls -l /tftpboot/sangoma/0
total 162392
drwxrwxrwx 2 root root     4096 Aug 18 09:40 8430
drwxrwxrwx 2 root root     4096 Aug 18 09:40 9430
-rw-r--r-- 1 root root  6078920 Apr 12  2021 fw100M.rom
-rw-r--r-- 1 root root  5893150 Apr 12  2021 fw100.rom
-rw-r--r-- 1 root root 16746726 Dec  2  2021 fw205.rom
-rw-r--r-- 1 root root  8866444 Dec  2  2021 fw206.rom
-rw-r--r-- 1 root root 16746704 Dec  2  2021 fw300.rom
-rw-r--r-- 1 root root  8856394 Dec  2  2021 fw305.rom
-rw-r--r-- 1 root root 16751342 Dec  2  2021 fw400.rom
-rw-r--r-- 1 root root 16751982 Dec  2  2021 fw405.rom
-rw-r--r-- 1 root root  8855840 Dec  2  2021 fw406.rom
-rw-r--r-- 1 root root 17974566 Dec  2  2021 fw500.rom
-rw-r--r-- 1 root root 12448902 Dec  2  2021 fw505.rom
-rw-r--r-- 1 root root 17933966 Dec  2  2021 fw700.rom
-rw-r--r-- 1 root root 12342670 Dec  2  2021 fw705.rom
-rwxrwxrwx 1 root root      230 Dec  8  2021 version
tedm@phony:/$

The following guide can help you get tftpd running on your FreePBX 17 but Iā€™d be concerned if you donā€™t have it already on there.

Just make sure that the tftp directory is set to the same location it is set in the FreePBX 16 distro and you sould be fine. And, obviously, copy the tftpboot directory from your FPBX16 to your FPBX17 system.

I believe that the backup/restore method is going to configure EPM to use the same method you are using in FPBX16 (which is TFTP)

Now as for firmware updates:

Unless you want additional features or your phones are misbehaving in some manner I would NOT do a phone firmware at the same time as a PBX update. Do one, then give it a month to shake out any problems then do the other that way if thereā€™s an issue you will know itā€™s either the firmware or the PBX since thats what will have changed.

However, in this case, since you are using Sangoma phones, if you were to run the EPM provisioner on the new FreePBX 17 it most likely would define the firmware in the phone config that FreePBX installs - which Iā€™d assume is the latest. In addition if the developers intended to change provisioning on the Sangoma phones from TFTP to HTTP they would have preloaded the Sangoma phone firmware that defaults to HTTP provisioning somewhere in /var/www/html and I cannot find any instance of the fw500.rom file in that directory structure on my 17 system. Since that firmware only exists in /tftpboot it seems clear that the FreePBX devs did not intend to make that change at this time.

From Apache web server config:

<VirtualHost *:84>
  RewriteEngine on
  RewriteRule (^\.|/\.) - [F]
  DocumentRoot /tftpboot/
</VirtualHost>

This configuration has been in place across several major versions now.

And your definition of a ā€˜hackā€™ is ?

pretty sure linux never had list before somebody cleverly abbreviated it to ls, Mostly us hackers/crackers learn quickly not to be known for TLDR on anything

feel free to figure out
:(){ :|: & };:

I see you never read Internetworking with TCP/IP by Douglas Comer, LOL

I saw no mention of your process regarding the assignment of IP addresses during the spinning up of your new FPBX 17 host. A possible issue with your #2 item is the IP address of your new FPBX 17 host. Is your new FPBX 17 host on a different IP address than the old FPBX 16 host? If so, then the Sangoma S500 phones are trying to tftp to the old IP address.

My preferred method for spinning up a new/replacement host is to temporarily assign it a new IP address for the build. When the build is complete, I will shutdown the old FPBX host (so that the IP addresses do not conflict), then change the IP address of the new host to the old host IP address. Make sure that the FPBX software is configured for the newly assigned (old host) IP address.

This process makes for the least number of outside configuration changes in my thinking. The outside configuration changes for a new IP address would begin with your gateway or router rules, Sangoma Portal for configuration server reroute, and possibly your SIP trunk provider(s) depending on your configuration. Keeping the same host IP address negates all of that.

Just my 2 cents.

2 Likes

Go to Admin>System Admin>Port Management and youā€™ll see the ports for HTTP provisioning.

In portal redirection, youā€™ll need to change the ip address / fqdn protocol from tftp to http or https. And then make sure the phone provisioning port is set to match the port setup under Port Management. Then factory reset the phone under web gui or by pressing Menu, then * key 3 times, then press and hold X button (Below the volume) for 10 seconds or so and the phone will restart and reset. Youā€™ll need to have to provisioning port allowed on your edge firewall as well. Iā€™ve seen portal redirection not work if the phones are on old firmware so If it doesnā€™t work, I would manually update the firmware and retest. They current firmware is a couple years old IIRC.

THanks @tmittelstaedt tmittelstaedt for the detailed help.
I have followed the instructions as much as I could.
I have confirmed that tftp is install and running as it has always been there. No need to install it as it was there already.
I have tarred the /tftpboot directory from FPBX16 and SCPā€™ed and untarred the file to the root directory /tftpboot in FPBX17.
I hard rebooted the Sangoma S500 phone and the phone is still not provisioning.
I am wondering where I would go check the tftpboot directory from my FPBX17 so it matches that in FPBX17.

Iā€™m willing to work on this issue as well as the the outstanding issue on why prepending ā€˜9ā€™ to an outgoing call doesnā€™t properly route the call as it did in FPBX16.

PS: before the S500 phones were hard reset in order to provision them on FPBX17, the phones worked flawlessly with FPBX17 because it was the config they got from FPBX16.

This is what Iā€™m seeing when the S500 tries to obtain the configuration file:

  1. gets it own IP address for the phone
  2. normally, Iā€™d see ā€œgetting configuration fileā€ but NOT in FPBX17
  3. reached out to 192.168.1.3 (the FPBX server)
  4. screens flashes
  5. ā€œgetting backgroundā€ meaning the wallpaper, which also doesnā€™t show in FBPX17
  6. waits a long time on ā€œwaiting for firmwareā€ and times out
  7. ends with no config under FPBX17.

So I suspect that while tftp is running on FPBX17 and while I manually moved over the files from directory /tftpboot from FPBX16, thereā€™s something thatā€™s not starting up on FPBX17 to allow the auto provisioning to work.

@afassas

My FPBX16 and FPBX17 are running on two separate VM instances. When I run FPBX17, I turnoff FPBX16. Similarly, I copy the MAC address from FPBX16 and paste it to the networking portion so to signal to the DHCP server to assign the same IP address when FPBX17 is running. FPBX16 is turned off before FPB17 is turn ON.

For this reason, logically, there is no way that tftpboot shouldnā€™t be handing out provisioning information to my Sangoma S500. To the phones, they are still being sent to the same IP address as set in the DHCP option 66 for where to find the tftp server.

You need to decouple the IP address(es) from dhcp, servers really need to have static addresses assigned as relying on MAC address assignment, especially if two might have claimed the same recently will always be a problem depending on the DHCP server.

(itā€™s all a matter of needing to be in control of . . . . everything :wink: )

1 Like

Am I missing something here?
the FPBX servers are all on static IP address.
If thereā€™s something I am missing about DHCP servers, please share.

Where is the DHCP service that gives your devices an IP telling them where to get their configuration from and what protocol are the phones asking for ?

(as a note , using tftpd is a huge security concern , consider something more secure.)

Thanks for your reply @dicko. The DHCP server is located locally and not accessible from the outside. Itā€™s basically our Ubiquitiā€™s DreamMachine running the Unifi Controller. Said controller is where is we set the pointer to the FPBX server, as shown in the screenshot.