Temat: Access Point Micro Peering - nowy sposób łączenie AP w mesh
Dwa dni temu (13 sierpnia 2024) do wersji rozwojowej OpenWrt, do hostapd dodali nowy sposób tworzenia sieci typu MESH - nazwany Access Point Micro Peering. Pozwolę sobie zacytować jego opis:
Access Point Micro Peering is a simpler and hopefully more useful successor to Ad Hoc, Wireless Distribution System, 802.11s mesh mode, Multi-AP and EasyMesh.
When enabled 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, without more trickery.
APuP has 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.
Those interfaces could be simply bridged in a trivial topology (which happens automatically if wds_bridge is not an empty string), or feeded to a routing daemon.
W "tradycyjnym" podejściu do mesha robiło się interfejsy radiowe pracujące w odpowiednim trybie (np. 802.11s), a dalej zwykle łączyło się je do bridge. Aby dodatkowo był dostęp do takich punktów trzeba było na tym samym interfejsie radiowym zrobić nowy interfejs pracujący w trybie np. AP żeby klienci mogli się przez niego łączyć i połączyć wszytko w jedność. Uprościłem trochę opis, ale ogóle tak to mniej więcej wyglądało.
W przedstawionym podejściu wystarczy mieć tylko interfejs w trybie AP wraz z ustawionymi odpowiednimi opcjami. Utworzy to dodatkowy interfejs który można dołączyć np. do bridge lanowego.
Zróbmy przykładową konfigurację. Zakładam że OpenWrt jest w domyślnej konfiguracji.
Punkt który będzie robił za gatewaya, ma domyślny adres 192.168.1.1:
uci set wireless.radio0.disabled=0
uci set wireless.default_radio0.ssid=test2
uci set wireless.default_radio0.encryption=psk2
uci set wireless.default_radio0.key=12345678
uci set wireless.default_radio0.apup=1
uci set wireless.default_radio0.apup_peer_ifname_prefix=apup
uci add_list network.@device[0].ports=apup1
uci commit
rebootKonfiguracja jest dość podstawowa - włączamy radio, ustawiamy nazwę sieci wraz z szyfrowaniem oraz ustawiamy dwie nowe opcję - apup która włączy w/w funkcjonalność oraz apup_peer_ifname_prefix które jest prefiksem nazwy interfejsu. Jeżeli utworzy się interfejs to zostanie on nazwany apup1, a kolejna linia dołączy go do bridge lanowego.
Podłączamy kabel do wanu i w takiej konfiguracji mamy zwykły router z rozgłaszaniem sieci przez WiFi.
Węzły sieci mesh
Robimy teraz węzeł sieci mesh, który będzie tylko miał zasilanie, a bezprzewodowo łączył się z naszym gatewayem, będzie w tej samej klasie adresowej i rozgłaszał tą samą sieć:
uci set wireless.radio0.disabled=0
uci set wireless.default_radio0.ssid=test2
uci set wireless.default_radio0.encryption=psk2
uci set wireless.default_radio0.key=12345678
uci set wireless.default_radio0.apup=1
uci set wireless.default_radio0.apup_peer_ifname_prefix=apup
uci add_list network.@device[0].ports=apup1
uci set network.lan.ipaddr='192.168.1.2'
uci set network.lan.gateway='192.168.1.1'
uci set network.lan.dns='192.168.1.1'
uci set dhcp.lan.ignore='1'
uci commit
rebootKonfiguracja jest podobna, tu się różni tylko tym że:
- zmieniamy mu adres na lanie na kolejny z tej samej puli adresowej (inny dla każdego węzła)
- ustawiamy gatewaya i dns na naszego (zapewni to dostęp do internetu z danego węzła, choć jest to zbędne z punktu widzenia klienta)
- wyłączamy serwer dhcp
Ustawiamy w taki sam sposób sieć bezprzewodową. I to wszystko, podłączamy tylko zasilanie. Jeżeli dojdzie do wykrycia i połączenia innego węzła to powstanie interfejs apup1 który zostanie dodany do bridga lanowego i będziemy mieli normalny dostęp do internetu.
root@OpenWrt:~# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.972 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=1.787 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=2.653 ms
--- 192.168.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.787/2.137/2.653 ms
root@OpenWrt:~# ping -c 3 onet.pl
PING onet.pl (13.227.146.66): 56 data bytes
64 bytes from 13.227.146.66: seq=0 ttl=246 time=10.411 ms
64 bytes from 13.227.146.66: seq=1 ttl=246 time=20.452 ms
64 bytes from 13.227.146.66: seq=2 ttl=246 time=9.728 ms
--- onet.pl ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 9.728/13.530/20.452 msroot@OpenWrt:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.ac8674069098 no eth0
phy0-ap0
apup1
root@OpenWrt:~# iw dev
phy#0
Interface apup1
ifindex 9
wdev 0x4
addr xx:xx:xx:xx:xx:xx
type AP/VLAN
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
4addr: on
Interface phy0-ap0
ifindex 8
wdev 0x3
addr xx:xx:xx:xx:xx:xx
ssid test2
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 1 0 0 0 0 30 1
Przedstawione rozwiązanie działa obecnie tylko w wersji rozwojowej OpenWrt i nie zostało jeszcze przeniesione do wydania stabilnego. Jest to bardzo świeża rzecz i pewnie kilka razy jeszcze się zmieni, choć trzeba przyznać że już teraz dość upraszcza tworzenie sieci mesh bo zajmuje się wszystkim główny demon odpowiedzialny za tworzenie punktu dostępowego.
