Unable to Provision any Phones

[Sembee]

Version 18.0 Update 9, build 20 using the 3CX supplied Debian install.

On our internal test system we have started to be unable to provision any phones. We use a random mix of devices - Yealink, some old Poly VVX 411, a few Fanvil, they all are failing.

Attempting to browse to the provisioning URL - http://xxx.3cx.uk/provisioning/random/mac.cfg - returns connection refused.

On the phones themselves the logs just say the server was unresponsive.

Nothing is logged within 3CX when looking at the logs in the dashboard.

Tried it with both internal IP address as well as the DNS - the DNS resolves to the correct host, rather than the external IP.

Rebooted the system.

Checked that NGINX is running, but I didn't think that covers port 5001. Management console is fine.

IP Address blacklist is empty, the browser test has been tried from multiple machines.

Anything else I can check?

Thanks.

 

[Alejandro_3CX]

Hi @Sembee, so the phones are in the same local LAN as the pbx? are you using PNP or RPS for provisioning?

Also what are the phone models? please check they are running the supported firmware

 

[SweetAction]

Version 18.0 Update 9, build 20 using the 3CX supplied Debian install.

On our internal test system we have started to be unable to provision any phones. We use a random mix of devices - Yealink, some old Poly VVX 411, a few Fanvil, they all are failing.

Attempting to browse to the provisioning URL - http://xxx.3cx.uk/provisioning/random/mac.cfg - returns connection refused.

On the phones themselves the logs just say the server was unresponsive.

Nothing is logged within 3CX when looking at the logs in the dashboard.

Tried it with both internal IP address as well as the DNS - the DNS resolves to the correct host, rather than the external IP.

Rebooted the system.

Checked that NGINX is running, but I didn't think that covers port 5001. Management console is fine.

IP Address blacklist is empty, the browser test has been tried from multiple machines.

Anything else I can check?

Thanks.

And what about if you hit the httpS version of the link?

 

[Sembee]

Both HTTP and HTTPS versions give the same connection refused.
The phone firmware is all up to date/supported as we reset these phones often for testing purposes - although the last time was before Christmas. Currently testing with a Poly VVX 411 and a Yealink T54W, can't find the Fanvil at the moment.
Everything is on the same LAN. No VLANs to get in the way.

 

[ivank]

@Sembee
From your description it seems like transport level error - i.e. no one is listening on the port.
What http, https ports have been selected on install?
Try links with port 5000 for http, port 5001 for https.
Also you could check which TCP ports are actually open on the PBX host.

 

[Sembee]

Port 5001 is open and working fine, as we can access the management console without issue.
The install is on the 3CX supplied Debian install, so it hasn't been touched. I stopped the nftables service, and there hasn't been any changes - port 5001 still works, but 5000 gives connection refused.

 

[SweetAction]

Port 5001 is open and working fine, as we can access the management console without issue.
The install is on the 3CX supplied Debian install, so it hasn't been touched. I stopped the nftables service, and there hasn't been any changes - port 5001 still works, but 5000 gives connection refused.

Ok, so provisioning using httpS works fine, as long as you use port 5001 (the https port).

What's the internal IP scheme these phones have? If the phones are not reaching out to the PBX over an RFC1918 address, nginx will block it.

 

[Sembee]

It worked over https using 5001, which makes me feel like an idiot, as I am sure I tried that combo before and it didn't work.
Is that now the expected behaviour? If so I will update our deployment documentation.

The phones were connecting from a 192.168.x.x address, as was the browser, so I don't think that was it.

 

[SweetAction]

It worked over https using 5001, which makes me feel like an idiot, as I am sure I tried that combo before and it didn't work.
Is that now the expected behaviour? If so I will update our deployment documentation.

The phones were connecting from a 192.168.x.x address, as was the browser, so I don't think that was it.

Doing it over https is always the best way to do it.

I now recall, you used to be able to do it over http, but that was either fully removed or restricted in an update (update 5 or 6 of v18). I think if you have the "SSL/SecureSIP Transport and Ciphers" disabled, http works, but it's been a while since I last looked at this. I remember the problem because Yealink didn't want to update the T46 (non s/u models) to support modern ciphers.

But HTTP won't work from outside the LAN.