Loop avoidance in daisy chain with WDS bridges

Installing and Using OpenWrt
1

Supose the following situation, we have 3 devices connected in a Daisy chain topology via WDS (wireless bridges). The focus here goes about using the same radio the STA and AP interfaces, for example, all WDS STAs and WDS APs are in the 5 GHz band over a single radio per device.

Router (AP-U) <---O--- (STA-U) WB 1 (AP-U) <---O--- (STA-U) WB 2 (AP-U)

The arrow direction follows the logic of "connects to" (STA to AP), which is the same as the uplink direction. "-U" means "interface UP" and "-D" means "interface DOWN". The "O" means the STA "feels itself" connected and "X" if it feels disconnected.

So, we know that if the STA is not connected, the AP won't be irradiated. But what happens if, for example, the Router shuts down suddenly and comes back after... like 10 minutes? I will explain a step by step of the hypothetical problem I want to demystify (or not):

  1. The Router shuts down

Router (AP-D) <---O--- (STA-U) WB 1 (AP-U) <---O--- (STA-U) WB 2 (AP-U)

  1. WB 1 detects that there is no uplink connection available

Router (AP-D) <---X--- (STA-U) WB 1 (AP-U) <---O--- (STA-U) WB 2 (AP-U)

  1. WB 1 turn off its AP interface and starts scanning for a new AP/BSS to connect (starts to send probe requests in broadcast)

Router (AP-D) <---X--- (STA-U) WB 1 (AP-D) <---O--- (STA-U) WB 2 (AP-U)

  1. WB 2, which still not detects that its uplink connection is down, answers a probe request from WB1
  2. WB1 connects its STA to WB2's AP.

............................................-------------------------------O--------------------------v
Router (AP-D) <---X--- (STA-U) WB 1 (AP-D) <---O--- (STA-U) WB 2 (AP-U)

  1. WB1 turns on again its AP

............................................-------------------------------O--------------------------v
Router (AP-D) <---X--- (STA-U) WB 1 (AP-U) <---O--- (STA-U) WB 2 (AP-U)

  1. WB2' STA stills associated to WB1's AP because the steps 3 to 6 occured "too fast" to notice
  2. The Router boots normally.

............................................-------------------------------O--------------------------v
Router (AP-U) <---X--- (STA-U) WB 1 (AP-U) <---O--- (STA-U) WB 2 (AP-U)

So, we get a loop between WB 1 and WB 2 and it won't recover by itself. This is what i call the "Double Nelson" effect (aka "Full Nelson"), and I wonder if this scenario es really possible or not, and if doesn't, why.

Of course that if this could occur the most obvious method to avoid that is to configure statically the ".bssid" parameter via UCI in every STA to specify the BSSID to associate exclusivelly. But this has the drawback that you cannot move any device in a location which its backhaul should be another AP (you need to configure the new BSSID).

I hope you find this discussion interesting to enrich the information regarding the topic (WDS bridges and so...).

2

There are two possible replies here.

  1. Set the target BSSID explicitly on STA interfaces, as you have already mentioned. This way, wireless bridges will only connect to the main router.
  2. Set up a mesh network instead of WDS.

Here is a YouTube video about setting up the mesh network:

1 Like
3

Thanks, but just let me clarify that 802.11s is not an option here, I am interested in go deep with the knowledge of this WDS scenario.

And although it is not part of the topic, and because I am aware of the popularity of 802.11s mesh in this community , just in case I am going to answer in advance the question that I see coming from "why not 802.11s mesh".

The answer could be complex and I could do a really deep analysis but I will try to make it quicker just highlighting few points like:

  1. Interoperability. Since the existence of EasyMesh, WDS has had a standard association which was a blocker to interoperability, and is being WIDELY adopted in the industry.

  2. Use cases where the tree topology tends to be very stable, making it unnecessary to constantly evaluate routes when backhaul properties do not change frequently. This also allows the use of the WDS Infrastructure AP/STA approach where medium access is more efficient (less collision probabilities), than an AdHoc network, which means more bandwidth and specially better behaviour regarding latency and jitter.

  3. Interoperability with hybrid technologies (networks that combine links from various wired or wireless technologies)

  4. Implementation of LAN management via IEEE1905 and/or EasyMesh

The example of 3 devices via WiFi backhauling is just that, an example to show the potential issue in the most minimal setup needed, it is not representative of the whole use cases where this could be useful.

4

mac filter not solve this issue?

5

First of all I don't know If there is an issue, I exposed why I think that could be a chance to this to occur.

Next, I don't know which kind of filtering do you propose but for sure it won't work anyway. MAC filtering works at layer 2, but here we have a problem which involves the physical part.

That is why spanning tree won't help here also: STP can be enabled on any device but the only you will avoid is the loop in terms of the frame forwarding... the "Double Nelson" between the crossed association of WB 1 and WB 2 still could occur. There method to avoid this effect for sure involves a control/correction in the STA association of each device.

6

You can set main AP mac in client. I dont see why mesh may not work if you explicitly complain about too many wds nodes in range. Ie ideal olacement for mesh.

7

What do you mean? I already said that with "topology preservation" (.bssid fixed parameter) is a way for loop avoidance but has some drawbacks.

I do not complain about "too many wds nodes in range". About "Why mesh may not work" I gave 4 points for which it does not work for me, if you express yourself based on them I could clarify precisely what was not understood.

8

Sorry cant take them seriously

  1. false
  2. ok
  3. batman
  4. dont buy a car until it can fly to the moon ie irrelevant tech
9
  1. true . And the proof is in 802.11, hostapd/wpa_supplicant implementation and in the global market.

Just because you don't like a technology doesn't mean it's useless. Also, that neither will hide the reality: that a huge industry (most of ISPs), some developers, users and the WiFi Alliance itself don't share your opinion.

Yep, I have already realized that you have that limitation, so continuing to answer you is pointless. I will not do it anymore.

10

No4 has no open source implementation.

All your points equally disqualify wds and 11s

11

Of course, because WDS has issues with hardware interoperability - it is simply not reliable if you mix radios from different manufacturers due to border conditions being prevalent. Thus, any hardware maker is going to push WDS because it puts the golden handcuffs on the customer, once the customer sets up a few APs in WDS they are going to continue to buy the same make and model from the same manufacturer. And the Wireless Alliance is funded by the wifi radio makers, and the ISP's really don't give a tinker's damn since they have almost zero interest in wifi. Their thing is delivering internet service that's where they make their money, they lose money on answering questions from people like you "why isn't my Wonkulating Grokulator phone that I rooted not connecting to your wifi AP you gave me for free"

1 Like
12

I will also echo the following statement made in THIS thread:

Wi-Fi EasyMesh - Site Feedback and Other Questions - OpenWrt Forum

"@Pablomagno, if you would care to share some code or point to your repository"

I decided to use some Google-fu to investigate this more and what I found was:

Home - prpl Foundation

No explanation if this is just an overview of EasyMesh with the trademarked name EasyMesh (that the Wi-Fi Alliance owns BTW) removed or not. However, of interest on this page:

"prplOS (formerly prplWRT)"

prpl Foundation · GitLab

GitHub - prplfoundation/prplMesh-openwrt: This project has been replaced by prpl-feed (https://gitlab.com/prpl-foundation/prplwrt/feed-prpl) and prplMesh(https://gitlab.com/prpl-foundation/prplmesh/prplMesh) on gitlab.

From what I can suss out from all of this prplMesh essentially manipulates WDS to create a "sort of mesh" I guess.

But, the many locations in the github tremendously complicate understanding of it, and there seems to be no code at all up on that github tree that can be added into a typical OpenWRT build for an access point other than addin for lede which seems to be used for configuring it - but WHAT it's configuring is unknown.

In other words - the entire thrust of this effort seems incredibly similar to EVERYTHING I have read so far about EasyMesh - it's merely an attempt to get wifi radio chipset vendors to fork over money for some kind of mesh implementation. Code that can build on a real life wifi router does not seem to be supplied as there's no reference implementation of either system anywhere I can find, APIs don't seem to be supplied.

For ANYTHING like PrplMesh or EasyMesh or whatever other proprietary trademarked "mesh" implementation to get traction in the industry you MUST have a binary or firmware that can be downloaded, flashed to a half dozen access points, and deployed in a test environment.

It is easy to do this with IEEE802.11s The current version of OpenWRT comes with it included in the default load off the OpenWRT website. Anyone can take a bunch of APs from random thrift stores for very little money, flash them to OpenWRT, configure a 802.11s mesh, and distribute them through a building then run some radio tests with common phones, laptops, and other wifi clients, and see what happens. I'm sure that this is probably an assigned project in many college courses on wifi/network engineering.

But nothing like that is possible with EasyMesh unless you fork over many hundreds of dollars per AP and use the vendor's proprietary firmware. And the same is true with PrplMesh or any other kind of proprietary mesh solution - many of which these days are subscription based (like Cisco Meraki's) - so not only do you get the thousand dollar or so capital cost of acquiring the APs - you are now stuck forking over hundreds of dollars a month to keep it all running.

Pablomagno, when you started this prplmesh project 7 years ago what did you use for testing your initial project? OpenWRT, a free Open Source project. What are you using now? Ubuntu 18, Docker, and so on = all free OSS products. WORKING products that anyone can download and boot. You knew then the POWER of free, unencumbered, non-vendor-proprietary solutions. So why in heaven's name do you think that EasyMesh is going to win long term? It's proprietary. Even your own prplmesh has this to say:

" it is scoped as a reference implementation and will leave ample room for differentiation, for example for proprietary IP algorithms making intelligent decisions for the whole Multi-AP network."

Last I checked, "proprietary" is the OPPOSITE of Linux, of OpenWRT, of Ubuntu, of Docker - all things your "reference implementation" utterly depends on.

Do you NOT see how futile all this is?

Produce an OpenWRT community build of prplMesh, for a commonly available AP and post it on your multitude of github repositories and as icing on the cake, make a video or at least post some screenshots - proving how superior all this stuff is to IEEE802.11s

13

Yes it is useful to discuss the limitations of wds.

You have perfectly described the reasons why wds is not a good choice for a "daisy chain".

You clearly understand what the potential problem is.
It is a fundamental limitation to wds.

Of course you could develop your own wireless driver/kernel extensions to do what 802.11s can do and maybe improve on it. Make that development open source and targeted at OpenWrt and you will be met with enthusiasm by members of this Forum.

1 Like
14

Buddy, is time for you to be aware that WDS is standard, since MultiAP/EasyMesh v1, and is included since hostapd/wpa_supplicant since 2019 and since OpenWRT 19+.

This works pretty well out of the box, at the point that I have tested it between more than 40 EasyMesh "propietary" devices and OpenWRT and all of them worked by WDS without issue. Also worked perfectly fine getting its backhaul credentials via MultiAP-WPS (also incluided in hostapd/wpa_supplicant and OpenWRT since 2019)

Yes, you probably don't know what is MultiAP WDS (basically WDS with standard handshake) or multiAP WPS (basically WPS which is intended to send WiFi credentials which could be different to the SSID which is doing the WPS and standarized for EasyMesh)

Since you demostrated no interest in read 802.11, EasyMesh, WSC/WPS or IEEE1905 specifications, you probably will find this explained better here:

https://android.googlesource.com/platform/external/wpa_supplicant_8/+/refs/heads/main/hostapd/README-MULTI-AP

Or the first functional commit in hostapd repository:

https://w1.fi/cgit/hostap/commit/?id=9c06f0f6aed26c1628acaa74df0232dd7b345e9a

You have no idea what you are talking about. Most of ISPs are the main insterested in interoperability. You obviously haven't worked in any of them, nor are you familiar with the problems and challenges that ISPs face today.

Finally, just check this UCI configuration:

wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='FRONTHAUL_SSID'
wireless.default_radio1.encryption='psk2+ccmp'
wireless.default_radio1.key='FRONTHAUL PASSWORD'
wireless.default_radio1.bss_transition='1'
wireless.default_radio1.multi_ap='2' 
wireless.default_radio1.max_inactivity='40'
wireless.default_radio1.wps_pushbutton='1'
wireless.default_radio1.multi_ap_backhaul_ssid='BACKHAUL SSID'
wireless.default_radio1.multi_ap_backhaul_key='BACKHAUL PASSWORD'
wireless.wifinet5G_2=wifi-iface
wireless.wifinet5G_2.device='radio1'
wireless.wifinet5G_2.mode='ap'
wireless.wifinet5G_2.ssid='BACKHAUL SSID'
wireless.wifinet5G_2.encryption='psk2+ccmp'
wireless.wifinet5G_2.network='lan'
wireless.wifinet5G_2.key='BACKHAUL PASSWORD'
wireless.wifinet5G_2.ifname='bss2'
wireless.wifinet5G_2.bss_transition='1'
wireless.wifinet5G_2.multi_ap='1'
wireless.wifinet5G_2.hidden='1'
wireless.wifinet5G_3=wifi-iface
wireless.wifinet5G_3.device='radio1'
wireless.wifinet5G_3.mode='sta'
wireless.wifinet5G_3.ssid='BACKHAUL SSID'
wireless.wifinet5G_3.key='BACKHAUL PASSWORD'
wireless.wifinet5G_3.encryption='psk2+ccmp'
wireless.wifinet5G_3.network='lan'
wireless.wifinet5G_3.multi_ap='1'
wireless.wifinet5G_3.wps_pushbutton='1'

This is a radio configurated as (at the same time):

- MultiAP/EasyMesh compatible Fronthaul AP
- MultiAP/EasyMesh compatible Backhaul AP (WDS)
- MultiAP/EasyMesh compatible Backhaul STA (WDS)

Well... do you see any "wds" in that configurations? How could be this possible if I am saying that it is WDS? Well, is time to understand that WDS is standard since late 2018 and is time to understand that there are "new" (since 2019) hostapd/wpa_supplicant and OpenWRT configurations that allows to take advantage of that. And works in INTEROPERABILITY (definition: working between different software and hardware implementations) flawlessly

Tested between OpenWRT Mediatek and Qualcomm devices and Non-OpenwWRT BROADCOM :scream:, MediaTek and Qualcomm devices (all possible combinations).

15

Let me disagree: WDS is a good idea for a network with few hops (but it could be more than 2, so Daisy Chain is OK), where it's important to maximize airtime efficiency, capacity (Mbps), and, crucially, connection stability (minimizing packet loss, latency, and jitter). On the other hand, 802.11s networks may be a better option for networks with many hops, where capacity or connection stability isn't critical, and a decision is made to compromise on this in favor of more dynamic redundancies.

It is not a limitation of WDS, WDS does its part. To cover that effect should in charge of an upper layer. Saying that this is a fault of WDS is similar to say that not having ACK is a limitation of IP protocol. And that is why WDS is pretty clear, it just solve a precise L2 problem. But the telecommunications in the work in general needs the full OCI stack.

I don't believe that this should be done in driver level, since this should work at the same time with different wifi radios, chips and drivers coexisting in the same device. I think that the contention should be at hostapd/wpa_supplicant level maybe, or maybe a new deamon. I have tested some propietary implementations use standard WDS and avoid this effect, but I am not pretty sure at which levels their works in their software stack. The only I can say is that they wait until the backhaul STA is connected to begin to irradiate the backhaul AP (regarless in which radio are them).

This is just my point of view at the moment.

16

My first WDS network I setup was around 15 years ago I think, using (what is now considered) a couple antique WRT54Gs. It was in a warehouse where they had 1 ethernet drop on one side of the warehouse and they needed to use a wifi device on the other end - the signal could not reach.

That setup ran for around 5 years. In hindsight I probably should have told them to pay a wiring contractor to run an ethernet drop and put a second AP near where they wanted to use the wifi device. But I was younger and stupider and fell for the mesh marketing BS at that time.

I'm well aware of the limitations of WDS. It works fine in specific use case scenarios like the one I just outlined although a warehouse with an open ceiling is a stupid place for it since nobody cares if you run ethernet. But my experience is that it's not reliable when mixing chipset vendors since it's implemented in the radio chipset. It's also pointless when you can run Ethernet to all the locations APs can go to since it really appears to do nothing to assist moving wifi client associations from one AP to another.

Perhaps the chipset vendors have improved interoperability since the last time I messed with it around 3 years ago but there's a lot of older kit out there still in service.

I was sysadmin of an ISP from 1998 to 2011, Internet Partners, Inc.

ISPs make their money by buying bandwidth from larger networks and retailing it to individuals. Just like Costco makes money by buying a semi-truck full of toilet paper and selling it to individuals. Everything else that they do is a cost-sink, and loses money. That's why ever since ISP's came out they have eroded away at the value-adds. Time was for example Usenet News NNTP access was considered standard for an ISP but the ISPs made no money on it so they all ultimately stopped including it as part of the product offering.

I spent enough time in the field seeing what end users regarded as acceptable ways to connect to our circuits to know how ass-backwards some people will construct networking and seeing how much time it took to educate them and correct their nonsense they had setup to know how much of a cost sink and money loser that endpoint wifi is. The ISPs only engage in it because the customers would cancel their service otherwise and go to the next ISP instead of admitting they are stupid and needed to hire a 3rd party consultant. Most customers will take barely-adequate suboptimal crappy networking that barely works as long as they can bring up Amazon on their PeeCee and the ISPs have learned how to essentially provide the cheapest C-grade connectivity at the endpoint as a result - but they still lose money on it.

17

Well, it is time to update your knowledge regarding modern WDS o stop talking without knowing.

In the while, the only one harmed by remaining stubborn is you, who are missing out on using WDS to its full potential it has today.

Please stop this because you are not contributing in the motivation of the topic. And this kind of spam only contributes to discourage others to contribute.

Thanks.

18

I will repeat what I said earlier:

Produce an OpenWRT community build of prplMesh, for a commonly available AP and post it on your multitude of github repositories and as icing on the cake, make a video or at least post some screenshots - proving how superior all this stuff is to IEEE802.11s

I apologize if my posts here discouraged you to contribute a community build of OpenWRT with prplmesh. I look forward to seeing such a build appear on one of your github repos.

19

I already implemented EasyMesh from scratch, without PRPL, and works with just OpenWRT (0% propietary software) and in interoperability (connected to Agent/Controllers from Broadcom's implementations, PRPL, Huawei and Mediatek at least).

But this topic does not goes about why I did that, why my code is not public (not at the moment), or about you telling me what should I do with my efforts and time. Also this topic does not go about you complaining against WDS or ISPs like they have killed your mother.

This topic goes about a pretty specific issue and this is the last time I will repeat it to you.

21

So you are mad I told you to implement it so we could all look at it and judge for ourselves if your arguments are correct, yet you went ahead and implemented it anyway. If you honestly did implement it - then why are you mad I told you to do so?

You sir do not make any sense. It is easy to create a theory and prove it's better. If IEEE802.11s was also theoretical then nobody would have a problem with an argument about whether 11s was better than EasyMesh.

But 11s isn't theoretical, and it is free. EasyMesh isn't free it only comes in new expensive APs.

In the market, the only time a proprietary standard beats an open standard is when there is a tremendously compelling and obvious better use case for the proprietary solution. This is why for example we setup Samba fileservers for Windows clients instead of using the NFS client that's now in Windows Pro, because Samba serves ALL the windows clients, 7, 8, home and pro. The NFS client is only in Pro. Yet still the pressure was such that ultimately the open standard -NFS -was put into Windows. (grudgingly)

As for WDS you have not proven at all that I'm complaining about WDS. When I used it, it worked fine. For years. I don't use it now because it's limited and has problems the #1 was that different makers radio chipsets sometimes were not reliable in WDS. Talking about problems WDS has is NOT complaining about it. It is merely stating factually that there's problems with it. The fact that you haven't seen those problems in no way negates the fact I have or that others have. Talking about how ISPs operate is also, once more, not complaining about ISPs. It is merely stating facts about how they operate and their financial motivations - which don't always align with customers motivations.

It may be different where you live but where I live the only ISPs that offer customer premise mesh wifi APs charge subscription fees for them. Thus they have a financial interest in making those mesh wifi protocols proprietary which is why I think that they like EasyMesh - because as you say on your website, some parts of it are not standardized they are vendor-determined, which is a recipe for breaking interoperability. If a competing vendor selling EasyMesh wanted to cause problems with your OpenWRT EasyMesh then they would just change those unstandardized parts and it would break interoperability.

An ISP selling subscriptions for 10 mesh APs does not want a customer adding an 11th node for free. They want them paying them for another node.