FreePBX 17 GA Issues Encountered

This is entirely dependent on the network and switching fabric and phones. For example on my test PBX which has around 20 extensions on it, 8 of them 100 miles away connected by an OpenSSL gateway-to-gateway VPN, all phones are on the default untagged networks and there is no packet loss and sound is clear on all extensions. In fact there are 3 separate routed networks involved.

At work on my production network that has 30 different subnets and 15 different remote sites on a private WAN, we use separate VLANS for SIP. However, none of the SIP VLANs are running any packet prioritization on the WAN (since the WAN is built on a non-deterministic metro ethernet fabric it’s not really possible to prioritize traffic) and yet there is no packet loss.

This is because all phones both on my test network and production network have jitter buffers. My production net is Cisco 8845 and 7821 phones the test network is a mixture of Cisco and Polycom phones plus a few other random phone manufacturers I experiment with from time to time. (In general, when someone posts here claiming it’s impossible to get a phone to work with FreePBX I like to prove them wrong, lol)

So the Dream Machine is routing between the untagged network and your VLAN, that is fine. As long as it is not doing any kind of packet filtering it should be OK. But for testing I would START with the Windows TFTP client on the SAME vlan as the PBX. Then I would move it to the phone VLAN for the second test. Note that it is NOT easy to put a Windows machine on a different VLAN because Microsoft left VLAN tagging to the Ethernet chipset vendor to implement in their drivers and not all of them have done so.

I have a laptop with a Intel(R) Ethernet Connection (6) I219-LM that allows vlan tagging from Windows but Microsot does not include the VLAN stuff in the driver it supplies. To load it you have to download:

https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html?v=t

Then you follow this video:

https://www.intel.com/content/www/us/en/support/articles/000056184/ethernet-products/gigabit-ethernet-controllers-up-to-2-5gbe.html

  1. Open Windows Powershell as administrator.

  2. Import the PROSet Powershell* module using this command: Import-Module -Name “C:\Program Files\Intel\Wired Networking\IntelNetCmdlets\IntelNetCmdlets”

  3. Type “Get-IntelNetAdapter” to display the name of your network adapter.

  4. Type “Add-IntelNetVLAN” to initiate the creation of a VLAN.

  5. PowerShell will prompt for VLAN ID

For tagged VLAN, type the desired VLAN ID.

For example: VLAN ID = 9

To create an untagged VLAN, type VLAN ID = 0

I have NOT done this myself so I can’t tell you if it works. The last time I tried fooling around with defining VLANs under Windows for testing I was using a laptop with a Realtek ethernet chip in it and with that one, you have to download a driver from Realtek then they have a GUI program that does it - and when I tried the laptop blue-screened. So I now do any testing requiring VLANS with a laptop running Linux which is far easier to and and remove vlan tagging from an interface.

I wouldn’t worry about figuring out why you can’t use the Windows tftp client to get files from the CentOS FPBX16 system. Sometimes we just gotta let go of old tech.

It isn’t that tftp isn’t as good as http. The reason that http and https are used for phone provisioning is that unlike tftp, they work better over the Internet. A decade ago I managed a number of large customer networks running Cisco devices across the United States, and one of the first times I tried firmware updating a router that was on the Eastern Seaboard from the West Coast, I used tftp. The copy took 3 hours and 2/3 of the packets didn’t make it through and were resent. I was stunned that the firmware file arrived intact and passed it’s internal crc checksum but it did and I rebooted the router on it and it did come back up. I was crossing my fingers on that one for sure.

So many phones today are sold for use with Cloud PBXes (Sangoma has one) that the cloud providers use https provisioning. This allows quick provisioning from the cloud and prevents an attacker from sniffing the SIP username and password. But on a local LAN network like yours, tftp provisioning is perfectly fine and just as good as http provisioning.

As for which is used first that’s phone dependent you will need to read the manual for the s500. I can tell you on the Polycoms they use tftp option 150 which allows a freeform URL to be used, and their newest firmware defaults to whatever 150 says, but if 150 is not handed out they will fall back to option 69 and use ftp provisioning from whatever server is specified in 69 on the latest firmware while the earlier firmware defaults to tftp provisioning. But as you may know Polycom renamed itself to Poly then was acquired by HP.

It is not Debian 17 it is Debian 12 and FreePBX 17

On Debian if you run the FreePBX17 install script it installs tftpd and it configures it plus it loads all of the latest Sangoma phone firmware into /tftpboot One thing it does NOT do is turn on verbosity. To do that you would edit this file like this:

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure --verbosity 7"

The verbosity integer is not explained in the manual but 7 seems to be high enough to generate usable logging. You can try higher values if you want.

Then you can look in /var/log/syslog and see what is going on, what files the phones are requesting, etc.

And like I said I had no problems getting the Windows tftp client to obtain phone config files and firmware from tftpd on Debian 12 so I know those are compatible.