ePMP Software Release 4.7.1 is now available

squirrely · January 15, 2024, 11:53am

We also get logs being trashed by message ‘Jan 15 10:16:54 xxxxxxxxxx creporterd: kernel process_crash… get_crash_data fail : -1’ by hundreds of lines. Very annoying to read stuff that actually matters. This has been happening for like a year now… We also see ‘Reason: 52 (INAC MISS TIMEOUT)’ a lot, also I’ve seen many 'Reason: 49 (INVALID SECURITY KEY)'s in a row and then it suddely connects, SM config untouched for ages. There’s no interference, air is quite clean, good SNRs… And few other problems that haven’t been solved and I really have no hope they will ever be…

Hafsteinn_Mar · January 16, 2024, 1:49pm

Did an update on some 3000L APs and 1000 clients to test out the firmware, I have the same errors in the log files, after 5 days connection is stable but log files, always 3 times every hour at minute 10, 30 and 50

Jan  9 16:50:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 16:30:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 16:10:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 15:50:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 15:30:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 15:10:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 14:50:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 14:30:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 14:10:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 13:50:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 13:44:35 AP02 kernel: [ 5703.819005] SM[00:04:56:f7:yy:yy] aid=3 associated with AP
Jan  9 13:30:29 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 13:10:28 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 12:50:28 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 12:30:28 AP02 creporterd: kernel process_crash... get_crash_data fail : -1
Jan  9 12:29:07 AP02 kernel: [ 1176.506911] SM[58:c1:7a:45:zz:zz] aid=2 associated with AP
Jan  9 12:18:50 AP02 kernel: [  558.648267] SM[58:c1:7a:44:xx:xx] aid=1 associated with AP
Jan  9 12:18:19 AP02 kernel: [  527.852281] SM[58:c1:7a:44:xx:xx] aid=1 disassociated. Reason: 48 (COMMUNICATION LOST)
Jan  9 12:10:42 AP02 kernel: [   71.387157] SM[58:c1:7a:44:xx:xx] aid=1 associated with AP
Jan  2 15:21:12 AP02 DEVICE-AGENT[6195]: SessionID unavailable, regenerating
Jan  2 15:21:02 AP02 snmpd[2725]: DFS status: N/A

SKYNET360 · January 18, 2024, 1:46pm

getting Failed to update the json file. when uploading to cnMaestro for AC FW only N works fine.

Fedor · January 18, 2024, 2:27pm

The entire bundle of ePMP software instead of separate images should be uploaded to cnMaestro on-premises.
https://support.cambiumnetworks.com/files/cnmaestrobundle/
Thanks.

ninedd · January 18, 2024, 7:50pm

We are also seeing that crash and disconnects. I didn’t think we were (and we ran RC-18 on this AP and I don’t think we saw any issues) but after 4 or 5 days, this happened 3 hours ago…

Jan 18 13:37:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 13:17:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 12:57:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 12:37:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 12:17:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 11:57:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 11:37:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 11:17:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 10:57:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 10:37:24 EPMP3K-40 creporterd: kernel process_crash… get_crash_data fail : -1
Jan 18 10:28:02 EPMP3K-40 kernel: [ 678.509080] SM[00:04:56:00:00:ad] aid=6 associated with AP
Jan 18 10:26:32 EPMP3K-40 kernel: [ 588.006018] SM[58:c1:7a:00:00:22] aid=13 associated with AP
Jan 18 10:26:25 EPMP3K-40 kernel: [ 581.426077] SM[00:04:56:00:00:f8] aid=9 associated with AP
Jan 18 10:26:12 EPMP3K-40 kernel: [ 568.259178] SM[00:04:56:00:00:ad] aid=6 disassociated. Reason: 48 (COMMUNICATION LOST)
Jan 18 10:25:12 EPMP3K-40 kernel: [ 507.722507] SM[58:c1:7a:00:00:22] aid=13 disassociated. Reason: 48 (COMMUNICATION LOST)
Jan 18 10:24:49 EPMP3K-40 kernel: [ 485.246913] SM[00:04:56:00:00:f8] aid=9 disassociated. Reason: 48 (COMMUNICATION LOST)

Fedor · January 19, 2024, 4:16am

It’s not a crash.
It is the message that says that there is no crash to be send to the remote server.
Thanks

PFR · January 19, 2024, 6:21am

This may not be a mistake, but:
a) looks like an error and a standard user (even an experienced one) interprets it as an error
b) it creates terrible garbage in the logs and in the debug section there is confusion instead of valuable information
I suggest providing a magic command that can turn off this message or in version 4.7.1.1 turn it off because it has a negative rather than a positive value.

ninedd · January 19, 2024, 6:39am

OK - maybe it’s unrelated, but also – in the logs I submitted, all the clients disconnected and then reconnected. This particular system is a 3000 AP (4x4) with 16 clients (all Force 300-25 and 300-16) and the Cambium 90 Degree 4x4 sector – and all the clients disassociated (or the AP crashed/rebooted maybe). Everyone’s Session Time was just 3 hours.

squirrely · January 19, 2024, 8:56am

So you say you’re not going to do anything about it?

Fedor · January 19, 2024, 12:10pm

Did I say that it’s not going to fixed?
I said that it doesn’t have any performance impact and of course it will be fixed in the next release.
Thanks

Bradley_O_Connor · January 31, 2024, 1:41pm

Good day one and all,

Trust you are all well,

Has anyone had any issues with the show commands with the new firmware.

All show commands seem to show this.

Soon as I downgrade back to 4.7.0 then all show commands work with no issues.

Sorry forgot to add this is the Force300-25L

Andrii_Telehin · February 1, 2024, 9:41am

Hi, Bradley

Many thanks for your cooperation!
Filed a bug, expect it to be fixed in the next Beta.

Best,
Andrii

JLLC · February 8, 2024, 4:32pm

While we’ve seen some bizarre issues with 4.7.1 related to ACS, Ethernet negotiation and GPS, we haven’t needed truck rolls. 2900 devices upgraded so far.

JLLC · February 8, 2024, 4:36pm

I haven’t seen the rebooting issue, but I’ve had negotiation problems above 100mbps IF smart detect is disabled for the ethernet adapter. Enable that option and we settle right at 1gbps no flaps. When the feature was introduced, it was more problematic, so we always disabled it. Just scripted for it to be enabled and every radio came back at gigabit.

Speedy · February 8, 2024, 4:55pm

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.

JLLC · February 8, 2024, 5:00pm

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.

dcshobby · February 8, 2024, 5:58pm

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.

aka · February 12, 2024, 1:40pm

Hi @dcshobby!

On which exactly radios do you see this?
Could you show Monitor >> Wireless screenshot on 4.7.1 or better PM me techupport file?

dcshobby · February 12, 2024, 8:10pm

I will work on screenshots and tech file to send over in the next day or two. We’re seeing this on Force 200 radios. I have not tested on any others.

gkounis · February 23, 2024, 2:15pm

Hello all
In the previous version, license was existing in the maintenance tab. With 4.7.1 is not there anymore? It is not necessary anymore

?