Solved H3 wont update firmware through 3CX Management.

[P4ul]

Good Afternoon All,

I have a self hosted 3CX using FQDN that resolves both locally and publicly, with IP phones on another VLAN / Subnet configured via an SBC. Using FQDN that resolves both locally and publicly. Still in the setup stages of deployment. I have a handful of Yealink T33G, T46U. All of these deployed, upgraded and provisioned correctly. Also have a couple of Fanvil H5W that worked.

I also have 300 Fanvil H3 phones that all came on firmware 2.10.2.6887. This is showing as unsupported as it would like me to upgrade the firmware to 2.14.0.7387.

I do not seem to be able to update the firmware from the 3CX management console. When I attempt to perform the upgrade the phone reboots / reprovisions but stays on the same firmware. I have attempted to reboot, and factory reset the phone and it still will not update.

I have searched the forum, and online a bit and can't see any known issues with this firmware. Anyone have any tips / advice.

I realise that I could probably upgrade these phones through the GUI but there are 300 of them, 295 of which are planning on being shipped straight to the customer.

 

[JohnS_3CX]

Hi @P4ul

As per our provisioning guides, we always recommend that the phones are upgraded to the latest firmware before they are provisioned for the first time. https://www.3cx.com/sip-phones/fanvil-h3/#h.7ls0w5vyhlnd

Sometimes you can get away with it and provision them first, and upgrade later, but this is not always doable and may lead to problems in extreme cases

The problem is most likely the fact that the phones are on a way older firmware than the one 3CX provides, hence the phone rejects the upgrade. It's quite common amongst phone manufacturers to prevent "large" jumps in versions and won't let you install the latest until you install the ones in between.

1. First confirm that the upgrade mechanism works, but manually updating a single H3 to v2.12.0.7275 via https://www.fanvil.com/Support/download/id/78.html

2. Then provision it, and try upgrading it automatically via 3CX to v2.14.0.7387

If you were successful then we have confirmed that upgrading via 3CX works, but the phones are rejecting the upgrade due to what I said earlier.

By the way, please don't tell me that you tried to upgrade all 300 at the same time That's an instant 8 gigabits of traffic right there!

 

[P4ul]

Hi @JohnS_3CX Thanks for the quick reply!

I tried upgrading to v2.12.0.7275 manually using the web UI of the phone, and that worked fine. I still cannot update the phone from v2.12.0.7275 to v2.14.0.7387 using the 3CX Management page.

I have found this and am not sure if it is relevant; it appears to be: Forum Post

If it is relevant could the system be modified (if only temporarily) to allow firmware updates over http, ruling out a cert issue?

I'm new to 3cx but will be looking to install multiple systems with around 300 phones, is the only process really to use the Web UI of every phone to perform firmware updates? This will add a lot of overhead. Do you know of anyway to script this at all?

No, I only have a couple of the phones here, the reset were planning on being sent straight to the customer.

Thanks Again!

 

[JohnS_3CX]

Ah yes thanks for reminding me, that is indeed 100% true. The devices are missing critical CA certificates and they cannot be upgraded over https so you are stuck now.

I can propose a method that should work, but it would be a good idea to test it before you deploy it at the customer.

What type of installation will the customer have, a local one, or SBC based installation with a cloud PBX?

 

[P4ul]

Hi John, This is an on premise system but it has multiple subnets due to security and volume of phones. The subnets each have an SBC on.

 

[JohnS_3CX]

Ok, we have a few options that could help in your case:

a) use DHCP Options, to instruct the phones at startup to go load their firmware from a TFTP server. Once they upgrade themselves, they will be ready to be provisioned normally via SBC. This would be the best choice if you can do it.

Or

b) Install a temporary PBX locally inside the phones VLAN, provision the phones there and upgrade them. When you are done upgrading, you must modify the template to include the provisioning URL of your production PBX. The phones will then be rebooted, they will reprovision to the production PBX, and you can then delete the temporary PBX

 

[P4ul]

John, I understand the TFTP option as it bypasses the HTTPS requirement for the root cert, thanks for this I will give it a try.

How would option B assist? Would it not just try HTTPS from the temporary PBX.

I appreciate you taking the time to answer these questions.

 

[JohnS_3CX]

In option B you use a temporary PBX, installed inside the VLAN of the phones.
You can then provision them using the "LAN" option instead of the "SBC" option (hence plain HTTP with no FQDN, it's just an IP address based URL) so you bypass the cert requirement entirely.

This method is a bit more convoluted, you should only use it if option A is not posible

 

[P4ul]

I see, I did not realize the phones default to HTTP when on a local network. Is this the same behavior for a Locally Routed network. For example direct connection through a firewall rather than through an SBC would result in HTTP connection?

 

[JohnS_3CX]

For example direct connection through a firewall rather than through an SBC would result in HTTP connection?

No, not exactly. It's all a matter of configuration choice. The system does not know whether there are firewalls involved or not. It just knows the difference between private address space, and public address space:

If you choose the LAN option the PBX generates a config file containing http://10.10.10.1:5000 for example

If you choose SBC/STUN it generates a file with https://mypbx.3cx.com:5001 for example

But be careful when using LAN mode: the PBX will only provide the config file on its plain http port (5000), and only to IP addresses in the RFC1918 address space.

If you try and route phones to the PBX coming from outside this address space, the config server will refuse to provide any config files. I would advise against doing any routing that "fakes" the true source IPs, it will cause problems and the system will be in an unsupported state.

I hope this was enough to give you an idea, let me know if you need any more clarifications!

 

[P4ul]

No, not exactly. It's all a matter of configuration choice. The system does not know whether there are firewalls involved or not. It just knows the difference between private address space, and public address space:

If you choose the LAN option the PBX generates a config file containing http://10.10.10.1:5000 for example

If you choose SBC/STUN it generates a file with https://mypbx.3cx.com:5001 for example

But be careful when using LAN mode: the PBX will only provide the config file on its plain http port (5000), and only to IP addresses in the RFC1918 address space.

If you try and route phones to the PBX coming from outside this address space, the config server will refuse to provide any config files. I would advise against doing any routing that "fakes" the true source IPs, it will cause problems and the system will be in an unsupported state.

I hope this was enough to give you an idea, let me know if you need any more clarifications!

 

[P4ul]

John, just wanted to say thanks for your help. I have managed to get this working using HTTP local access, even for the remote subnets.

I have also managed to get an account for the Fanvil FDMCS (FDPS and FDMS). This way the phones will turn on, be updated online, then receive the provisioning URL of the 3CX.

The latter I think is the Zero-Touch deployment I was looking for!

 

[JohnS_3CX]

Glad to hear it was all sorted then!