Anybody else having the same problem?
Rod

i have same problem , i downgrade back on 4.16

Thank you - glad it wasn't just me!
Rod
Givin' you "karma"

BTW - NV2 wireless package activated still screws up 802.11 2.4 AP clients! HUGE Latency!

Looking for the day I can have a NV2 bridge on the same board as an AP!!!!

4.17 release strangely working , besides that it have another bugs , and i not parsing it ,

Few hours ago I've upgraded P2P link to ROS 4.17 with NV2 package.
Works fine as expected, it's transparent bridge between office and warehouse.
Previously was ROS 4.13 with NV2 too, and uptime before upgrade was more than 80 days.

Regards,

I'm have several P-to-MP that I tried it on - would not connect when changed to NV2 but immediately connected when changed back to nStreme.

Any change in your configs?

rodneal/mishaM, please contact support about this problem and include the support output files.
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.

I'm using station wds - is there another mode to use 'cause I cannot get v4.17 or rc11 to connect after upgrade but v4.16 and rc10 will immediately connect on downgrad - but nsteme works fine on all!

"station bridge"??


Rod

I'm using station wds - is there another mode to use 'cause I cannot get v4.17 or rc11 to connect after upgrade but v4.16 and rc10 will immediately connect on downgrad - but nsteme works fine on all!

"station bridge"??


Rod

It should be able to connect using station-wds with all the wireless protocols. Check the log files why it didn't connect. Make sure the AP is using WDS.

rodneal/mishaM, please contact support about this problem and include the support output files.
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.

Uldis,

I have seen you mention this in several threads. A few questions for you on it.

1. What do you consider "very high distance"?
2. When do you guys plan on having a fix for it? Because it's not like your end users can just start canceling the service of existing clients that work with older versions of ROS. I know you guys have your plates pretty full right now but this problem has existed for months now, it isn't a minor bug in the software. It pretty well makes the new wireless package unusable for anyone wanting to use 802.11 wireless modes.

Hey Uldis,
They are straight upgrades to v4.17 from v4.16 - no changes - NV2 does not work. Downgrade and they work immediately
Rod

bump

I experienced a similar situation after upgrading to 5.0 RC11 and the fix was to disable Adaptive Noise Immunity. When enabled none of the clients would connect when using NV2. After turning off Adapative Noise Immunity they immediately connected.

****Update****

After Upgrading a radio from 4.16 to 4.17 and enabling the wireless test package...I had several clients that wouldn't reconnect. Once I reset the card and reconfigured it everyone connected. There were no other changes - this AP doesn't utilize nstreme or NV2.

Just throwing that out there as something to try.

Hope that helps.

I experienced a similar situation after upgrading to 5.0 RC11 and the fix was to disable Adaptive Noise Immunity. When enabled none of the clients would connect when using NV2. After turning off Adapative Noise Immunity they immediately connected.

****Update****

After Upgrading a radio from 4.16 to 4.17 and enabling the wireless test package...I had several clients that wouldn't reconnect. Once I reset the card and reconfigured it everyone connected. There were no other changes - this AP doesn't utilize nstreme or NV2.

Just throwing that out there as something to try.

Hope that helps.

Ok, does this ****Update**** message now mean you don't need to turn the Adaptive Noise Immunity off?
I am trying to figure out what, and if, the influence is of the ANI when NV2 package in use, or when nv2 protocol is even in use (=not the same!)

WirelessRudy:

I should have been more thorough in my testing. I tried to go back and recreate what I was experiencing with ANI disabled and enabled when using the NV2 package and I couldn't recreate it.

I tried to recreate the OP's scenario as well (upgrade from 4.16 to 4.17) on a tower that has a 2.4 client that is 9 miles out to no avail...everyone connected fine.

Regarding my "Update" message....I ran into a situation later in the day where, after upgrading the wireless package from 4.16 to 4.17, only 2 out of 10 clients connected...a scenario that seemed similar to the OP's. It didn't matter what changes I made, the "lost" clients wouldn't connect until I reset the card and reconfigured it.

So reseting the card may still be something to try.

Sorry for the confusion....

chadd, about that big distance I meant when the client is getting a lot higher distance as it has, for example if the client is located 3km away, the software detects approx 20 or 30km. Then that could cause problems. Usually when you remove them from the registration table they connect back and distance detects fine. If someone see this problem very often please email to support@mikrotik.com, we will could try to debug it and fix this problem.

BrinkNetworks, have you compared the wireless configuration on the wireless card before and after the reset of the wireless interface? Maybe you have support output file from the case when it can't connect and another file after the reconfiguration of the card?

After fighting with v4.17 working with any other version or even itself on another RB - I just discovered that if you change the WDS settings to "dynamic" instead of "static" it links right up and behaves beautifully!!
Why is this not listed any where in the NV2 wiki? I almost have the damn thing memorized!

Rod

BTW - legacy wireless for 2.4ghz connections still sucks when NV2 activated! Anyway can we have TWO wireless packages active at one time - one for 5.8 BH and the other for 2.4 AP???!!!

Read this
http://forum.mikrotik.com/viewtopic.php?f=1&t=48073
also problems when using b/g only
MT should done more testing but not in lab in real world

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.

Hey Uldis,
Sent in a request for rc12 but haven't gotten anything back - waiting up late here in the States for it. Will it be today?
Thank you,
Rod

Hey Uldis,
I'm reporting back - over all a huge improvement!! AP side seems to function well and the NV2 protocols seem to be up to speed. So far very happy!!! Now for the proviso: it could all change by the am after these connections settle in but I pretty sure this is not gonna be the case.

Several observations: 1. The ethernet ports seem a little unstable - had to take off "automatic" otherwise they will drop occasionally but left them at 100mb and full-duplex. (as I was writing this they dropped again - will continue to tweak to find solution)

2. still have to maintain the settings on the 802.11b/b 1-2 for b and 6-9-12 for g off

I'm using this version on all Routerboards from 112-800x - only had 2 lockups and a hard reboot fixed it - have not blown off any of the boards - yyyeeaaahhh - no tower climbs!

Keep my fingers crossed but very hopeful!
Rod

Rod,

Keep us updated on this and let us know how it is running.

Thanks,
Chadd

Hey Uldis,
I'm reporting back - over all a huge improvement!! AP side seems to function well and the NV2 protocols seem to be up to speed. So far very happy!!! Now for the proviso: it could all change by the am after these connections settle in but I pretty sure this is not gonna be the case.

Several observations: 1. The ethernet ports seem a little unstable - had to take off "automatic" otherwise they will drop occasionally but left them at 100mb and full-duplex. (as I was writing this they dropped again - will continue to tweak to find solution)

2. still have to maintain the settings on the 802.11b/b 1-2 for b and 6-9-12 for g off

I'm using this version on all Routerboards from 112-800x - only had 2 lockups and a hard reboot fixed it - have not blown off any of the boards - yyyeeaaahhh - no tower climbs!

Keep my fingers crossed but very hopeful!
Rod

my rb532A went bananas with 5.0rc11 only after 36 hours. So I'll gues I'll wait a bit to see how your experiance is the next day before I go for rc12....

rodneal, what kind of problems you had with ethernet link stability, could you give us more detailed info so we could look into that issue?

my rb532A went bananas with 5.0rc11 only after 36 hours. So I'll gues I'll wait a bit to see how your experiance is the next day before I go for rc12....

Installed 5.0rc12 on my 532A AP last Saturday and the board is till running and clients (ubntNS5/MT4.17/MT5.0rc11 mixture) are doing fine.
So far looks rc12 is ok for this board. (Previous 5.0 versions made it go bananas.)

Still have some problems with CCQ on a rb333 board running rc12 in a backhaul setup.

Hey All,
Reporting back on rc12 and the AP issues we have all had with previous versions with NV2 activated.

HARD ROCK STEADY!!! I am very happy to have this loaded on my global network.

The issue that I reported before about ethernet issues - still here and seems to be very unique per situation. Have three sites with this problem and solved one with a switch change out (older Netgear managed switches would drop with rc12 but not with v4.17 - easily fixed. The 2nd is a little more unique and that would be with a NSM5 bridge on the secondary ethernet port to a RB133 Lite AP with maybe 5 low-end customers connected - will pass customer traffic but not able to ping the routerboard but can log in with mac'ed winbox. The 3rd is a eth connection between a RB433 AP-Brg and RB133 900mhz AP - the connection would drop suddenly and disabling the port and re-abling would fix the problem (replaced cable several times - not fixed) - I have since bonded two eth ports and the problem has not resurfaced.

Otherwise this version rocks - NV2 is much better than nstreme and not near as noise sensitive. The AP's latency are back to where they belong.

Appreciate the work MT - Now I'm back in business!

Rod

great to know that is is working for you rodneal
could you write to support@mikrotik.com about those problems with Ethernet (what board yo used, what cable, what problem you experienced)?

my rb532A went bananas with 5.0rc11 only after 36 hours. So I'll gues I'll wait a bit to see how your experiance is the next day before I go for rc12....

Installed 5.0rc12 on my 532A AP last Saturday and the board is till running and clients (ubntNS5/MT4.17/MT5.0rc11 mixture) are doing fine.
So far looks rc12 is ok for this board. (Previous 5.0 versions made it go bananas.)

Still have some problems with CCQ on a rb333 board running rc12 in a backhaul setup.

So rc12 should work better on rb133c as previous 5.x as its mipsle.
Did you try that?

my rb532A went bananas with 5.0rc11 only after 36 hours. So I'll gues I'll wait a bit to see how your experiance is the next day before I go for rc12....

Installed 5.0rc12 on my 532A AP last Saturday and the board is till running and clients (ubntNS5/MT4.17/MT5.0rc11 mixture) are doing fine.
So far looks rc12 is ok for this board. (Previous 5.0 versions made it go bananas.)

Still have some problems with CCQ on a rb333 board running rc12 in a backhaul setup.

So rc12 should work better on rb133c as previous 5.x as its mipsle.
Did you try that?

Yes - I did - in fact on all legacy boards we have operational in our system - i.e., RB112 - 133 - 153 - 532. No outright crashes - just a lockup.
Works very well!
Rod

Hey - Thanks for the Karma - very cool! Rod

my rb532A went bananas with 5.0rc11 only after 36 hours. So I'll gues I'll wait a bit to see how your experiance is the next day before I go for rc12....

Installed 5.0rc12 on my 532A AP last Saturday and the board is till running and clients (ubntNS5/MT4.17/MT5.0rc11 mixture) are doing fine.
So far looks rc12 is ok for this board. (Previous 5.0 versions made it go bananas.)

Still have some problems with CCQ on a rb333 board running rc12 in a backhaul setup.

So rc12 should work better on rb133c as previous 5.x as its mipsle.
Did you try that?

I didn't have time to change many CPE boards. But indeed put it on two of these 133C boards and they give no problem. But that is not enough for me to accept all 133C and 112 board's issues will disappear with rc12. I'll know in a week or so when I have updated more boards..

I seem to have similar problem
When I enable NV2 on my uplink, the clients that do not have NVT setup on the AP, their TX/RX CCQ drop by half, and the pppoe connextions keeps on dropping.
When I switch of NV2 on the uplinks everything gets better but pppoe still keeps dropping?
This caused chaos in business hours.
V4.17

I seem to have similar problem
When I enable NV2 on my uplink, the clients that do not have NVT setup on the AP, their TX/RX CCQ drop by half, and the pppoe connextions keeps on dropping.
When I switch of NV2 on the uplinks everything gets better but pppoe still keeps dropping?
This caused chaos in business hours.
V4.17

contact support@mikrotik.com with the problem and also ask for the test release of v5.0