Fanvil voice vlan selection CDP / LLDP

[FoxtrotCharlie]

Hi,

Any chance to update for Fanvil template regarding CDP?

Due to over 3 years old incident (Fanvil X4G Latest Firmware Issues) Fanvil template disables CDP protocol on the phone regardless of LLDP setting. As far as I can understand Yealink template do not touch CDP at all, just leaves it as it was before provisioning. I am in process of evaluating replacements for our EoL Yealinks and had an issue a lot of fun with factory clean Fanvil phone connecting to proper voice vlan and then droping to untagged data vlan after provisioning. Most of my access switches are cisco so CDP is first choice (and LLDP adds lots of noise). I prefer not to customize templates. Also dhcp option 132 would require to add it to every data subnet I have and I have one location where it is impossible to setup.

So any chance old Fanvil/CDP sins will be forgotten? Also any input on "security" of voice vlan selection methods will be welcome?

Regards,
FC

 

[JohnS_3CX]

Hi FC,

Practically zero chance I'd say, it's a risky unknown. Knowingly flipping the switch may potentially cause 1000s of deployed phones around the world to misbehave.

Consider Yealink instead if this is a hard requirement.

 

[FoxtrotCharlie]

Thanks,

Seems temporary workaround will live forever, but i understand your concerns. CDP, however convenient, is not hard requirement and current Yealink entry level models are really "entry" in all the ways except price. Fanvils seems to have more bang for the buck but behave funny. For example when I configured my DHCP to provide vlan-id option only for devices matching Fanvil OUI phone as expected moved from untagged data vlan to tagged voice vlan but there it entered REQUEST-ACK-RELEASE loop. I have several data vlans to separate departments' networks and now have to include the same if <Fanvill_OUI> {option} for each of them instead of single class {if match <Fanvill_OUI>; option}
I've asked Fanvil about that dhcp loop, will see what they say.

Regards,
FC

 

[FoxtrotCharlie]

Hi,

as a follow up:

Fanvil suggested upgrading to latest fw available on their website that is 2.4.10.1. It did solve dhcp loop problem. V.2.4.10.1 release notes in bug fixes state:

2. Fix the problem that the X3S Pro phone under the special server will prompt that the IP cannot be obtained after obtaining the address

It does not directly relate to dhcp but symptoms were the same.

Side effect is it is displayed on Phones tab as X3SGPro (X3SG_Pro on fw 2.4.7.5) but when I try to Assign Ext. it is provisioned as generic X3 - it does not set up timezone and language properly.

Regards,
FC

 

[JohnS_3CX]

Side effect is it is displayed on Phones tab as X3SGPro (X3SG_Pro on fw 2.4.7.5) but when I try to Assign Ext. it is provisioned as generic X3 - it does not set up timezone and language properly.

Regards,
FC

That's because it reports the wrong user agent.

Unfortunately, this device is no longer compatible with 3CX when using this firmware version mentioned above.

Being detected as a plain X3 is a side effect of using the unsupported firmware.

 

[FoxtrotCharlie]

That's because it reports the wrong user agent.
[...]
Being detected as a plain X3 is a side effect of using the unsupported firmware.

Can you explain a little bit further? Does it mean that if 3cx adopts new firmware version it will no longer be detected as plain X3 or it means 2.4.10.1 firmware just reports wrong user agent so 3cx can't recognize it properly (thus preventing 3cx from adopting this firmware)?

Regards,
FC

 

[JohnS_3CX]

Can you please let me know

- the exact version of 3CX you are using
- the exact phone model (as seen on the label behind the device)
- whether you are using custom templates or not
- if the phone is provisioned as LAN or STUN/SBC

 

[FoxtrotCharlie]

3cx version: 18.0 Update5 (Build 418)
Exact phone model on a label: X3SG Pro
templates: no custom templates
phone provisioning: lan provisioning

Regards,
FC

 

[JohnS_3CX]

Ok so if you try adding a X3SG Pro on the above 3CX system version, but the device has the non-3CX firmware, then it is expected that you will end up with it being misdetected as a plain X3 (and generating the wrong config file too).

The difference between the two firmwares is quite likely the User Agent the phone sends. 3CX only understands this as a user agent: X3SP_Pro

If that firmware you added was anything else but the above, then that would be the reason it is detected wrongly, and that's why I said that the phone is no longer compatible with 3CX unless you revert it to the correct firmware we support.

I hope this makes things more clear!

 

[FoxtrotCharlie]

[...] 3CX only understands this as a user agent: X3SP_Pro

As I mentioned earlier fw 2.4.10.1 reported new unassigned phone as X3SGPro (missing underscore), so user agent mismatch is quite obvious (except I was not sure if UA includes also fw version - like in browsers - or just name). But my question was rather about the process of incorporating new firmwares into 3cx than problems with this exact instance (just out of curiosity, but I understand this might be company know-how).

On the other hand, Fanvil just recently contacted me with inquiry about support ticket I posted. When I confirmed their solution to upgrade fw to 2.4.10.1 solved problems with dhcp but due to problems with 3cx templates I had to revert back to 3cx provided version they stated they will contact 3cx directly. It seems they are willing to cooperate.

Anyway thanks for your explanations.

Regards,
FC

 

[JohnS_3CX]

But my question was rather about the process of incorporating new firmwares into 3cx than problems with this exact instance (just out of curiosity, but I understand this might be company know-how).

In theory, when the release their next 3CX-compatible version, it should contain a bunch of fixes/improvements and will have the correct user agent too.

As to what fixes end up going in the firmware, that's almost entirely up to the manufacturer than 3CX.