Access Point Client Roaming / Ethernet Backhaul

Installing and Using OpenWrt Network and Wireless Configuration
#1

Hi all,

schematically spoken, I have the following situation where WiFi signals will not pass through the walls between rooms R1, R2 and R3.

|        aisle       |
+--  --+--  --+--  --+
|  R1  |  R2  |  R3  |
+------+------+------+

Since R1, R2 and R3 have LAN sockets while the aisle has neither power nor LAN nor the tiniest bit of WAF, my idea is to have (weak) access points in each of the rooms with a seamless operation when a client changes its position. The LAN has a star topology.

In this regard, my requirements differ from what many mesh solutions provide: I don't need any ad-hoc or dynamic configuration. Also, I don't need a wireless backhaul channel because it simply won't work. At the same time, all LAN cables end in a box where no WiFi makes sense, so the main router will be separate and not a "master" WiFi AP. And, guest WiFi is required as well as isolation of some devices in the rooms from the rest of the network, so VLANs will have to be set up and the main router must sort it all out.

From what I have read, it may be possible that BATMAN can solve this, because it should be able to interconnnect the access points via LAN without a master, is that correct? If yes, can I tell it to not even try to connect the other APs wirelessly?

What I don't understand so far is whether 802.11s support is required or not. As far as I see it I don't need it but maybe the software isn't designed to support the desired functionality without 802.11s capabilities? So is there a dependency or not in this particular case?

Does my solution approach make sense, should I be looking at something different, are there any references to descriptions of such an approach (I'm not sure I'm searching for the right keywords)?

#2

You can do what I think you're trying to do without BATMAN, 802.11s, OLSR, or anything fancy.

On each AP and your "main" router create a bridge for each VLAN you need. That bridge should "cover" the wireless interface for that VLAN, as well as an Ethernet interface "tagged" for the VLAN at the switch. Then you can "daisy chain" or "star" that "trunk" across the router and APs, all on one Ethernet cable between each device.

So, you could, for example, assign that trunk to ports 1, 2, and 3 on your main router and port 1 on the APs, then plug port 1 of each AP into the "special" ports on your main router.

You could also consistently set up ports 1 and 2 for the trunk, and wire

  • Main, port 2 <=> AP 1, port 1
  • AP 1, port 2 <=> AP 2, port 1
  • AP 2, port 2 <=> AP 3, port 1

(though daisy chain seems like it won't work the way you described it as a "star")

If you can't locate the master in the "closet", then you'll likely need a VLAN-aware switch there. Decent ones can be had for US$100 new, or perhaps a used Cisco SG300 at about the same price.

3 Likes
#3

The roaming of clients around a network of APs with the same SSID is independent of how the APs are interconnected.

There's considerable confusion over this because of commercial "mesh system" offerings which also claim to improve client roaming. Those two functionalities are separate functions in the product.

6 Likes
#4

This is really just a normal "multiple APs on the same network" except that you carry more than one network over the ethernet cables using VLAN tags to demultiplex.

Physically the topology looks like this:


ROUTER ------- Managed Switch ------- AP1
                  |     |
                  |     ----------------- AP2
                  |
                  -------------- AP3

The "managed switch" can be either a separate piece of hardware, or it can be one of the switches built into a consumer router running OpenWrt

each of the wires carries tagged packets for at least LAN and GUEST VLANs. Each AP contains two SSIDs one bridged to each ethernet VLAN.

Put each AP onto a separate channel, 1,6,11 for the 2.4GHz band, and you can choose whichever non-overlapping channels for the 5GHz band if they're dual band.

The client decided which AP it will try to connect to. OpenWrt doesn't offer anything similar to proprietary band-steering solutions etc. Those work by telling the AP to refuse any connection from a device that the controller wants to steer onto a particular AP... the client then tries again with a different AP until it gets onto the one the controller wants it on. Instead OpenWrt will just accept the client onto whatever one it tries. But unless you have literally more than 100 devices on these APs I doubt you'll have problems.

1 Like
#5

What about client roaming / band steering?

The router can be placed in the "closet".

#6

Thank you for clarifying this. And can anything be done to improve client roaming? I recall a setup where I seemed to have problems with a specific kind of client.

#7

What would happen if each AP uses the same channel? Does it affect roaming, or are you suggesting to have separate channels "only" because it improves throughput in the absence of other networks?

Is there nothing that a controller could know / do better than the client, unless I have dozens of clients?

#8

I'm sure it could do better, but this functionality is only available on proprietary systems. And it would be rare to see major problems without dozens of clients. One thing you might do is eliminate some of the slower rates, make sure to disable all 802.11b legacy rates, and maybe even disable the 6 and 9 Mbps rates, this will force roaming earlier.

1 Like
#9

It would dramatically reduce effectiveness of the whole system, use separate non overlapping channels.

#10

Which effectiveness? Data throughput or client roaming? (Because if you're referring to data throughput then I believe you're assuming that there's no foreign WiFi disturbing the channels.)

#11

Client roaming algorithms vary by vendor but I believe they often prefer a different channel to the same channel. So both, maybe?

#12

Thank you for pointing this out! I just found Why You Should Disable Lower Legacy Data Rates based on your hint. Sounds promising. I'll have to play with /etc/config/wireless, right?

#13

Yes, basically the higher you set the minimum rate, the closer the device will have to be to maintain a connection. When there are multiple APs you want to only use higher rates and force roaming rather than stick to same AP with lower rates.

#14

According to SmallNetBuilder: How To Fix Wi-Fi Roaming, it seems as if 802.11r support would be beneficial (for clients which support it)....

#15

There's kind of minimal support in general for 802.11r but if you're using WPA2-PSK it's just a checkbox to enable it... so you could try. Apparently it helps with Apple products, and it can prevent some older devices from working at all.

1 Like
#16

Low power on the AP's is key as mentioned.....

You can also lower the beacon interval slightly, if snappy roaming is preferable to a decrease in throughput across the board.

#17

Doesn't 802.11r require any hardware / driver support?

#18

Good to know, thanks! I will play with it, assuming that the decrease in throughput is relative to the connection speed, which should be good enough with small distances between access points and clients (if handoff works as expected).

#19

it does require software, wpad/hostapd supports it, and like I said it's a checkbox if you're using pre-shared keys.

On the client, yes it requires support, and many many clients don't support it. Some to the point of being unable to connect. Basically for a few more years I think it's unlikely to be a good idea to enable 802.11r

It's really that the beacon takes up airtime, so that airtime doesn't get used to transmit data.

#20

  1. First of all, I'm still trying to find out how to disable rates. For openwrt, would /etc/config/wireless be the right place? Any UI, any other platform?
    Unfortunately, my AP does not seem to be supported by openwrt, ánd I'm trying to avoid wrong investments. Therefore I'm still collecting material and trying to play with what I currently have.

  2. Am I right in assuming that "disabling WiFi connection features" such as rates is "more natural" than having the AP disconnect based on criteria? I would assume so because then it's still completely a client decision, nothing forced by the AP.
    There are a few approaches to have the AP disconnect: ASUS offers a "roaming assistant" based on configurable signal strength. For OpenWRT, there is angry_wifi.sh and, more sophisticated, Disconnect WiFi STA (clients) based on their signal levels whcih considers SNR, something I find interesting.

  3. What about 802.11n only for 2.4 GHz? Is that something that one would expect to come close to disallowing 802.11b? (There are no b/g clients left.)