No mention of the STP bug on ePMP 2000 APs with Netonix switches. Any resoution there? We are still running 3.4.1 on our 2000's since they won't take 3.5 if they have STP enabled.
In addition, any SM with STP enabled in 3.4.1 and 3.5 will not re-acquire it's AP if the AP reboots. The SM must be rebooted for it to re-acquire an AP if STP is on.
I notice in the release notes > 'known problems' it says "AP drops Elevate radio connections when switching from Fixed to Flexible licencing mode".
Moving to flexible licencing was something I was hoping to move towards, but am wary after seeing this.
However, I thought it was the case that once licences are allocated to an AP in fixed mode they can't be reallocated to the flexible pool, so maybe its not such an issue (or am I wrong on this point).
No mention of the STP bug on ePMP 2000 APs with Netonix switches. Any resoution there? We are still running 3.4.1 on our 2000's since they won't take 3.5 if they have STP enabled.
In addition, any SM with STP enabled in 3.4.1 and 3.5 will not re-acquire it's AP if the AP reboots. The SM must be rebooted for it to re-acquire an AP if STP is on.
Chadwick,
Unfortunatelly we didn't have enough time to investigate issue with Netonix switch deeply and fix it in 3.5.1 Release where other critical fixes were delivered.
We are going to investigate it very soon and provide updates.
We didn't observe same issue with other switches except Netonix.
I notice in the release notes > 'known problems' it says "AP drops Elevate radio connections when switching from Fixed to Flexible licencing mode".
Moving to flexible licencing was something I was hoping to move towards, but am wary after seeing this.
However, I thought it was the case that once licences are allocated to an AP in fixed mode they can't be reallocated to the flexible pool, so maybe its not such an issue (or am I wrong on this point).
Hi,
It means Elevate radios are dropped only once after switching from Fixed to Flexible Licensing method and configuration saving.
They reconnects immediately after switching.
Then when Flexible Licensing is running no disconnects occur.
I upgraded one of our ePMP2000 AP's this morning and after the reboot lost all clients. A downgrade to V3.5 made no difference. Power cycling made no difference either.
After the device was factory reset on V3.5 and reconfigured clients reconnected. I upgraded it back to V3.5.1 and lost all clients again.
I then factory reset the configuration on V3.5.1 and clients reconnected. I noticed I had missed changing the bandwidth of the radio which was running on a 20Mhz channel so changed it to 40Mhz (the normal width) and lost clients again.
In the end I have downgraded it to V3.5, factory reset it and reconfigured. Seems stable now.
Have had no issues with our 1000 APs in 20 and 40 Mhz channel widths upgrading to 3.5.1 from 3.5. We are avoiding our 2000 APs due to the STP bug. We did accidentally take a bridge link of Force 180's to 3.5.1 (from 3.4.1) that had STP enabled and it took down our entire management VLAN with a broadcast storm due to STP flapping.
Does anyone else run ePMP 1000 APs with Mikrotik CRS switches, I am not sure what the problem is but every time I try to run 3.x software on the Accesspoints I get random disconnects on the Subscriber modules I am not sure what causes is, I do however know that reverting the AP to 2.6.2.1 resovles the connectivity issues.
Not being able to run 3.x software on my APs is becoming a real problem.
does anyone have a clues or knowledge that could help me out with this.
Does it run fine with other types of Mikrotik switches? Please check that you running firmware after 3.4.1(better use 3.5.1) to avoid a lot of broadcasts caused by MNDP.
It's nothing crucial, but did anyone else noticed timers jumping second up and down, or is it just on my devices?
I've seen the same thing on a few occasions - for example the clock will show 16:16:16 then immediately flicker to 16:16:15, then 16:16:17 and flicker to 16:16:16, etc. If the numbers were always ascending it wouldn't be so obvious, but it's definitely a two-seconds-forward-one-second-back kind of thing.
Wanted to mention something odd I just noticed - I'm logged into an SM on the network running 3.5.1, and LLDP is DISABLED, yet I keep getting log entries like:
Jan 22 16:18:15 customer name DEVICE-AGENT[23036]: rx_lldp: Received LLDP packet
Jan 22 16:18:15 customer name DEVICE-AGENT[23036]: LLDP: E4-8D-8C-3C-C0-99
With LLDP disabled on the SM, I didn't think I'd see log entries for received LLDP packets??
Device agent is a cnMaestro agent. It is using lldp to discover neighbouring cnPilot units. It doesn't send anything, but inspects received LLDP packets if it is cnPilot or not. In your case it is RouterBoard.
I feel we may be chasing the same issue...We have been upgrading to try and resolve SM drops as well as ocasionnally we have a couple of EPMP1000s connected to a CRS that will lose ping connectivity to SMs...After deregistering SM they will reassociate and work properly...We are running 3.5 currently and I was interested if 3.5.1 would help but it seems that no upgrade in the 3.x has resolved the issue...I have not tried downgrading to try and resolve but maybe you have found something that might help?
1. Please check that you have latest GPS firmware.
2. You can always increase the GPS holdoff timer to workaround the issue.
3. I know it sounds weird, but I would recommend to disconnect the GPS puck. In this case GPS reciever will use small built-in antenna patch. In most cases GPS is stuck due to high signal level of GSM/LTE transimitters and using lower gain build-in antenna patch helps to workaround the issue.