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)?
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.)