Are you using EAP-TTLS auth?
The issue we have is with EAP and is fairly easy to reproduce, both the AP and SMs say “INVALID SECURITY KEY”. It seems to me the SMs are trying to connect to the AP with WPA2 instead of EAP even if only EAP is selected on the configuration.
The issue seems to be on the SM because it’s happening even with 4.4.3 and 4.7.0 APs. Only fix is truck roll and downgrade.
I don’t have the ticket numbers as i cannot access Cambium Support (don’t know the reason, page remains blank) but we sent all the tech files, so it should have been straightforward to pinpoint the issue.
Yes, we do use EAP-TTLS. We’re in a small club man. The only other user I know using EAP is Douglas Generous.
This is the first release that F300s don’t just randomly stop forwarding traffic during the handshake. Approaching 4 years on my first ticket opened about it.
The EAP process is case sensitive on our deployment and we use the MAC as the UN. On some models of F300 (and some releases) the dashboard shows the MAC all uppercase and others show it all lower case. I wouldn’t expect that to impact you on an existing deployment though.
We’ve started upgrading some sectors and SMs to 4.7.1 and see a new issue compared to 4.6.2 and older.
Under Monitor-Wireless, the RSSI numbers are inaccurate for AP’s that the SM is not connected to. They’re off by 10-20 dB in most cases. So lets say the current AP1 it’s connected to is -65, a sector facing the same direction might show -82 in the scan but when I connect to AP2, the signal is better at -65 like the AP1 was. While connected to AP2, now AP1 shows a worse signal until you connect to it again. So the only accurate signal is the AP it’s actually connected to, not others that is only scanned the beacon of. It never used to behave like this in past version. It was always within 1-3 dB of what the signal is when actually connected to an AP.
This seems to be a new bug so hopefully Cambium can reproduce this and fix in a future version. We can’t trust the Monitor-Wireless page any longer with signal readings this inaccurate. This makes surveying sites much harder for our techs when doing installs so I’m hoping for a quick fix.
I am returning on this update. I have tried to restore the version 4.6.1 and the license came up again
I got to the 4.7.0.1 and the license is not there. Actually with no license the number of given frequencies is considerably lower to the version 4.7.1
One of the best feature of the latest version is the PtMP which I need the most on the F300C units.
Has anyone else noticed that effect?
Channel Bandwidth
Software Version
Frequency Range
20MHz
4.7.1
5480-5785
4.6.1
4920-6125
40MHz
4.7.1
5490-5775
4.6.1
4930-6115
80MHz
4.7.1
5510-5560
4.6.1
4950-6095
I suspect the lowest number of available frequencies has to do with the fact that I have not added a valid license to my access point.
Have these issues regarding the licensing and Monitor Wireless values been confirmed?
What about the issue of transmit frequency being changed to ACS from specific frequency?
We are hoping to start transitioning to 4.7.1 soon, but would like to verify what issues are present.
Does 4.7.1 address the code injection vulnerabilities shown in CVE-2023-6691 for Force 300-25 radios?
We just upgraded most of our ePMP network to 4.7.0.1 from 4.6.2, as we are admittedly hesitant to adopt new software until they’re shown to be stable by users in this forum as well as others.
I just posted this in the New Feature - Primary AP reconnect thread but since this feature was just introduced in this release, I figure reposting it here could spark more useful discussion:
This is a phenomenal feature but I have one issue and a way to hopefully improve it.
In my particular configuration, each AP has its own data VLAN with a unique subnet and DHCP server. I believe this is a very common configuration for security reasons.
When the SM fails over to the secondary AP (whether it be primary AP failure or just a DFS frequency change) the router behind it will not renew its DHCP lease until it times out (im using Mikrotik so its typically 10 min).
It would be very nice if the SM could signal to the router behind it to auto renew its DHCP lease. This way, the downtime for the end user would only be a matter of seconds. The only way to speed up the DHCP lease renewal is to completely reboot the SM which is a crude way of forcing it.
I think if the SM could trigger a very brief ethernet disconnect/reconnect, it would force the router to renew its lease and reduce the downtime dramatically. I dont think it should be too difficult to add.
If anyone else has a better idea or is experiencing the same issue, please feel free to chime in.
Well, you should probably rethink your network topology instead of asking Cambium to introduce features barely required by some small number of users. I’d rather not introduce features before more important shortcomings are fixed…
So are you telling me that all of your AP’s share the same data VLAN and that you have SM isolation disabled??? I would imagine my network topoology is very common. At least its what I gather from other netwrok engineers.
Is your network topology one big data VLAN for all CPE??
Its easy to criticize without posting details about your own network. Please grace us all with your infallible network knowledge.
Well, you should probably rethink your network topology instead of asking Cambium to introduce features barely required by some small number of users. I’d rather not introduce features before more important shortcomings are fixed…
You didnt need to be such a dick about it…but you were right. I was able to network around it.
But more importantly, asking Cambium to briefly disable the ethernet port to trigger a DHCP lease renewal is a pretty risky proposition.
Did You noticed that with 4.7.1 all full versions SM Force300-13 / Force300-16/ Force300-19 / Force300-25 need to use smart speed on Ethernet. When it is disabled then port speed is only 100Mbps ? We tested on all kinds of connection PTMP and PTP also with eptp mode. The problems is not existing on Force300 Light - 13L and 25L version.
The 1 Gbit connection is negotiated only when the smart speed is Enabled. We were using “Disabled smart speed” option as default in our devices, after firmware upgrade, all of them that we made upgrade (like more than 100) they are starts working on 100 Mbps only. You have two options Downgrade firmware or change this option for Enable. It’s not a secret that epmp3000 devices line, generally are very sensitive on noice on Ethernet port’s because of: high gain FM noise, LTE noise or etc. Because of this problem in all our network we are using smart speed as disabled. Sorry for the delay I’ve missed Your answer.
