Hello all,
Upgraded a 433ah from 4.11 to 5.0rc7, the xr5 backhaul link works fine, my xr5 with nv2 ptmp works fine, but my xr2 802.11b/g will not pass traffic. CPE’s associate but not traffic at all!
Any thoughts, please help quickly as this is a beta test with approx 40 custs. The 2.4ghz with standard 802.11b/g shouldnt have been affected, we are trying to beta nv2 on 5ghz.
Upgraded a 433ah from 4.11 to 5.0rc7, the xr5 backhaul link works fine, my xr5 with nv2 ptmp works fine
Can i ask what antenna you are using as i am using 4.16 - Rb433ah+XR5 with NV2 onto 16dbi Itelite 90° and have regular disconnects/reconnects one AP has hourly disconnects and another has maybe daily, have tried adjusting and trying different setting in wireless advanced (disconnect timeouts,calibration interval, etc) - no luck still regular dropouts but using a 23dbi AP on NV2 of the same brand is much more stable ???, had to switch back to 802.11 and no-disconnects?
Backhaul PTP remains at 3.30 and is rock solid with XR5
I have had the same experience with the NV2 package and standard 802.11b/g. I have sent supout files to MT a few times now and I have finally given up on it. It is something related to the AP side also because you can leave the NV2 package on the clients but roll the AP back to the standard wireless package and all is well again.
I have heard there are some people successfully using it in PtMP but I have not found the package to be stable when running either NV2 or 802.11 all I can come up with is that they must have some magic pixie dust 
I have heard there are some people successfully using it in PtMP but I have not found the package to be stable when running either NV2 or 802.11 all I can come up with is that they must have some magic pixie dust >
If this is true that some have a stable NV2, than it says to me Miktotik need to compile a list of equipment and config used by these people?
We also have the same problem, one RB433AH with approx 40 clients on 2.4GHz divided between 2 wireless interfaces and one RB600 with maybe 10 2.4GHz clients.
All 5GHz interfaces work fine but 2.4 randomly drops, PPPoE sessions fail and cannot reconnect. Eventually downgraded to 4.15 on standard wireless package I was so sick of it.
Sent supout files to MT but no response. Come on MT, at least I am not alone!
we had same problem with XR2 card!..downgrade to 4.9…works fine… There is a good Rule, Dont touch if it is working fine! 
I posted this the other day. Try it.
"Hey All,
I was just on here the other day flaming MT for not providing WISP with the proper tools on the AP side to truely give highend quality service to our customers. I STILL have some issue with this BUT I have finally discovered a work-around for my latency issues!
I hope this will help other providers with the sane problem and for you who know this and didn’t share it - SHAME ON YOU.
MT - there should be a place on this forum for quality work-arounds when your system does not provide complete support or at least a place for disclaimers!
To make my APs - globally and with high end loads 20-40 customers per XR2 card and 2 XR2 per RB433 - on the “Data Rates” Tab on the “Supported Rates B” I UNCHECKED the 1Mbps and 2Mbps boxes and left the other two checked. On the “Supported Rates A/G” I unchecked the 6Mbps and the 9Mbps boxes and left the others checked. On the “Basic Rates B” I ONLY checked the 5.5Mbps.
Once this happened - My AP latency IMMEDIATELY dropped from 1000ms+ latency under-load to 5-10ms latency.
This works on ALL versions of firmware and especially good on the newest RC version.
BTW - NV2 kicks ass! Not usable in all connections and still learning to do p-to-mp connections 'cause there are NO AVAILABLE EXAMPLE CONFIGS AND NOBODY and I mean NOBODY has responded to my requests for one! Including MT STAFF!
OK - I’m done being mad. Still all-in-all the MT system is the best!
BTW MT - had another board fail with that “you don’t have a legit License issue” during and upgrade - sending you the supout now.
These forums have saved my ass many a time so I hope I can give back occasionally without being too much of a distraction."
Thank you All,
Rod
I’m finding that a lot of APs have to have the “G” turned completely off and using only “B” and only “5.5 and 11”. They still need to be reset on a regular basis. They completely suck but at least I can keep my customers operational until I can transition to a different AP system.
Using RC7.
Use exclusively SR2 and XR2 on AP and SR5 and XR5 on BackHaul
The NV2 works great tho - so not completely moving away.
Rod
PS - it seems as if the the transmit works ok (not great) but the receive is trashed
PSS - v4.16 has same problem - in fact all versions past v3.30 / v3.28 have same problem to varying degrees
Thanks for the work around. I think that I will forgo using NV2 until it comes out of beta.
@Mikrotik - Any thoughts on this issue?
Thanks,
Adam
Customizing your data rates (and if using N all-around completely turning off all b/g rates, and customizing the HT rates) can get you better performance, fewer disconnects, and higher average CCQ, but its very dependent on the environment you are in (with respect to interference and noise).
Basically, the slower rates take longer to send a packet, providing more time for an interfering signal to appear. 802.11 typical response is to retransmit using an even slower rate, making that packet even more likely to be interfered with, IF competing transmissions are the cause of your problems. (and, you’re probably interfering with them, making them more likely to retransmit, with longer packets…).
So, you have to find the highest rate that works reliably when there is no interference, and then pick one or two of the next slower fallback rates, just in case (and to account for atmospheric (non-interference related) issues/variations over time; “rain fade”), and not let it use any slower ones beyond that.
However, this entire post is based on my experience tuning point to point links. Point to multipoint becomes vastly more complicated.
Basically, this overrides 802.11 normal mechanism, which assumes corrupt packets are due to inadequate signal strength for the modulation mode employed and current path conditions, rather than from someone else talking over you; now you’re forcing it to try to get the packets through “edgewise” so to speak, instead of talking slower and slower each time it repeats itself.
p.s. If restricting the data-rates, you have to make sure the clients and APs have compatible settings, or they will refuse to associate (last I checked, you get a log message about incompatible rates, maybe only if you have wireless logging on).
The only way we have found to solve these random PPPoE disconnects is to briefly change the wireless protocol between any/unspecified/802.11 then the sessions reconnect.
As i said this only affects 2.4Ghz clients to AP with v5rcxx or v4 using the nv2 wireless package.
Disabling and Re-enabling the AP interface seems to work also.
Mikrotik - have you managed to reproduce this problem? As I said it is present in Wireless nv2 package on v.4 and also in v.5xx
PPPoE sessions through wireless interface will remain connected for several days then all disconnect for no reason.
We want to use nv2 but cannot if this persists!!
we need remote access to such unit where we could do some debugging and the way to reproduce it.
Uldis - I can arrange for that if you contact me direct 
write to support@mikrotik.com
Just to let you know we’ve got 4.16 NV2 2.4Ghz AP with 45 clients UP and running and most of them got 1d 09h of wireless connect time (last disconnect was made by device change by administrator).
Only problem: I had to remove the WPA2 aes-ccm key cause station disconnect randomly with class 2 frame receive and the AP keeps reebooting randomly with kernel failure 
It tooks many hours to find the problem, but now it seems stable. All station use also 4.16 NV2 package. Transfert with client goes up to 40 Mbps UDP down and 20 Mbps UP !
about this Nv2 encryption problem, please send those support output files to support@mikrotik.com, that would help us to find that problem.
I am using 5.0rc7 and routeros gets kernel panic many times a day on every access point. I am going to try rc8.
I also have seen this problem..
Simple fix was not to downgrade but to switch the wireless protocol from NV2 to NSTREME on the interface…
Seems to be a problem with NV2. After a duration of time all clients will disconnect. I think they eventually reconnected but would not pass any traffic until the interface was disabled/enabled.
I’ve had this happen in two other circumstances with ROS 5.0rcX … The other two seem to be working reliably on ROS 5.0rc5 with NV2 enabled so I’m not sure what’s different between rc5 and rc7…
All AP’s are 2.4GHz, using a mix of hardware:
RB433 w/ SR2 – RC7 NSTREME
RB433 w/ R52H – RC5 NV2 working
RB133 w/ SR2 – RC5 NV2 working
I’ve yet to deploy 5.x on any of my 5.8GHz APs so I can’t confirm if this a problem with just 2.4GHz devices or not.