Fixed an issue preventing Mac-Telnet from operating on ePMP1000/2000 and Force180/190/200 radios.
ACG-15901
All
Fixed abnormal increases in CPU usage.
ACG-15809
All
Fixed the UI to accurately reflect the status of Option 66.
ACG-15786
All
Fixed a discrepancy where the PPPoE connection was established, but the PPPoE Mode Status incorrectly showed as disabled.
ACG-15715
All
Fixed that device names remain consistent after applying a cnMaestro template (requires cnMaestro v5.2.0 or newer).
ACG-15508
All
Resolved an issue where Subscriber Modules (SMs) with the Primary AP Reconnect feature enabled couldn’t pass traffic after failing over to a secondary AP with different Data VLAN configurations.
AXG-11363
All
Fixed occurrences of frames with invalid MAC addresses (40:00:40:xx:xx:xx) appearing on ePMP device interfaces.
AXG-11263
All
Fixed the Mac-Telnet feature functions correctly when the SM is configured in NAT mode.
AXG-11118
All
Fixed the issues preventing the OOKLA Speed Test from working through a VPLS tunnel.
AXG-10986
All
Fixed the Watchdog feature to operate correctly with the default configuration.
AXG-10907
All
Fixed the issue where the GPS Antenna Status was displayed as N/A.
AXG-10885
All
Fixed packet loss issues (ping and TCP) occurring after radar detection and subsequent channel switching.
AXG-10847
All
Fixed an issue where SMs configured with MIR profiles could experience random disconnections from the AP.
AXG-10707
All
Enabled GPS Sync functionality in AP TDD PTP mode for F4600C devices.
AXG-10501
All
Fixed rare occurrences of random disconnects with reasons such as AP INITIATED DISCONNECT or INVALID SECURITY KEY.
AXG-8321
All
Fixed the Watchdog’s Ethernet restart function affects the AUX port as intended.
AXG-7090
All
Fixed the issue Disable Ethernet option was missing on APs.
AXG-6953
All
Fixed system crashes with the signature Assertion arq_tx_packet_timeout.c:148 (arqtx_to_pkt_add+0x1c0/0x2c0 [tdd_arq]).
AXG-11571
All
Fixed an issue where the SM could not obtain an IP address from the DHCP server when STP was enabled.
AXG-11682
All
Fixed an issue where the software upgrade via URL failed on SMs when STP was enabled.
AXG-11496
All
Fixed a crash with the signature Crash _HTCPipeIndicateSendComplete + 0x28.
AXG-11493
All
Fixed a crash with the signature Assertion failed tlv_type == CAMB_HTT_PPDU_STATS_USR_COMPLTN_COMMON_TLV.
AXG-11093
All
Fixed a crash with the signature Crash camb_dp_gather_ppdu_timeout_check_peer, which could occur in Flexible mode with MU-MIMO enabled.
AXG-11814
All
Fixed the issue where F300 SM failed to reconnect to ePMP 4500s APs after reconfiguring the frequency carrier with a 40 MHz bandwidth.
Flexible Licensing is disabled in firmware and is not supported.
Does this release fix the issue where the AP->Monitor->Wireless table would randomly show SMs with 0% DL Capacity that I thought someone else reported was there in the latest betas?
Is it the same during/after WLT? On my setup it gets blue as soon as I run some traffic. It is momentary indication. If SM is idle for a long time it can drift to zeros.
PPPoE seems to be broken in 5.10.0 (on AX, I haven’t confirmed whether or not AC is affected yet). If the PPPoE session drops, it doesn’t seem to ever re-connect. I confirmed 5.10.0-RC36 also does this, but it looks like RC35 might not be affected (most of the 5.10.0 final and RC36 clients on the AP weren’t working, but there were a couple on RC35 that were still working, but there were a couple of others working as well, so that could be a coincidence).
For added context, I had this happen on a tower that had some backhaul issues because of storm damage, so it probably was getting significant packet loss, but PPPoE did reconnect on the clients as soon as I rebooted them, so it’s possible that it’s just giving up after too many connection attempts fail, or something like that.
Unfortunately, the release notes don’t provide full clarity. The asymmetric feature can only be enabled on e4k AP’s. e3k SM’s connecting to an e4k AP using backwards compatibility mode that have asymmetric feature enabled will ONLY connect at the full channel width… NOT at the reduced uplink channel width.
See this post for guidance on asymmetric features and use cases:
So, unless I’m doing something wrong - we have a Backhaul using a Force300 Master to a Force300 Slave which we’re trying 5.10.0 on, and it seems like we need to have ‘Backwards Compatibility’ turned on in the AP configuration for a Force 300 to communicate with a Force 300? It appears that if we don’t, the SM/Slave reports “Failed - SM has no allocation on AP”
This will be a poor report (I won’t be able to download or send in the tech support files) but in our graphs, I’m seeing outages on our Force 400c link with 5.10.0, and the link uptimes show that the link is disconnecting occasionally (Gap dropping to Zero at 19:40). FWIW, this 400c link had it’s Spectrum Analyzer left on… which historically does seem to cause weirdness, and but since turning it off, we still see the same unlink-relink happening. This is a poor report because no, I’m not certain if this was or wasn’t happening with 5.9.2 and No, I havent yet tried downgrading.
Signals are -53 – SNR is 44 – radio uptime is 9 days (since upgrading to 5.10.0) but the link uptime is 44 minutes.
This problem for the 400C device in each new firmware, after the test, you have to roll back to version 5.4.2 where the work is stable, the data provided support, but all the conversations ended in that we have problems in our network, after such statements I stopped with them, but only I observe how users complain and re -send technical information.
Last night we updated our Cambium 4625 point-to-point backbone links to the new 5.10.0 firmware (April release), and the results were disastrous.Before the update, the links were performing normally with local ping latencies of around ~0.5 ms and a link capacity close to 900 Mbps.After updating to 5.10.0, we started seeing high and unstable latencies between 1 ms and 70 ms, even when pinging locally, along with significant packet loss.Link capacity also dropped dramatically from ~900 Mbps down to only ~130 Mbps.
We had to roll back to 5.9.0, and immediately everything returned to normal.
Is there any technical clarification regarding this version?Will there be a hotfix soon?At the moment, I would strongly advise caution before upgrading production links to 5.10.0.
by any chance did you grab tchsupport files while on 5.10.0?
Do you run any kind of MPLS, VPLS, EoIP or any other kind of traffic adding overhead?
In general I have positive reports regarding 5.10.0 release. But sometimes it does not work for some costumers. I would like to investigate why it does not work exactly for you.
Please, PM me if we can have a remote session to upgrade the link back to 5.10 and isolate the issue.
Starting having the same issue with ours this morning (4600c). Sounds similar… for 5-10 minutes, latency is 1-2ms… then it would spike to 70-300ms for a few minutes and then get better again. I had applied 5.10 around 9 days ago so I’m not sure what changed. I’m digging around trying to figure this out now, but I think I might downgrade at this point.
