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
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.
Uldis,
I have seen you mention this in several threads. A few questions for you on it.
- What do you consider “very high distance”?
- 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.
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/t/upgraded-4-11-to-5-0rc7-no-2-4ghz-traffic/43609/1
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.