Temat: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Temat może trochę dziwny, ale w sumie wyjaśnia problem.

Skonfigurowałem na TP-Link Archer C2 v1 sieć mesh 802.11s z szyfrowaniem WPA3-SAE. Jestem pewny, że wszystko dobrze ustawiłem (przećwiczyłem temat na Archerach C7 v5) ale połączyć się nie chciało. Po kilku chwilach szukania ustaliłem, że to jest istotne:

Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:31 2021 daemon.notice wpa_supplicant[1901]: wlan0: new peer notification for e8:94:f6:d0:d1:be
Sat May 29 13:44:41 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:44:58 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:13 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:28 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-FAILURE addr=e8:94:f6:d0:d1:be
Sat May 29 13:45:28 2021 daemon.notice wpa_supplicant[1901]: wlan0: MESH-SAE-AUTH-BLOCKED addr=e8:94:f6:d0:d1:be duration=300

Przestawiłem mesha na tryb bez szyfrowania i faktycznie łączy się bez problemu. Z szyfrowaniem jak wyżej.

Może nie będę wielu linków podrzucał, ale sytuację dość dobrze wyjaśnia ten post: https://github.com/libremesh/lime-packa … -842034728. Człowiek pisze tutaj zdaje się o tej łatce: https://git.openwrt.org/?p=openwrt/open … 636116a35a.

Nie wiem czy faktycznie to jest powodem, ale zrozumiałem, że początkowy handshake w WPA3-SAE trwa zbyt długo, strony uznają, że wiadomości nie dotarły na czas i kwitują to komunikatem: MESH-SAE-AUTH-FAILURE. Mówiąc krótko: za wolny procesor sad Z OpenSSL też mi nie działa sad

Człowiek, który opisał problem w tym poście na GitHubie ma OpenWrt 19.07.6 a tam libwolfssl24 - 4.6.0-stable-1 oraz wpad-mesh-wolfssl - 2019-08-08-ca8c2bd2-4. W repozytoriach nie ma już tej wersji biblioteki WolfSSL ani wpad-mesh-wolfssl, ma ktoś może taki zabytek, żebym mógł u siebie podmienić i przetestować? Ktoś bardziej biegły niż ja mógłby sprawdzić w źródłach, czy ta poprawka, do której link podałem jest ciągle aktywna?

2

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Od roku jest w repo openwrt 19.07. Więc jak używasz aktualnych wersji systemu i pakietów to ją już masz.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Po wielu próbach zaczęło działać. Co dokładnie dzieje się podczas "handszejku" nie wiem, ale urządzenie nie potrafią się dogadać. Odpaliłem na OpenWrt 19.07-SNAPSHOT r11328. Działa zarówno z wpad-mesh-wolfssl jak i wpad-mesh-openssl, działa też jeżeli na jednym z węzłów jest WolfSSL a na innym OpenSSL. A żeby zaskoczyło to przełączyłem tryb pracy z AC na N (mnóstwo klikania w LuCI, żeby zmienić z VHT40 na HT40 wink). Nie łapie od razu, ale działa:

Tue Jun  8 09:50:13 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-GROUP-STARTED ssid="mesh_5G" id=0
Tue Jun  8 09:50:13 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:14 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:15 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:24 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:26 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with c4:6e:1f:40:9e:bc established
Tue Jun  8 09:50:26 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED c4:6e:1f:40:9e:bc
Tue Jun  8 09:50:30 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=30:b5:c2:96:1b:9b
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: new peer notification for 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with 30:b5:c2:96:1b:9b established
Tue Jun  8 09:50:31 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED 30:b5:c2:96:1b:9b
Tue Jun  8 09:50:39 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:50:50 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-SAE-AUTH-FAILURE addr=d4:6e:0e:c6:0e:e6
Tue Jun  8 09:51:01 2021 daemon.notice wpa_supplicant[1640]: wlan0: mesh plink with d4:6e:0e:c6:0e:e6 established
Tue Jun  8 09:51:01 2021 daemon.notice wpa_supplicant[1640]: wlan0: MESH-PEER-CONNECTED d4:6e:0e:c6:0e:e6

4

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Ostatnio testuję sobie meshe i jestem zadowolny z działania, ale pojawił się pewien problem:

Powiedzmy, że mamy 3 urządzenia:
- A i B widzą się doskonale i zestawiają linka na 300Mbit/s
- B i C też się widzą się doskonale i też zestawiają linka na 300Mbit/s
- ale A i C widzą się, raczej słabo i zestawiają linka na 6Mbit/s

Problem polega na tym, że wbudowany w 802.11s protokół forwardingu, jeżeli trzeba będzie przesłać dane pomiędzy A i C to wybierze drogę bezpośrednią (mniej skoków) i połączenie będzie, ale bardzo wolne.

Pytanie brzmi: co mogę zrobić, żeby to zachowanie zmienić?

Na razie jedyne co mi przyszło do główy, to zmienić to ustawnienie:

mesh_rssi_threshold='-66'

Wartość może nie idealnie dobrana, ale jeżeli poziom sygnału spada gdzieś poniżej -70 dBm to wtedy linka urządzenia mi zestawiają, ale na niższej prędkości.

Taka zmiana spowoduje, że A i C nie zestawią bezpośredniego linka w sieci mesh. Czyli niby o to chodzi, ale jeżeli B stanie się niedostępny, to nie mam połączenia wcale. A nie ruszajać poziomu RSSI połączenie by było, chociaż trochę powolne.

Da się zrobić, żeby routing był na podstawie jakości/szybkości połączenia a nie liczby skoków?

5

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Zmienić protokół routingu smile

Tak, musisz bazować na poziomie sygnalu, choć zobacz czy w 802.11s nie było możliwości usuwania połączenia pomiędzy nodami, bo juz nie pamietam tego.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

6

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Siedzę... Czytam... I w sumie większość wydaje mi się, że rozumiem, poza jedną rzeczą hmm

Znalazłem protokół z "throughput based metric": https://www.open-mesh.org/projects/batm … /BATMAN_V, czyli BATMAN_V. Co prawda sugerują, że lepiej użyć BATMAN_IV: https://openwrt.org/docs/guide-user/net … sh/batman, ale to już sobie potestuję.

Dobra, a wracając do poradnika [OpenWrt Wiki] B.A.T.M.A.N. / batman-adv: Nie bardzo rozumiem jak mam potem mesha z batmanen podłączyć do sieci LAN?

W standardowym meshu mam:

config wifi-iface 'wifinet3'
        option network 'lan'
        option device 'radio0'
        option mode 'mesh'

czyli konfigurując interfejs w trybie mesh podpinam go po sieć lan. A konfigurując batman-adv powinienem dopisać jego interfejs do mostu:

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'

?
I tu dodać:

list ifname 'bat0'

czy też podmienić linię i wpisać:

option ifname 'eth0.1 bat0'

a może jeszcze jakoś inaczej?

================================================================================

BTW:

(...) choć zobacz czy w 802.11s nie było możliwości usuwania połączenia pomiędzy nodami, bo juz nie pamietam tego.

Myślę, że dałoby radę używając iw:

    dev <devname> mpath set <destination MAC address> next_hop <next hop MAC address>
        Set an existing mesh path's next hop.

    dev <devname> mpath new <destination MAC address> next_hop <next hop MAC address>
        Create a new mesh path (instead of relying on automatic discovery).

    dev <devname> mpath del <MAC address>
        Remove the mesh path to the given node.

Ale to już jest ingerencja "ręczna" a zależy mi na tym, żeby to było bezobsługowe i żeby można było sobie węzły przenosić w dowolne miejsca bez ciągłego poprawiania konfiguracji.

7

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Dokładnie. Robi się dodatkowa sieć a co zrobisz z interfejsami to już jak chcesz - możesz utworzyć z nimi bridge.

PS. Masz jeszcze olsrd, bmx i parę innych protokołów...

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

8

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Skonfigurowałem BATMANa. Nawet działa. Aczkolwiek, żeby działał BATMAN_V, czyli routing na podstawie oczekiwanej przepustowości, to odpowiednią wartość musi zwrócić sterownik. Poleceniem iw dev mesh1 station dump wyświetlamy listę sąsiadów a tam szukamy informacji typu expected throughput:    42.388Mbps. Jeżeli jej nie ma, to wszystkie połączenia mają wagę 1 (Archer C7 v5 ma taką możliwość na 2.4GHz ale na 5GHz nie zwraca tego parametru). Wtedy zostaje propokół BATMAN_IV, który ocenia "jakość poąłączeń" - szczegóły na stronach projektu, ogólnie mierzy się straty z tego co zrozumiałem.

Jest jeszcze jedna rzecz z BATMANem, której nie potrafię ogarnąć. Może od razu przyjąłem złe założenia i to nie będzie działać, ale powiedzmy, że mamy taką sytuację: dwie sieci mesh, jedna na 5GHz i jedna na 2.4GHz. Jestem w stanie obie przypisać pod jeden interfejs bat0 - w założeniu "wybierz najlepszą trasę uwzględniając dwie możliwości na różnych częstotliwościcach". Problem w tym, że w praktyce BATMAN widzi mi wtedy 2 ... hmmm ... adresy? W każdym mam w tablicy routingu dwa razy to samo urządzenie fizyczne, tylko z różnymi adresami MAC, bo radio 5GHz ma inny MAC niż radio 2.4GHz. Jak powinienem do tego tematu podejść?

9 (edytowany przez mar_w 2021-07-06 09:04:53)

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Możesz spróbować włączyć opcję "bonding" w konfiguracji interfejsu "bat0".
Testy na słabiutkim cpu w WNDR4300v1 pokazały że przy szyfrowaniu SAE nie podskoczył wyżej niż 115 Mbps na 21.02-SNAPSHOT

Ogólnie to dziwnie chodzi ten wbudowany w BATMAN-a "bonding".

[host nr 1] <-LAN-> [węzeł nr 1] <-- {{{Mesh 2,4GHz + Mesh 5GHz}}} --> [węzeł nr 2] <-LAN-> [host nr 2]

Gdy leci przez 2 interfejsy radiowe to ma mniejszą szybkość niż gdy leci przez jedno radio 5GHz.
Jak sobie wybierze tak będzie  smile

PS. A ten Twój C2v1 to też słabizna tyle że z lepszym radiem na 5 GHz.
C7v5 trochę lepszy ale nie sądzę że puknie więcej niż 150 Mbps w meshu.

Żeby jeszcze obsłużył NAT na konkretnym poziomie to ten brzegowy musi być niezły dzik big_smile

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

10

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

Zainteresowałem się tym bondingiem: https://www.open-mesh.org/projects/batm … nding-mode
i wywnioskowałem, że to powinno działać i bez niego i wtedy nawet lepiej: https://www.open-mesh.org/news/14

Wróciłem więc do mojego sprzętu i przyjrzałem się dokładniej działaniu mesha.

Większość opisu konfiguracji jest na stronach OpenWrt, nie będę więc powielał, i po przemyśleniu uznałem, że tak będzie dobrze w /etc/config/network:

config interface 'bat0'
        option proto 'batadv'
        option routing_algo 'BATMAN_V'
        option bonding '0'

config interface 'net_wifi_mesh0'
        option mtu '2304'
        option proto 'batadv_hardif'
        option master 'bat0'

config interface 'net_wifi_mesh1'
        option mtu '2304'
        option proto 'batadv_hardif'
        option master 'bat0'

A następnie w /etc/config/wireless:

config wifi-iface 'meshnet0'
        option device 'radio0'
        option mode 'mesh'
        option ifname 'mesh0'
        option network 'net_wifi_mesh0'
        option mesh_fwding '0'

config wifi-iface 'meshnet1'
        option device 'radio1'
        option mode 'mesh'
        option ifname 'mesh1'
        option network 'net_wifi_mesh1'
        option mesh_fwding '0'

Na pierwszy rzut oka wygląda problematycznie (bo mam 10 sąsiadów):

# batctl n
[B.A.T.M.A.N. adv openwrt-2019.2-11, MainIF/MAC: mesh1/d8:0d:17:22:b4:c5 (bat0/c2:ae:c2:ee:2f:cd BATMAN_V)]
IF             Neighbor              last-seen
30:b5:c2:96:1b:9b    0.050s (       18.1) [     mesh1]
f4:f2:6d:9b:f6:30    0.330s (       43.9) [     mesh1]
e8:94:f6:d0:d1:be    0.310s (       18.7) [     mesh1]
c4:6e:1f:40:9e:bc    0.400s (       47.9) [     mesh1]
d4:6e:0e:c6:0e:e6    0.450s (       47.1) [     mesh1]
d4:6e:0e:c6:0e:e7    0.030s (       38.9) [     mesh0]
e8:94:f6:d0:d1:bf    0.220s (        4.2) [     mesh0]
30:b5:c2:96:1b:9c    0.010s (       48.2) [     mesh0]
c4:6e:1f:40:9e:bd    0.090s (      116.0) [     mesh0]
f4:f2:6d:9b:f6:31    0.510s (       88.4) [     mesh0]

Ale jednak jest OK (routing jest do 5 urządzeń, wybrałem takiego który faktycznie ma niektóre przez mesh1 a niektóre przez mesh0):

# batctl o
[B.A.T.M.A.N. adv openwrt-2019.2-11, MainIF/MAC: mesh1/d8:0d:17:22:b4:c5 (bat0/c2:ae:c2:ee:2f:cd BATMAN_V)]
   Originator        last-seen ( throughput)  Nexthop           [outgoingIF]
   d4:6e:0e:c6:0e:e6    0.400s (       43.3)  d4:6e:0e:c6:0e:e7 [     mesh0]
   d4:6e:0e:c6:0e:e6    0.400s (       21.0)  e8:94:f6:d0:d1:bf [     mesh0]
   d4:6e:0e:c6:0e:e6    0.400s (       38.6)  30:b5:c2:96:1b:9c [     mesh0]
   d4:6e:0e:c6:0e:e6    0.400s (       43.3)  f4:f2:6d:9b:f6:31 [     mesh0]
   d4:6e:0e:c6:0e:e6    0.400s (       43.7)  c4:6e:1f:40:9e:bd [     mesh0]
   d4:6e:0e:c6:0e:e6    0.400s (       16.9)  30:b5:c2:96:1b:9b [     mesh1]
   d4:6e:0e:c6:0e:e6    0.400s (       22.7)  e8:94:f6:d0:d1:be [     mesh1]
   d4:6e:0e:c6:0e:e6    0.400s (       41.0)  c4:6e:1f:40:9e:bc [     mesh1]
   d4:6e:0e:c6:0e:e6    0.400s (       38.1)  f4:f2:6d:9b:f6:30 [     mesh1]
 * d4:6e:0e:c6:0e:e6    0.400s (       45.8)  d4:6e:0e:c6:0e:e6 [     mesh1]
   f4:f2:6d:9b:f6:30    0.960s (       43.3)  d4:6e:0e:c6:0e:e7 [     mesh0]
   f4:f2:6d:9b:f6:30    0.960s (       20.7)  e8:94:f6:d0:d1:bf [     mesh0]
   f4:f2:6d:9b:f6:30    0.960s (       38.8)  30:b5:c2:96:1b:9c [     mesh0]
   f4:f2:6d:9b:f6:30    0.960s (       47.9)  c4:6e:1f:40:9e:bd [     mesh0]
 * f4:f2:6d:9b:f6:30    0.960s (       95.9)  f4:f2:6d:9b:f6:31 [     mesh0]
   f4:f2:6d:9b:f6:30    0.960s (       17.0)  30:b5:c2:96:1b:9b [     mesh1]
   f4:f2:6d:9b:f6:30    0.960s (       43.4)  f4:f2:6d:9b:f6:30 [     mesh1]
   f4:f2:6d:9b:f6:30    0.960s (       20.6)  e8:94:f6:d0:d1:be [     mesh1]
   f4:f2:6d:9b:f6:30    0.960s (       37.2)  d4:6e:0e:c6:0e:e6 [     mesh1]
   f4:f2:6d:9b:f6:30    0.960s (       41.0)  c4:6e:1f:40:9e:bc [     mesh1]
   c4:6e:1f:40:9e:bc    0.850s (       43.3)  d4:6e:0e:c6:0e:e7 [     mesh0]
   c4:6e:1f:40:9e:bc    0.850s (       20.7)  e8:94:f6:d0:d1:bf [     mesh0]
   c4:6e:1f:40:9e:bc    0.850s (       38.8)  30:b5:c2:96:1b:9c [     mesh0]
   c4:6e:1f:40:9e:bc    0.850s (       45.7)  f4:f2:6d:9b:f6:31 [     mesh0]
 * c4:6e:1f:40:9e:bc    0.850s (      124.5)  c4:6e:1f:40:9e:bd [     mesh0]
   c4:6e:1f:40:9e:bc    0.850s (       21.7)  e8:94:f6:d0:d1:be [     mesh1]
   c4:6e:1f:40:9e:bc    0.850s (       16.7)  30:b5:c2:96:1b:9b [     mesh1]
   c4:6e:1f:40:9e:bc    0.850s (       36.5)  d4:6e:0e:c6:0e:e6 [     mesh1]
   c4:6e:1f:40:9e:bc    0.850s (       38.3)  f4:f2:6d:9b:f6:30 [     mesh1]
   c4:6e:1f:40:9e:bc    0.850s (       45.7)  c4:6e:1f:40:9e:bc [     mesh1]
   30:b5:c2:96:1b:9b    0.350s (       43.3)  d4:6e:0e:c6:0e:e7 [     mesh0]
   30:b5:c2:96:1b:9b    0.350s (       21.0)  e8:94:f6:d0:d1:bf [     mesh0]
 * 30:b5:c2:96:1b:9b    0.350s (       77.3)  30:b5:c2:96:1b:9c [     mesh0]
   30:b5:c2:96:1b:9b    0.350s (       47.9)  c4:6e:1f:40:9e:bd [     mesh0]
   30:b5:c2:96:1b:9b    0.350s (       45.7)  f4:f2:6d:9b:f6:31 [     mesh0]
   30:b5:c2:96:1b:9b    0.350s (       42.3)  c4:6e:1f:40:9e:bc [     mesh1]
   30:b5:c2:96:1b:9b    0.350s (       38.1)  f4:f2:6d:9b:f6:30 [     mesh1]
   30:b5:c2:96:1b:9b    0.350s (       22.7)  e8:94:f6:d0:d1:be [     mesh1]
   30:b5:c2:96:1b:9b    0.350s (       16.9)  30:b5:c2:96:1b:9b [     mesh1]
   30:b5:c2:96:1b:9b    0.350s (       37.2)  d4:6e:0e:c6:0e:e6 [     mesh1]
   e8:94:f6:d0:d1:be    0.020s (       41.7)  d4:6e:0e:c6:0e:e7 [     mesh0]
   e8:94:f6:d0:d1:be    0.020s (       20.9)  e8:94:f6:d0:d1:bf [     mesh0]
   e8:94:f6:d0:d1:be    0.020s (       39.2)  30:b5:c2:96:1b:9c [     mesh0]
   e8:94:f6:d0:d1:be    0.020s (       41.7)  f4:f2:6d:9b:f6:31 [     mesh0]
   e8:94:f6:d0:d1:be    0.020s (       41.7)  c4:6e:1f:40:9e:bd [     mesh0]
   e8:94:f6:d0:d1:be    0.020s (       17.0)  30:b5:c2:96:1b:9b [     mesh1]
   e8:94:f6:d0:d1:be    0.020s (       36.8)  d4:6e:0e:c6:0e:e6 [     mesh1]
   e8:94:f6:d0:d1:be    0.020s (       38.5)  f4:f2:6d:9b:f6:30 [     mesh1]
 * e8:94:f6:d0:d1:be    0.020s (       42.1)  c4:6e:1f:40:9e:bc [     mesh1]
   e8:94:f6:d0:d1:be    0.020s (       22.7)  e8:94:f6:d0:d1:be [     mesh1]

Osobną sprawą jest, czy to wszystko ma sens...

mar_w napisał/a:

Gdy leci przez 2 interfejsy radiowe to ma mniejszą szybkość niż gdy leci przez jedno radio 5GHz.
Jak sobie wybierze tak będzie  smile

Jak wynika z tego co pisało na tych stronach, które podlinkowałem, to lepiej powinno być jednak bez bonding. A ogólnie, to zestawienie sieci mesh na 5GHz oraz następnie konfiguracja AP na 2,4GHz wydaje się najrozsądniejszym rozwiązaniem. W takiej konfiguracji mesh nie współdzieli pasma z urządzeniami. A jak mamy dobry sprzęt, to dodatkowo wydajność mesha powinna wyraźnie przekraczać wydajność użytkowego wifi i powinno to wifi działać w miarę sprawnie.

Przetestowałem mojego mesha i kiedy działa tylko w jednym paśmie to klient końcowy (taki, który musi wykonać co najmniej 2 skoki, żeby dotrzeć do urządzenia podłączonego kablem do sieci) działa lepiej, gdy BATMAN korzysta tylko z jednego WiFi. Gdybym na końcu podłączył się kablem, to może byłoby lepiej, ale tak próbuję korzystać z sieci bezprzewodowej, która na tym samym kanale za chwilę przesyła moje dane przez zestawionego mesha. Dostępne pasmo jest współdzielone i na tym samym kanale smartfon przesyła dane do AP1, a potem AP1 do AP2. Możemy dodawać kolejne interfejsy w OpenWrt, ale wszystkie mają wspólną konfigurację radia (numer kanału i szerokość pasma).

C2v1 to faktycznie słabizna. 5GHz dość niestabilne. Żeby to działało byłem zmuszony wyłączyć AC/80MHz i ustawić N/40MHz w paśmie 5GHz. Szybkość jest niższa, ale połączenie jest stabilne. Niestety bez szyfrowania hmm Z szyfrowaniem działa, ale stabilność ... słaba sad Raz działa, raz nie sad

C7v5 zdaje się faktycznie ok. 160Mbit/s wyciągnął w meshu. Oczywiście z sąsiadem obok i tylko pojedynczym skokiem.

mar_w napisał/a:

Żeby jeszcze obsłużył NAT na konkretnym poziomie to ten brzegowy musi być niezły dzik big_smile

Po aktywacji "flow offloading" to już nie problem wink Nawet 1043ND daje radę, ale C7 czy ewentualnie R6220 są IMHO lepszym wyborem.

11 (edytowany przez mar_w 2021-07-07 22:18:51)

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

jest dokładnie tak jak piszesz.

Tylko że mesh bez szyfrowania to temat do dyskusji smile

U mnie sieć mesh tylko na 5Ghz "N" w WNDR4300v1 przy założeniu podobnych sygnałów jest szybsza niż postawiona tylko na 2,4GHz "N" (2x2) ponieważ działa w trybie 3x3.
Pewnie jakby radio 5GHz "N" było 2x2 to nie powinno być różnicy, bo 1x1 to 150 Mbps a 2x2 to 300Mbps (tyle samo co na 2,4GHz) a 3x3 to aż 450 Mbps.

Bonding miałby sens gdyby routery cały czas się przemieszczały i gdy sygnał jednego radia zanika, to sieć może cały czas pracować na sygnale z drugiego radia, aż do odcięcia bez potrzeby rekonfiguracji.
Ale skoro piszesz, że 2 meshe na jednym interfejsie "bat0" bez opcji bondingu chodzą dobrze i bez konfliktów na algorytmie BATMAN_V to w sumie ta opcja powinna być usunięta, bo w takim razie nie widzę dla niej zastosowania.

Routery zazwyczaj stoją w miejscu i dlatego warto wybrać i ustawić jedno radio do mesha a drugie dla klientów.
A najlepiej do tego celu mieć mocny procek, 2 fizyczne radia AC lub AX i jedno 2,4GHz smile
Dlatego wiadomo czemu np. w takim mesh-u jest procek 4 rdzeniowy: https://wikidevi.wi-cat.ru/Netgear_Orbi_Router_(RBR50)

co do "Flow offloading" to jest to jakieś rozwiązanie dla bieda-routerów, ale nie należy zapominać, że kastruje pewne funkcje, które są normalnie dostępne bez Flow....
Każdemu wg potrzeb.

Xiaomi AX3000T @ Netgear R6220
* DVBT2 - T230C *

12

Odp: Archer C2 + 802.11s = MESH-SAE-AUTH-FAILURE

mar_w napisał/a:

Tylko że mesh bez szyfrowania to temat do dyskusji smile

Już pisałem na to odpowiedź, ale nie widzę, więc chyba zapomniałem kliknąć "Wyślij"...

Sprawdzając tylko komputerem albo telefonem, to faktycznie nie miałem zdania.

Ale przypadkiem nacisnęło mi się skanowanie sieci w LuCI i ... ładnie wypisało, że jest mesh, na jakim kanale i że jest nieszyfrowany, więc podłączenie, to już tylko kilka kliknięć. Może nie każdy ma OpenWrt i potrafi się do tego podłączyć jak do zwykłej sieci nieszyfrowanej, ale bardziej obeznany nie będzie miał problemu z połączeniem.

Czyli: Lepiej poszukać sprzętu ze stabilnym radiem, czy też odpowiednio to radio skonfigurować ograniczając parametry na łączu w siatce niż zostawiać to nieszyfrowane.