To WDS or Adhoc with speed in consideration?

I have two APs each having two radios. Trying to decide if I should go with a WDS configuration or a point 2 point adhoc dedicating a radio in each AP for backhaul for speed. Anyone with experience in these scenarios able to point me in an optimized direction? Great appreciation.

To elaborate, the AP I'm attempting to use as the "back haul to" is in dumb AP mode on one radio. The other radio it has is free to use to as I wish. Not sure if being in dumb AP mode would impact attempting a WDS or adhoc configuration.

I don't see anything that would speak against using WDS/ 4addr.

sorry @slh I'm not following you on the 4addr comment.

WDS as a term isn't specified, there are multiple -incompatible- implementations for this. The (only) one supported by the mainline linux kernel (read OpenWrt) is called 4addr.

1 Like

Back haul to this AP:
MikroTik RBM33G
Architecture: MediaTek MT7621 ver:1 eco:3
Firmware Version: OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.020.41695-6f6641d)
Kernel Version: 4.14.95

Radios:
Generic MAC80211 802.11bgn ( in dumb AP mode )
Generic MAC80211 802.11bgn

Back haul from this AP:
MikroTik RBM33G
Architecture: MediaTek MT7621 ver:1 eco:3
Firmware Version: OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.020.41695-6f6641d)
Kernel Version: 4.14.95

Radios:
Generic MAC80211 802.11bgn
Generic MAC80211 802.11bgn

None of the WDS documentations I've found address having multiple radios in each AP. Wondering if I dedicate a radio in each one to back haul if it would improve speed. If so, what would be the best direction. The goal to expand coverage, thats it. Method of expansion I'm open to recommendations.

You do have to pick your backhaul uplink (if the distance is close enough, 5 GHz would be ideal - if you're further away, 2.4 GHz remains the only option), what you do beyond that depends on your hardware and needs. You can use dedicated interface or you can also repeat the signal on piggy-backing on the backhaul (as well), yes you pay with the repeater effect, but it still works.

Yes, it typically does. If you use the same radio for backhaul as for clients, your available bandwidth drops by about half.

That is why I run three-radio (native, not adapter) APs. One 2.4 and one 5 for clients, one 5 for backhaul.

1 Like

That is the ideal setup, however if you don't have three radios - it's worse not to use the 5 GHz interface as downlink (additionally to its primary function of being the backhaul uplink) and to rely solely on the 2.4 GHz interface for your repeated signal, than to pay the repeater effect penalty.

If you only have two 2.4 GHz interfaces, the choice is simple (dedicated interfaces), but that's not the common case.

1 Like

Thanks for the insight guys, the documented Luci config for the AP is throwing me a bit as it states to configure one interface ( a radio ) to be in WDS access point mode, yet the lan interface in the snapshot shows lan and two radios which look to be in bridge mode.

Here is my current config on the AP I intend to use as the back haul destination which is currently in dumb AP mode and making use of VLANs.

Ideally, I'd like to create a completely different SSID for the connecting AP placing it on its own VLAN. It seems the documentation requires the lan interface to be used, which i'm currently using as a maintenance interface. Is this possible? Once I have this working, I will replace the back haul 2.4's with 5 radios.

To reiterate my current configuration:

<openwrt router / no WiFI > ---- < dumb AP(a) snapshots above> ---- < additional AP(b) >

Building representation:

(building A: <openwrt router / no WiFI > ---- < dumb AP(a) snapshots above>)
(building B: < additional AP(b) > SSID: BnB Guests)

Endgame representation:

(building A: <dumb AP(a) SSID: Law Guests>)
(building B: <AP(b) SSID: BnB Guests>)
(building C: <AP(c) SSID: BnB Guests>)
(building D: <AP(d) SSID: BnB Guests>)

AP(d) --> AP(c) --> AP(b) --> AP(a) --> router. --> representing backhaul direction.

Call me a fan of starting small, with the basics and optimizing from there.

Your central AP/ router only needs option wds '1', not more, not less.

For the client, starting from a default setup, e.g. firstboot:

  • stop/ disable dnsmasq/ odhcpd (configure it accordingly so even if started, it will ignore your lan)
  • reconfigure one of your wlan interfaces as client device, with option wds '1'

at this point you repeat your signal to the client's ethernet (lan-) ports, don't do anything else (leave the switch configuration alone, unless you really, really, really need a fifth LAN port, you can keep the firewall running - it won't interfere with inter-lan traffic), keep it simple.

  • once you're there and tested, add (repeated-) AP interfaces to your client.

Basics done and working.

Now you have to decide, do you want the a single merged ESSID/ broadcast domain (for which IEEE 802.11k/v/r makes sense to set up) - or do you want a dedicated ESSID (probably nice for the initial testing, but once confirmed working the merged ESSID usually makes more sense).

Specifics can follow, if (really) needed.

Apologies @slh I updated posts same time you replied, having a look now. As reference in Building(a) I have multiple VLANs and 4 SSID's in play at the moment.

Well, WLAN doesn't have a concept of VLANs - you can only emulate them, either externally via dedicated AP interfaces (different ESSIDs) or 'internally' via, e.g., GRE tunnels and routing from there.

Keep in mind that most WLAN cards/ driver put limits on the number of concurrent STA- (typically <= 1) and AP (often <=4) interfaces, which favours GRE tunnels after a while.

I'd still recommend to start small and simple - and to expand from there, rather than trying to implement the full complexity in one go.

2 Likes

Ok, first and foremost, thank you so much for your detailed responses. I as well like to start simple. Building A in my case is already up and running and has been for a while. I'd like to not tamper with it if at all possible.

To keep things as simple as possible for now, I think what I need to do is simply connect AP(b) and AP(a) wirelessly via backhaul radios giving AP(b) SSID: BnB Guests. Once that's working, consider WDS for the remaining.

I'm going to try bridging the lan port and required VLAN and see what happens.

Haven run WDS, GRE tunnels, and various mesh protocols, I’d go with what slh suggests. For just a couple VLANs (1, 2, maybe 3), multiple SSIDs for each over WDS is reasonable and won’t make your head spin.

Thanks @jeff

As @slh mentioned [quote="slh, post:10, topic:42564"]
Your central AP/ router only needs option wds '1' , not more, not less.
[/quote] ... in my case I have two separate boxes. One is running OpenWRT, no WiFI just routing. The second is in dumb AP mode. Would this option need to be done on the router or the dumb AP? Hate to bring the whole network down and/or lock myself out.

It needs to be done on the central AP, whose signal is going to be repeated.

Considering that this situation is considerably different from what you originally described, "I have [just] two APs", a lot of other factors are becoming relevant (geographical (e.g. repeating a repeated signal is bad, as latency goes to hell and the repeater effect accumulates), (network-) topological), etc. Universal answers are no longer possible without taking the local situation into account (perhaps WDS/ 4addr will do (star topology), but at some point a mesh backhaul might make more sense - and a wired or even fibre backhaul becomes strongly preferred at some (other) point).

1 Like

Understood. In fact, fiber is coming at a later date. However, for this evening endevour, I'm needing to get AP(b) online as SSID BnB Guest with wireless backhaul connectivity by morning. So my only option is the following:

Building A (OWRT Router) networked to (AP(a) in dumb mode) <-----backhaul-----> Building B (AP(b) SSID BnB Guests)

Now I'm thinking I should in the simplest way possible setup AP(b) to backhaul to AP(a) and setup AP(b) to route and be the WDS. Thoughts?

Simplest way connecting the two APs for backhaul purposes only then later making the AP(B) mode WDS and as separate router use relayd? https://openwrt.org/docs/guide-user/network/wifi/relay_configuration

Just wanted to follow up on this topic. What I ended up doing is swapping out the dumb AP with a stock openwrt build and followed the doc for WDS. Its works, but its slow (4-5mbs at best on 2.4), and its double natting.

<ap(d)>--<ap(c)--<ap(b)>--<ap(a)>--(router)--(internet)
WDS--WDS--WDS--WDS/router--router--internet
radio0-ssid:house3 radio0-ssid:house2 radio0-ssid:house1 radio0:ssid:Office Guests
radio1-ssid:Backhaul radio1-ssid:Backhaul radio1-ssid:Backhaul radio1-ssid:Backhaul

Not quite sure if I'm dedicating backhaul correctly or not. Will posts configs as soon as I'm onsite again.

@slh It looks like my none star topology running WDS is experiencing the repeater effect. The last leg here is almost useless. 2 X 2.4 Radio Cards in each AP. Considering a P2MP solution now. However, the dotted line represents fiber which we're installing tomorrow morning.

Your topology will always incur repeater effect, without a wired backhaul (or at least a dedicated wireless backhaul (tri-radio devices; latency will still suffer here)).

WDS/ 4addr or the various meshing possibilities won't really make a difference here, as you don't have multiple signal propagation paths do exploit (at best the two APs at the right, but both are almost equidistant to the next hop to the left, rendering this moot as well).

Larger setups like this do need professional network planning, just throwing wireless at it is unlikely to help/ do anything sensible. The only 'simple' (and sensible) solution would be interconnecting the buildings via ethernet, to achieve robustness against lightning and equipotential bonding (just as well as segment length, as you're almost around the limits - depending on your actual cable runs) fibre would be the best choice (not just for speed reasons).