wifi mesh 802.11s
Es funktioniert (Variante wpad-mesh-openssl). Angeblich funktioniert Adhoc+802.11 auf Netgear R6220
TODO:
- GUI Soll erweitert werden: ADHOC only, ADHOC+802.11s, 802.11s only
- Da wir OpenSSL nehmen, müssen wir über mbedtls nachzudenken. Es sieht aber dann Blasen ohne ende: uhttpd, openvpn etc. @stephan Wie gehen wir vor ?
Activity
changed milestone to %Firmware 6.1.0
added enhancement / feature + 1 deleted label
mentioned in merge request !13 (closed)
changed milestone to %Firmware 6.4.x (802.11s - mesh)
openssl nur für 802.11s nutzen, alle anderen Tools nutzen weiterhin mbedtls. damit ist das in tiny und große Geräten gleich und bringt unser Verständnis nicht durcheinander. wichtiger ist aber, das wir gleiches verhalten bei rund und generic haben und nicht versteckten Probleme rein bringen.
eine GUI würde ich nicht machen, sondern generell immer ad-hoc und 802.11s aktiv haben. denn sonst stellt dein Nachbar daran herum und Knoten verlieren dann Verbindung. ist ja auch nicht nötig. ich sehe da keinen Vorteil,eher Nachteile.
mentioned in issue #37 (closed)
-
freifunk@devel:~/firmware/feeds$> [yaro-comfast-info]> ls 18.06 19.07 19.07.lomem [yaro-comfast-info]> ./build.sh list ------------------------------------------------------------------------------------------------- target | wrt_rev | wrt_var | config | feeds | files | patches --------------------------------------+---------+---------+---------+---------+---------+-------- ar71xx.tiny.lowmem | f6de1fa | lowmem | 18.06 | 18.06 | | 18.06 ar71xx.generic.lowmem | f6de1fa | lowmem | 18.06 | 18.06 | | 18.06 ar71xx.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ar71xx.generic.gl-mifi | c56ed72 | | 19.07 | 19.07 | | 19.07 ar71xx.nand | c56ed72 | | 19.07 | 19.07 | | 19.07 x86.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 x64.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ramips.mt7621.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ramips.mt7621.ubiquiti-edgerouter-x | c56ed72 | | 19.07 | 19.07 | | 19.07 ramips.mt76x8.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ramips.lantiq.xrx200 | c56ed72 | | 19.07 | 19.07 | | 19.07 sunxi.cortexa7.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ath79.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ath79.generic.lomem | c56ed72 | lowmem | 19.07 | 19.07.lowmem | | 19.07 ipq40xx.generic | c56ed72 | | 19.07 | 19.07 | | 19.07 ------------------------------------------------------------------------------------------------- assigned to @lankaster and unassigned @stephan
mentioned in issue #10 (closed)
mentioned in issue #36 (closed)
@stephan Vorschlag: 801.11s zu erst testweiser nur für 5GHz aktivieren. Dazu ein paar große strecken mit Comfast Geräten ( sehe #36 (closed) ) testen
"ad-hoc oder 801.11s sind nur für 2.4ghz möglich" Mein Router hat aber andere Meinung:
root@OpenWrt:~# iw dev mesh0 info Interface mesh0 ifindex 12 wdev 0x100000003 addr cc:40:d0:a7:f6:6c type mesh point wiphy 1 channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz txpower 17.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 12 0 0 0 0 1608 12 root@OpenWrt:~# iw dev mesh0 station dump Station 54:64:d9:01:ce:25 (on mesh0) inactive time: 90 ms rx bytes: 4778788468 rx packets: 56890337 tx bytes: 582 tx packets: 3 tx retries: 0 tx failed: 1 rx drop misc: 770 signal: -61 [-61, -66] dBm signal avg: -61 [-61, -66] dBm tx bitrate: 6.5 MBit/s VHT-MCS 0 VHT-NSS 1 rx bitrate: 6.0 MBit/s rx duration: 57793 us mesh llid: 0 mesh plid: 0 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: UNKNOWN mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes associated: yes preamble: long WMM/WME: yes MFP: yes TDLS peer: no DTIM period: 2 beacon interval:100 connected time: 2935655 seconds Station 50:c7:bf:0c:c8:a7 (on mesh0) inactive time: 100 ms rx bytes: 4798435370 rx packets: 57124227 tx bytes: 1838758 tx packets: 57442 tx retries: 8652 tx failed: 2 rx drop misc: 772 signal: -72 [-83, -72] dBm signal avg: -71 [-82, -71] dBm tx bitrate: 108.0 MBit/s VHT-MCS 3 40MHz VHT-NSS 2 rx bitrate: 6.0 MBit/s rx duration: 57605 us expected throughput: 40.191Mbps mesh llid: 0 mesh plid: 0 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: UNKNOWN mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes associated: yes preamble: long WMM/WME: yes MFP: yes TDLS peer: no DTIM period: 2 beacon interval:100 connected time: 2935514 secondsWahrscheinlich hier kommt eine missverstandniss:
-
Ich möchte auf Routern mit 2.4 Ghz und 5 Ghz auf 2.4 adhoc lassen und auf 5 Ghz 802.11s aktivieren: So bald ein Router in die Wolke über 5Ghz besseres Signal bekommt, fängt der über 5 Ghz statt 2.4Ghz zu kommunizieren. 2.4Ghz wird dann "Backup" Leitung
-
Für Langstrecken setzen wir gerade 5Ghz mit stock Firmware, also mehr als 2 Geräte bei 5Ghz Strecken kommen gar nichts in die Frage. Also Hier schlage ich vor langfristig auf FF Firmware mit 802.11s umzusteigen um mehrere Clients zu ermöglichen. Weritere Vorteil, so bald ein Router mit 2.4Ghz und 5 Ghz mit so einen Router sich verbindet, fängt der per 2.4Ghz mit "2.4Ghz only" Geräten zu kommunizieren.
Langfristig gesehen, sollten wir auf Geräten mit 2.4+5Ghz umsteigen.
-
"im Outdoor wechseln Kanäle spontan" ?? Ich dachte wir haben 44 Kanal ( https://gitlab.freifunk-dresden.de/firmware-developer/firmware/blob/master/files/common/usr/lib/ddmesh/ddmesh-bootconfig.sh#L100 )
-
der Kanal 44 oder 48 sind Indoor Kanäle und dürfen nur drin verwendet werden. willst du draußen Strecken überbrücken, musst du Outdoor Kanäle nutzen. alle Outdoor Kanäle, müssen die Radar Erkennung besitzen. diese sorgt für ständigen Kanalwechsel. das machen die Treiber oder sogar die Firmware von WLAN Chip selbst. wird ein Radar Signal erkannt, so wird dem anderen Router oder Endgerät, ein neuer Kanal mitgeteilt. das geht in beide Richtungen. ein Kanal, wo ein Radar Signal (Wetter, Flugzeug) gesehen wurde, wird für mehrere Minuten gesperrt.
bei nur 2 Routern wäre das kein Problem. wenn dann aber welche dazu kommen (was wir nicht Kontrollieren können, brechen Verbindungen weg)
Zusammenfassung der 5 GHz Diskussion (Sprechstunde vom 23.09.2020)
Vorschlag zur gesetzeskonformen Umsetzung von 5GHz WLAN: Zwei Modi:
-
Outdoor (Standard):
- Access Point mit Autokanal (Bereich 100 - 140) mit DFS
- kein Mesh
-
Indoor (manuelles einschalten, Nutzer trägt Verantwortung):
- Access Point mit festem Kanal 44
- Mesh 802.11s mit festem Kanal 44
-
