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

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.

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.

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!!

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.

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

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.

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.

Thank you. 5.0rc5 works. Its stable compared to RC7. I am testing over the weekend. I can keep a bandwidth test max out without all the clients dropping. Thank you wildblue.

My bad that version is the worst.

rc7 I kinda get to work but not really stable. I will show what settings I am using later when not so busy.

Still noting about this problem....

I got 5.0rc7 working good. Here is my settings.
Gonly
20mhz channel
nv2
data rates check from 18-54
basic rates is 18 only
on fail retry is 150
hw retry is 15
period 10
cell 20
your welcome. This works. The only problem is sometimes everyone looses registration. I have a script that if all clients loose connection it disables the card and reenables it. Basicly the card crashs with nv2 only.

client side disabled rts and noise immunity or it will crash alot.

Mikrotik when will this be fixed!!! I am going into production fully with this product. Throughput is amazing but it crashes.

Your welcome everyone!
Routeros v 5.0rc7 I did not upgrade to latest because changelog did not say any fixes for it.

dallas, please contact support about this Nv2 problems as latest RouterOS versions are working fine with Nv2. Please try out RouterOS v5.0rc10.

I will try it out on one of our aps. I will update the clients and ap.

Still problem not resolved in 4.17
MT with R52hN set to b/g/n (same with b/g)
clients are with UBNT Loco
sadden all the clients disconnected
or there is no traffic
need to disable enable wlans but after 3-5 min same story
with wireless-4.17.npk all normal problem is in wireless-nv2.npk

5.0rc10 and rc 11 rocks. Been 2 weeks and stable. I use on all my aps.

Same here
tried 4.16 nv2, 4.17 nv2, 5.0rc10, pppoe connections drop and there's no traffic

disabled and enable makes some stations reassociate, but only few can authenticate and lot of packet loss

switching to wireless.npk package instead nv2, everything works correctly

Read this. It may help.

http://forum.mikrotik.com/viewtopic.php?f=1&t=48261

If you are running in straight 802.11b/g unless MT has fixed it with the latest release the new "nv2" wireless package behaves exactly as you mentioned.

Same here
tried 4.16 nv2, 4.17 nv2, 5.0rc10, pppoe connections drop and there's no traffic

disabled and enable makes some stations reassociate, but only few can authenticate and lot of packet loss

switching to wireless.npk package instead nv2, everything works correctly

I havent tried 4.17. I am stuck on 5.0rc10. I love all the features and it works.

please for those that do have problems with 2.4ghz links with nv2 package email to support with the support output file when this problem is happening.
Check if you have clients connected with very high distance, if yes try to remove it and check if it connects with good distance. If you have changed the hw-retries from the default value to 15, for example, then set that hw-retries value back to default value which is 7 or if it still doesn't help lower it to 4.

everyone that has problem with wireless stabilities (high ping times, big last-seen numbers, etc) when wireless-nv2 package enabled or v5.0rc installed, contact support@mikrotik.com for a new RouterOS v5.0rc12 which most probably will fix your problem.

I realised that setting distance to a fix value and disable calibration solves such a problem.
often some "hidden" or worse clients gets values like 57km and this makes ap to stop
"talking" with everyone connected. also when some other brand cpe than mtik are connected,
choose 802.11 as wireless protocol. it's kind of bug because it helps me every time
in my network so looks like calculation of distance is broken again....
it happens in 4.17 as is in 5.0rc11... yeaaaa

I realised that setting distance to a fix value and disable calibration solves such a problem.
often some "hidden" or worse clients gets values like 57km and this makes ap to stop
"talking" with everyone connected. also when some other brand cpe than mtik are connected,
choose 802.11 as wireless protocol. it's kind of bug because it helps me every time
in my network so looks like calculation of distance is broken again....
it happens in 4.17 as is in 5.0rc11... yeaaaa

write to support for a v5.0rc12 as it should work better if you have such clients with long distance values.