I have a motel customer, 5 AP’s, 1st has R52H AP WDS and SR9 AP WDS, 2nd is AP WDS, 3rd is connected to second via ethernet. 4th is RB411AR AP with SR9 Station WDS, 5th is connected to 4th via ethernet.
Someone messed with the cables, so I had to go onsite today. I took that opportunity to upgrade from 3.30 and 4.17 to 5.11. When I did none of the WDS links came back up. I downgraded the main AP (1st) and the SR9 in station WDS connected. The 2nd AP in AP Bridge WDS reconnected, but would not pass traffic. I downgraded the 2nd to 4.17 and got the motel back up and running.
Any tips? I’d prefer to get all back on v5, more mangle options. This is all 802.11b/g, 10mb internal bandwidth connected to a 1mb Internet service. Ethernet is not an option. There is no way to run the cables. I could upgrade the links, but dedicated links are overkill for this service and will be nearly impossible to justify to the owner when the older version of the software works great.
That’s strange. We have not run into this problem and we are currently running 5.14 on our one WDS install. Could it be something with the SR9 cards. I have never used the SR9 cards, we have always used the XR9.
Check the setting on the data rates tab under wireless interaces. Since router OS 5.8 when the introduced the new advanced algorithm for data rate selection the default is now advanced vice legacy. I have had problems with using the advanced algorithm with SR9 cards. Try setting it back to legacy to see if the clears the problem
I’ve got that system stable running 4.17 on two, 5.11 on the other three.
So far every device I have WDS on (not many mind you) has issues with v5. I need to tinker with it a bit in my office and see if I can reproduce the problem.
Same here, except I have been using WDS to set up a simple bridged backhaul mesh, and as of 5.x the configuration no longer works. Note that it happens with various radios (CM9, all the r52n variations, the OmniTik & SXT), and if either or both ends of the link is running 5.x (It works fine if both ends are running 4.x.)
I am having the same issue on 5.11. It gets large amounts of traffic over the WDS interfaces as soon as they register and doesnt allow me to access them any more, i have to access via Mac address and disable to WDS to get back in. Have tried upgrading to 5.16 and am still having the same issue.
This seems to work fine with two APS connected via WDS, though when i have one AP with more than one WDS interface this is when the issue arises.
When i downgrade to version 4.16 the issue is gone.
Any ideas what is causing this?
This does sound like the same problem I have been seeing. I never noticed whether it only happens when more than one interface uses WDS, but now that you mention it, looking at my network, the devices that “behave themselves” do have only one radio.
FWIW, this problem continues in 6.0beta2.
My support ticket is #2012032266000094. Feel free to drop MTsupport a line, and let them know that it isn’t just me!
we are unable to reproduce that large traffic problem when you start using WDS.
We need the simplest setup to reproduce this problem - that will help us to find the problem and fix.
Well, I have forwarded supout files from several devices while the packet storm was going on, so I’m not sure what else to do. I’m unable to not reproduce it!
Most recently, I set up two brand-new OmniTiks in our lab. Each has a bridge: rstp enabled, wlan1 and ether1-5 as ports, IP addresses on the same subnet. Connect ether1 from one of the OmniTiks to the rest of your network. Configure wlan1: ap-bridge, same freq & SSID, wds-mode=dynamic. Enable the wlan1 interfaces, WDS is established. At some point, either immediately or within two hours at most, the interfaces will show a sustained multi-megabit stream of broadcasts originating from the WDS interface, and spilling into the rest of your network.
Perhaps network traffic from another part of our network is triggering this problem, and unless you have similar input on your testing network, it won’t happen. Maybe it’s a probe from The Dude. Or maybe it comes from devices that have more than one WDS interface (e.g., three 433s, each with two ap-bridge radios linking to the two others, using three different channels). We have several such devices on our network, all running 4.17. Those are working fine, but maybe they generate broadcast traffic that triggers a storm when it reaches a WDS link running on the newer ROS?
FWIW, I do appreciate that MT is paying attention to this.
I’ve been able to reproduce this consistently with 2 RB751U-2HnD’s one as apbridge and the other as either apbridge or WDS slave, nothing else in the network. Usually only takes a few minutes for the storms to start.
I have the same exact problem on my pair of RB751U-2HnD running AP Bridge mode with WDS-Bridge. Tried all the firmware including V6Beta2 but storm still observed. Only firmware 4.17 is OK.
After trying several permutation of configurations, I managed to find a way to fix this. Under Bridge Port configuration, just enable Horizon settings on WDS and WLAN interface by defining a same number for both interfaces. Do note that this Horizon settings can only be enabled on one of the two WDS nodes else traffic will somehow not pass through.
Do note that this Horizon settings can only be enabled on one of the two WDS nodes else traffic will somehow not pass through.
And if we have devices with three radios in WDS mode, all ports on the same bridge, do you suppose we’ll still have cross-talk from the other two?
I’ll be experimenting with this today, but anything that will accelerate the process would be great. We need a solution to this ASAP, as our older hardware is aging out and we’re replacing it with new boards. I don’t want to have to put ROS 4.17 on RB435s.
I found this entry in the online manual. Evidently, data from one bridge port will not be forwarded to other bridge ports with the same “horizon” value.
Does this mean the problem is that data arriving on the wlan port (via the WDS interface) is being forwarded back out the WDS port (via the wlan interface), and vice-versa?
If so, should the wlan interface itself not be a port on the bridge, just the WDS interface (via the wds-default-bridge setting)?
If both are required, does this mean we have to just assign the same “horizon” values to each pair of wlan/WDS interfaces?
Must WDS be static in order to assign it a permanent horizon value?
Lots of questions, very few answers forthcoming without a tremendous amount of trial-and-error. I’ll be doing the latter today; hopefully someone else who has “been there, done that” can help me out with the former.
Please email to support@mikrotik.com and provide also the Mikrotik account name - we will add you access to pre-release of the newest RouterOS version.
