New install phones not populating

[raymond.norton]

18.0 (Build 31)

We performed a debian on-premise install a few months ago and are now working toward implementation. However,our snom D713 & D717 phones are not auto discovered. DNS checks out between voip devices ( Local DNS with proper A record). The server can reach the phones and ping the Internet by fqdn. A laptop on the voip network can ping the server and anything on the Internet by fqdn. We are able to manually provision the phones but the install consists of 700+ snom phones, so we are pretty motivated to get auto-provisioning working. Many of the phones are across L3 connections and have provisioned fine using DHCP Option 66, yet phones on the same vlan as the 3cx server will not provision correctly. Grabbing for straws we have tried Option 66 locally, but that has not worked.

I have grabbed a few logs from the web interface of a D713 and D717 and see they end with a dst error.

Including a snippet of the logs here and attaching the rest.

Jul  9 20:28:26.614 [INFO  ] PHN: OnImageLocation: Fetching FW URL: https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm done, result 404
Jul  9 20:28:26.615 [INFO  ] PHN: ProvisioningReplacements: URL >http://%7Bprov_host_path%7D/snomD713-firmware.htm<
Jul  9 20:28:26.617 [DEBUG0] PHN: Uri Replace >{prov_host_path}< in >http://%7Bprov_host_path%7D/snomD713-firmware.htm<
Jul  9 20:28:26.618 [DEBUG0] PHN: Uri Replaced result: >http://domain.com:5001/snomD713-firmware.htm<
Jul  9 20:28:26.620 [INFO  ] PHN: ProvisioningReplacements prov_host-step result: >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.620 [DEBUG0] PHN: Uri Replace >{mac}< in >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.620 [DEBUG0] PHN: Uri Replaced result: >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.621 [DEBUG0] PHN: Uri Replace >{phone_type}< in >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.621 [DEBUG0] PHN: Uri Replaced result: >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.621 [DEBUG0] PHN: Uri Replace >{firmware_version}< in >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.622 [DEBUG0] PHN: Uri Replaced result: >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.622 [DEBUG0] PHN: ReplaceQueryVariables in >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.623 [DEBUG0] PHN: ReplaceQueryVariables replaced: >https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm<
Jul  9 20:28:26.623 [INFO  ] PHN: OnImageLocation: uri[https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm] fallback uri[https://domain.com:5001/provisioning/subdir/snomD713-firmware.htm]Jul  9 20:28:27.373 [ALERT ] WEBCLIENT: request https://secure-provisioning.snom.com:443/snomD713/snomD713-firmware.htm stopped due to no response from server for con_id:3; resending with timeout 12000 ms
Jul  9 20:28:27.664 [INFO  ] PHN: ETH LINK STATUS: changed first time, not yet to propagate. Link: -1
Jul  9 20:28:28.668 [INFO  ] PHN: LAN port status: propagated (1)
Jul  9 20:28:30.000 [INFO  ] PHN: Setting system time: 1720556910 (Tue Jul  9 20:28:30 2024
)
Jul  9 20:28:30.002 [ERROR ] PHN: Wrong Dst values: .
Jul  9 20:28:30.010 [INFO  ] TOOLS: Going to write file ./snomconfig/config.xml.
Jul  9 20:28:30.014 [NOTICE] PHN: Std-Settings stored
Jul  9 20:28:30.000 [INFO  ] PHN: Setting system time: 1720556910 (Tue Jul  9 20:28:30 2024

 

[JohnS_3CX]

Hi Raymond,

Autodiscovery (or PnP) requires that the multicast messages of 224.0.1.75 in the phone VLAN can actually reach the PBX NIC.
- If this is not happening, they will not appear as new phones for you to assign them to their extensions under the "Phones" page
- If you have multiple NICs on the server (ie. an internet facing one, and a VLAN facing one) things may get more complicated regarding DNS, SIP, and provisioning. Let me know if this is the case.

As for the logs, they are only referencing the firmware, but it does seem to imply that they were able to provision otherwise how would they know the correct folder for fetching the firmware in the first place? If they provisioned you should be able to see the extension name on the screen even if it fails to register.

Meanwhile, V18 will reach EOL soon and since you are on the implementation stage it might be worth redeploying V20 now to avoid doing the work later. Your current work can be saved by taking a backup and restoring it on V20. Provisioning works differently here and it may simplify your configuration.

 

[raymond.norton]

upgraded to version 20, as recommended, and enabled ip igmp on the voip vlan but still having issues. Getting the following error, which is supposed to mean there is a problem with a custom template, but we are using the default: code: 30040
Provisioning file /provisioning/subdir/cfg0004138012345 requested by 10.x.x.x could not be generated

 

[JohnS_3CX]

Does it appear in the PnP page of V20 after enabling multicast and resetting the phone?

Getting the following error, which is supposed to mean there is a problem with a custom template, but we are using the default: code: 30040
Provisioning file /provisioning/subdir/cfg0004138012345 requested by 10.x.x.x could not be generated

That is the type of error you would also get if for example:
- You entered the wrong MAC (typo)
- The phone does not exist (can be the case if a custom template previously used is deleted)

 

[raymond.norton]

The error is in the logs. Phones still do not show up on their own. However, phones can be manually assigned successfully, and the firmware URL (without variables) works to update phones. We did not knowingly use a custom template. Is there a way to reset the config so the phantom custom template is not referenced? Also, we have not needed to enable IP igmp on other installs for 3CX. I did so after being advised to do so, but I need to clarify if it should be a simple enabling of igmp or if each switch should be configured with a static group 224.0.1.75.

 

[JohnS_3CX]

We have not needed to enable IP igmp on other installs for 3CX

clearly those ones had IGMP enabled, and the server was joined into the multicast group

We did not knowingly use a custom template

That was only one candidate explanation, there could be others like i mentioned earlier.

I need to clarify if it should be a simple enabling of igmp or if each switch should be configured with a static group

The phones and PBX should be on the same LAN and subnet, and whatever equipment makes this LAN up must all allow multicast to pass through.


Quick check
1. See that the server is joined into the multicast group first on the active LAN card that is in the same network as the phones.



2. Start capture on server and factory reset a phone (no Option 66 should be active on DHCP server that could bias the phones)

3. Check capture after phone boots, ip.addr==224.0.1.75 and see if the phone sent a PnP message that reached 3CX


If the server is joined, and no message arrived in the capture, you can be almost certain that the switches blocked the traffic.

 

[raymond.norton]

That part looks good:
eth0
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
link 33:33:ff:67:05:10
link 01:00:5e:00:01:4b
inet 224.0.1.75
inet 224.0.0.1
inet6 ff02::1:ff67:510
inet6 ff02::1
inet6 ff01::1

The phones and server are on the same VLAN/subnet. I did captures yesterday and saw 224.0.0.1 but not 1.75. This gives me some good info, and it seems the switches are the most probable issue. I will keep digging. Thanks for the info!