Recently a patch for hostapd on OpenWrt was merged that allows to Access Points to send messages to other Access Points while still allowing clients to connect to it as it would be a regular Access Point.
This was called APuP: Access Point Micro (μ) Peering
From the author, G10H4ck:
“Fiddling with hostad code I have managed to successfully establish WiFi communication between multiple AP, each of them send and receive traffic from the other as if they where associated stations, while they are all configured in AP mode. This P2P like behavior have multiple advantages compared to the usual setup where one of them is configured as AP and all the others as stations, and also compared to Ad-Hoc, WDS, 802.11s, Multi-AP and EasyMesh. I have named this operanting mode APuP (Access Point Micro Peering).” (Source)
From the OpenWrt merge request:
“A simpler and more useful successor to Ad Hoc, Wireless Distribution System, 802.11s mesh mode, Multi-AP and EasyMesh.
Almost plain APs communicate between them via 4-address mode, like in WDS but all of them are AP, so they can eventually communicate also with plain stations and more AP nodes in sight. Low hardware requirements, just AP mode support 4-address mode, and no more unnecessary complications, like hardcoded bridging or routing algorithm in WiFi stack. For each AP in sight an interface is created, and then it can be used as convenient in each case, bridging, routing etc.” (Source)
A bit more context:
“In community networks we need to maximize the possible paths of communitacions between nodes. In a classical AP-STA approach it is not possible to guarantee communication between all possible nodes in all scenarios. As an example if we have 4 nodes A, B, C and D where A and B sees each other, B and C sees each other C and D sees each other. With AP-STA mode each radio must operate either as AP or as STA, each STA must connect to only one AP at once, STA need an AP to relay communication between thems. In each combination configuring each node either as AP or STA you will see that some of them will end up not being able to connect. To overcome this issue in the past adhoc mode was used which solved the basic connectivity issue, still it’s implementation wasn’t high quality and it’s design had important flaws, this resulted it in becoming unmaintained after a few years. Luckly while adhoc was growing outdated 802.11s emerged, it had a few improvements, still some design choice such as complex ways to bridge other networks and routing between nodes fossilized into the standard, increased WiFi drivers complexity became problematic and lastly determined it’s silent demisal. New radios drivers and firmwares doesn’t support 802.11s well. New WiFi standards doesn’t bring much improvements to 802.11s mesh mode, while they do improve a lot AP-STA modes. Still our need of nodes being able to comunicate to anyone in range is strong. In this context, looking for a modern solution I started asking myself, is there an hard to resolve problem that impede AP nodes in sight to talk each other? Talking about my thinking with Felix Fietkau (nbd), we agreed that it might be possible for AP nodes to commuicate directly each other, and because AP mode is what is getting more support and improvements, if we can we just use that on all nodes with some slight modification so all AP in sight can talk each other, we could solve this problem that afflict us since WiFi creation. Felix suggested that this should be possible and with a bit of luck should not even need kernel and driver modifications, modifing hostapd in a way that each AP adds the other in sight to its station list could be enough and it is indeed the staring point to start experimenting and see what happens.” (Source)
The advantages are simple:
- no additional mesh SSID is broadcasted
- no Linux kernel / driver change
- AP mode is much more stable compared to other mesh modes
A few disadvantages also need to be mentioned:
- a new interface for each other AP is created,
this can be a bit of a configuration burden - the code is still mostly untested
Example Setup
APuP is only available in the OpenWrt snapshot builds as for now until the text major release. If you have two WLAN router A and B then let’s set up one example:
Router A
uci set wireless.radio0.disabled=0
uci set wireless.default_radio0.ssid=openwrt-mesh
uci set wireless.default_radio0.encryption=psk2
uci set wireless.default_radio0.key=12345678
uci set wireless.default_radio0.network=lan
uci set wireless.default_radio0.apup=1
uci commit wireless
Now reboot the device.
The single important setting is apup=1, which enables APuP. Without any other mesh device around, there will be only a “phy0-ap0” interface bridged to the br-lan bridge interface. This is the WLAN interface where normal clients will connect to (e.g. mobile phones, laptops, …).
Router B
uci set wireless.radio0.disabled=0
uci set wireless.default_radio0.ssid=openwrt-mesh
uci set wireless.default_radio0.encryption=psk2
uci set wireless.default_radio0.key=12345678
uci set wireless.default_radio0.network=lan
uci set wireless.default_radio0.apup=1
uci commit wireless
uci set network.lan.ipaddr='192.168.1.2'
uci set dhcp.lan.ignore='1'
uci commit network
uci commit dhcp
These commands also disables the DHCP server on router B and set a unique IP address.
Now reboot the device.
After the reboot, a “phy0-ap0” interface will be created as we have seen on Router A.
Since both routers see each other, each of them will also create a “phy0-ap0.sta1” interface that will be bridged to the br-lan bridge interface. If yet another router would be in reach, then a new interface called “phy0-ap0.sta2” would be created and so on for each AP in reach. That is how routers exchange packets between each other.
But be careful. If we would now set up a third device router C similar to router B (or even router A), then any packet will be send between routers A, B and C in a loop, due to the bridged interfaces. This will cause the CPU and bandwidth unitilization to be pushed to the maximum and the network will be unusable.
That is what a mesh routing protocol (e.g. batman-adv, OLSR, Yggdrasil) or a spanning tree protocol would prevent. But that is another topic. 🙂
Notes
- APuP is still experimental
- If a neighbor AP vanishes, then the associated interface on the neighbor routers will persist and does not time out.
- The encryption/key settings only affect the client interface. The AP-to-AP connections are without encryption. Maybe this will change in the future.
- “apup_peer_ifname_prefix” can be used next to the “apup” setting to change the default interface name prefix
- hostapd patch by Gio
- Freifunk Radio 110 about APuP (English)
- OpenWrt merge request that introduces APuP
Cheers,
mwarning
