Please, take the tech-support file from the AP and one SM (if possible before rebooting).
It can be taken under /Tools/Backup&Restore/Backup Technical Support File and send it to me:
Andrii.Khyzhnyi[_at_]cambiumnetworks.com. We will investigate this case.
I have tried moving to long guard (even though these are all Force 300 SMs) and that did not fix it.
I have rebooted the AP. That did not fix it.
We have had customers reboot SMs, that does not fix it.
We downgraded the AP back to 4.3.2.1. That did not fix it.
As SMs attach to the AP, they will not get an IP (via DHCP), they stay connected for less than 3 minutes and then fall off the AP and keep repeating that. Our watchdog on the SM is set for 15 minutes before it reboots so this is not watchdog that is causing it to fall off the AP.
We are now sending a tech out to trouble shoot at anygry customer locations. I'll report back what, if anything, fixes it on site. I just hope the backdoor IP works and we can get these to re-attach.
Out of curiosity, are these 300-25s or 300-16s? There was a note a couple weeks back that 300-16s needed to have both banks upgraded to 4.4 or they could reboot. I wonder if you’re hitting something like that somehow?
These are a mix of 300-25's and 300-16's. Reboot is not related to the hardware, it was discovered to be related to ping watchdog due to a DHCP problem in 4.4
So far we haven't had any issues with upgrades using on-prem cnMaestro. Only upgraded 2 3000 APs with total 8 F300 SMs. Went from 4.3.2.1 to 4.4rc23 to 4.4. Also upgraded 6 2000 APs w/ about 40 F200 SMs from 3.5.6 to 4.4. Was planning to start doing more.
DFS on F300 AP/PTP!
Finally !
@Au Wireless wrote:I have tried moving to long guard (even though these are all Force 300 SMs) and that did not fix it.
I have rebooted the AP. That did not fix it.
We have had customers reboot SMs, that does not fix it.
We downgraded the AP back to 4.3.2.1. That did not fix it.
As SMs attach to the AP, they will not get an IP (via DHCP), they stay connected for less than 3 minutes and then fall off the AP and keep repeating that. Our watchdog on the SM is set for 15 minutes before it reboots so this is not watchdog that is causing it to fall off the AP.
We are now sending a tech out to trouble shoot at anygry customer locations. I'll report back what, if anything, fixes it on site. I just hope the backdoor IP works and we can get these to re-attach.
I have to admit that this is a software defect in 4.4 release. With separate management and "option 82" enabled DHCP requests are rejected by the server due to incorrect checksum. We are working on the fix and it will be delivered ASAP.
Temporary solution for this is to disable option82 on AP. Sorry for this inconvenience.
I haven't been keeping up much with the 4.x series except for PTP550. Most of our ePMP 1k and 2k gear is running 3.5.6. We have a number of sites with ePMP 2000 utilizing the uplink beamforming antenna. Is this fully supported on R4.4?
@George Skorup wrote:We have a number of sites with ePMP 2000 utilizing the uplink beamforming antenna. Is this fully supported on R4.4?
Yep!
If im using a 5 GHz Force 300-25 for a backhaul running TDD PTP (4.3.2.1) will I add latency to it if I update to 4.4 cuz it seems to just say TDD not TDD PTP?
I have all the following CPEs connected to a 2000 series AP and the all seem to be ignoring the MIR profile settings.
By seem, I mean when using the speedtest tool in the AP or in the CPE
Thoughts?
.
Same for me
Only have R4.4 on a couple APs so far for validation. Link test is reporting MIR speeds on them. But we're using RADIUS for speed profiles.
I finally swapped my first EPMP3k into production. Unfortunately, it's not going too well.
Clients:
Mix of N, and N elevates, etc.
I have Force200s and Elevate clients both rebooting, 5 or 6 clients total, ever since we swapped from the EPMP2K AP. I don't believe I have the same bug as the earlier post, we do not use DHCP on the management side. We do not have option-82 enabled.
The clients where stable previously, 4.4 on the EPMP2K.
The more I look at it, just logging into a client sometimes can cause it to reboot. The others do it by themselves.
Any advice?
I was able to login to the force200 that was rebooting, reflash the 4.4 firmware, and it's been stable since.
All that leaves is XW elevates radios connected to this sector. All but one of them are unstable (5-6 units). All of the XMs work as expected. At least a couple of the radios reboot when attempting to log in to them remotely, one of the radios just seems to disconnect/reconnect but at least it doesn't reboot every single time.
@NOW wrote:
I have all the following CPEs connected to a 2000 series AP and the all seem to be ignoring the MIR profile settings.
By seem, I mean when using the speedtest tool in the AP or in the CPE
Thoughts?
.
We will check and revert to you shortly.
Thank you.
@jbliley wrote:
If im using a 5 GHz Force 300-25 for a backhaul running TDD PTP (4.3.2.1) will I add latency to it if I update to 4.4 cuz it seems to just say TDD not TDD PTP?
TDD PTP is limited to 1 SM TDD.
Upgrade to 4.4 will not affect the latency, throughput or anything else.
Thank you.
hi
hello
is there any benefits using 4.4 on a 802.11n network with epmp 1000+2000 ?
thank you
@dcshobby wrote:
I tried rebooting a couple, then upgrading them again and it didn't work. These are XW devices, not XM.
~10% Throughput increase with Short GI configured.
+3 dBm sensitivity because of LDPC.
Comparing to 3.5.6.
Some new features like Trial Configuration are introduced form 802.11n products.
Thank you.
