Firmwarebäckerei: 1.4.0

wusel · 6. März 2023 um 23:33

Fortsetzung der Diskussion von In der Firmwarebäckerei:

AFAICS offene Punkte:

@m.bitterlich: »mein „Joy-IT JT-OR750i“ läßt sich seit Version 1.4.0~36 leider nicht mehr dazu überreden, Firmwareupdates durchzuführen [Quelle]
- Matthias, wie ist da der Stand? Mit 1.5.0 tut’s demnach?
@wusel: »Insgesamt 62 von gut 300 Knoten fahren mittlerweile 1.4.0~42 — AFAICS steht einem Push nach stable eigentlich nichts mehr im Wege?« [Quelle]
- Thomas fragte: @wusel willst du die 1.4er nach „stable“ rüber schubsen?
- Meine Antwort: Es gab’ noch ein paar Änderungen, die 1.4.0 ist nun auch die Migrations-Firmware für Freifunk-Bielefeld-Knoten. Ich schiebe die aktuelle rawhide noch mal bis testing, und dann schauen wir mal.

1.4.0~76 ist nun in rawhide, experimental & testing.

wusel · 7. März 2023 um 00:16

Der Patch von Freifunk Stuttgart wäre in 1.4.0~77 drin — @m.bitterlich, würdest Du damit den OR750i nochmals testen?

wusel · 12. Mai 2023 um 04:13

Hmm, ich sehe leider keinen Joy-IT OR750i mehr in der Statistik; hat den jemand außer @m.bitterlich (und mir, wobei derzeit nicht im Zugriff)?

Anyway: 1.4.0~97 ist für mich ein Release-Kandidat, da ist imho alles drin vom FFGT-Config-Mode über einen OWE-aware SSID-Changer und Nachtruhe-Modus und einem HT-Mode-Setting von VHT40 auf 5 GHz. (Gluon setzt generell nur 20 MHz; wir ändern das bei 5 GHz (802.11a/ac) über die site-Einstellungen für u. a. mehr Bandbreite, da 5-GHz-Geräte generell wenigstens 40 MHz unterstützen.)

Steuern läßt sich das lokal über uci set gluon.wireless.preserve_htmode='1' ; uci commit gluon, damit nicht mehr die Einstellungen aus der site.conf der Firmware übernommen werden, sofern lokale Werte gesetzt sind (analog uci set gluon.wireless.preserve_channels='1' ; uci commit gluon, um lokale Kanaleinstellungen über FW-Updates hinweg zu behalten) und die Einstellungen in gluon:

root@33332-Schalueckstr-107-afd6:~# uci show gluon | grep wireless
gluon.wireless=wireless
gluon.wireless.outdoor='0'
gluon.wireless.radio0_htmode='HT20'
gluon.wireless.radio1_htmode='VHT40'

Setzt man gluon.wireless.preserve_htmode auf 1, werden die Einträge gluon.wireless.radio*.htmode beim FW-Update konfiguriert, sofern vorhanden — ohne gluon.wireless.preserve_htmode werden die Einstellungen der site.conf (== netzweite Einstellungen) genommen (oder falls, trotz gluon.wireless.preserve_htmode==1, keine Werte gesetzte sind).

Inwiefern/wie gut wireless meshing zwischen unterschiedlichen HT-Modi funktioniert, muß noch eruiert werden; uci set gluon.wireless.preserve_channels='1' & Co. ist insofern eher dazu gedacht, erkannten Problem aus dem Weg zu gehen, bis sie in zukünftiger Firmware adressiert werden konnten.

Wer kann, bitte gerne auch den Weg durch den Config-Mode durchlaufen; am Ende sollte eine angpaßte Seite wie diese stehen:

Es wird dabei vorausgesetzt, daß info@${ssid} als Mailadresse existiert — i. d. R. paßt das, für alle unterstützten Netze müßte das noch mal gegengeprüft werden. Klickt man auf den Link, sollte das Erstellen-Fenster des Mailreaders aufgehen:

Nice2Have, aber ich gehe von <10 Prozent Clickrate aus.

Feature der Firmware: Trag. Einen. SSH-Key. Ein!

Da über dem Hostname positioniert, klickt man da hoffentlich häufiger rechtzeitig drauf … Latent muß auch die Hostname-Einstellung nach /admin wandern.

Also: bitte fleißig damit rumspielen, so sollte die User eXperience zukünftig sein.

m.bitterlich · 12. Mai 2023 um 12:27

Moin.
der Joy-IT ist aus, da die installierte FW keine Client-Verbindungen zuläßt.
Ich schalte ihn sofort ein, wenn ich wieder @home bin.

wusel · 12. Mai 2023 um 13:25

Ah, dann hat der 1.5.0 drauf? Wenn der schon 1.5 drauf hat, sollte ein „autoupdater -b tng“ ihn auf den aktuellen (funktionierenden) Stand bringen. Ciao, -kai

Thomas · 13. Mai 2023 um 19:38

Config Mode mit einem Frischen 1200er sah gut aus.

Habe aktuell auch einen Wifi Mesh Link über 5 GHz

trotz …

root@33378-a42bb0f43a87:~# uci show gluon | grep wireless
gluon.wireless=wireless
gluon.wireless.outdoor=›0‹
gluon.wireless.radio0_htmode=›VHT20‹
gluon.wireless.radio1_htmode=›HT20‹

root@33378-TH-Test1200:~# uci show gluon | grep wireless
gluon.wireless=wireless
gluon.wireless.outdoor=›0‹
gluon.wireless.radio0_htmode=›HT20‹
gluon.wireless.radio1_htmode=›VHT40‹

Ich werde heute Nacht einmal schauen ob der Link stabil bleibt. Werde morgen dann einmal den Hauptknoten auf VHT40 umstellen und schauen wie viel mehr an Bandbreite dadurch geht.

wusel · 13. Mai 2023 um 21:48

radio0 ist nicht immer 2,4 GHz, aber der Code setzt das nur bei 11a und 11ac. (Muß ich jetzt dann für 1.5 noch anpassen.)

Zu testen ist, ob und wie schnell ein Mesh über 5 GHz mit VHT20 auf der einen, VHT40 auf der anderen Seite ist, im Vergleich mit beiden Seiten VHT20 bzw. VHT40.

Thomas · 14. Mai 2023 um 07:40

Das mit radio1 und radio0 ist mir bekannt, dass sie unterschiedlich sein können.

Ich habe es jetzt einmal versucht durchzuführen.

Ich habe auf den 1200 Testknoten das 5GHz Client Netz deaktiviert und auf 2,4GHz die SSID geändert.
So das ich mit Sicherheit auf dem richtigen Knoten bin.

Es muss überings

root@33378-a42bb0f43a87:~# uci set wireless.radio0.htmode=›VHT40‹
root@33378-a42bb0f43a87:~# uci commit
root@33378-a42bb0f43a87:~# wifi

sein, ohne gluon. wire… (Hat mich beim ersten mal etwas in die Irre geführt. (Kontrolle über wifi status) - iwinfo zeigt ja leider erst in der 1.5er die Frequnzbreite an.

Ich konnte keine gravierenden Unterschiede fest stellen.

Ich habe jeweils nur eine Messung durch geführt. Deshalb würde ich die Differenzen jetzt auch normale Schwankungen zurück führen. Der 5 GHz Link geht durch eine Decke und einer Steinwand hindurch. (Sind halt Real Bedingungen und kein Laborumfeld). Beim nächsten mal werde ich den WAN Port mal als Client Port umkonfigurieren. (Dieser Steckdosen Adapter hat leider nur einen Port, und den wolte ich jetzt für die ersten Ergbenisse nicht erst Zeitaufwendig ändern.)

Im ganzen Sieht mir die komplette Firmware sehr Stabil aus. Evtl. kann ja nochmal wer den Config Mode Testen, Ich weiß nicht wie viel sich dort geändert hat, seit dem ich ihn das letzte mal in der 1.4er mit diversen eventualitäten durch getestet habe.

Sonst ab Richtung Testing mit der Version.

By the way, was mir aufgefallen ist:

root@33378-TH-Test1200:~# uci set wireless.client_radio1.disabled=1
root@33378-TH-Test1200:~# uci commit
root@33378-TH-Test1200:~# wifi

deaktiviert das WPA3 Client NEtz nicht auf dem jeweiligen Interface.

wusel · 14. Mai 2023 um 12:35

Ah, sorry, too few lines/explanations:

Die Settings im Gluon-Bereich der Konfiguration sorgen dafür, daß das nach einem gluon-reconfigure diese Werte geschrieben werden, nicht die aus der site.conf. DAMIT wird das upgradefest. Sprich: gluon.wireless… setzen, dann gluon-reconfigure laufen lassen, zuletzt ein wifi reload und feddich.

Nö, das heißt ja auch was mit ›owe‹ im Namen Aber der SSID-Changer sollte das mit ändern und Nachtruhe jenen AP ebenfalls ab-/anschalten.

Thomas · 14. Mai 2023 um 13:47

Ich musste WiFi ausführen damit ich in WiFi Status, eine Änderungen der Bandbreite gesehen habe. Reload alleine hatte ich auch erst getestet.

wusel · 16. Mai 2023 um 01:13

Setup:

Screenshot_Test-Setup

Auf dem 1.5er wurde Mesh-VPN deaktiviert (sonst hohe CPU-Last durch tunneldigger-syslog-Einträge, auf dem 1.4er WiFi-Mesh auf 2,4 GHz.

An beiden Freifunk-Knoten hängen Linuxe, und der Laptop hinter dem 1.5er 3600er macht …

root@ysabell:~# echo "Sending ..."; iperf3 -t 300 -c 2001:bf7:1322:17:a2ce:c8ff:fe5b:4714 | awk '/sender$/ {print $0;} /receiver$/ {print $0;}' ; echo ; echo "Receiving ..." ; iperf3 -R -t 300 -c 2001:bf7:1322:17:a2ce:c8ff:fe5b:4714 | awk '/sender$/ {print $0;} /receiver$/ {print $0;}'

Sprich: es wird iperf3 über das WiFi-Mesh genutzt.

1.4.0~101 (VHT40) <=> 1.5.0~99 (VHT40):

iwinfo:

root@33332-FW-Test-1-4-0:~# iwinfo 
[…]
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 0A:BF:54:CB:78:8D
          Mode: Mesh Point  Channel: 44 (5.220 GHz)
          Tx-Power: 19 dBm  Link Quality: 64/70
          Signal: -46 dBm  Noise: -89 dBm
          Bit Rate: 300.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11an
          Hardware: 168C:0033 168C:A120 [Atheros AR9580]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
[…]

root@33332-Schalueckstr-107-afd6:~# iwinfo 
[…]
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 22:C5:E3:28:9B:A5
          Mode: Mesh Point  Channel: 44 (5.220 GHz)  HT Mode: HT40
          Center Channel 1: 46 2: unknown
          Tx-Power: 15 dBm  Link Quality: 59/70
          Signal: -52 dBm  Noise: -92 dBm
          Bit Rate: 270.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11a/n
          Hardware: 168C:0033 168C:A120 [Atheros AR9580]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
[…]

Ergebnis:

Sending ...
[  5]   0.00-300.00 sec  2.42 GBytes  69.2 Mbits/sec  310             sender
[  5]   0.00-300.07 sec  2.42 GBytes  69.2 Mbits/sec                  receiver

Receiving ...
[  5]   0.00-300.04 sec  1.73 GBytes  49.4 Mbits/sec  7401             sender
[  5]   0.00-300.00 sec  1.73 GBytes  49.4 Mbits/sec                  receiver

Bemerkenswert: beide 3600er gehen auf 0% idle im top -d 2 zurück und auf über 80% Soft-IRQs hoch.

1.4.0~101 (VHT40) <=> 1.5.0~99 (VHT20):

iwinfo:

root@33332-FW-Test-1-4-0:~# iwinfo 
[…]
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 0A:BF:54:CB:78:8D
          Mode: Mesh Point  Channel: 44 (5.220 GHz)
          Tx-Power: 15 dBm  Link Quality: 66/70
          Signal: -44 dBm  Noise: -89 dBm
          Bit Rate: 144.4 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11an
          Hardware: 168C:0033 168C:A120 [Atheros AR9580]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
[…]

root@33332-Schalueckstr-107-afd6:~# iwinfo 
[…]
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 22:C5:E3:28:9B:A5
          Mode: Mesh Point  Channel: 44 (5.220 GHz)  HT Mode: HT20
          Center Channel 1: 44 2: unknown
          Tx-Power: 15 dBm  Link Quality: 56/70
          Signal: -54 dBm  Noise: -93 dBm
          Bit Rate: 144.4 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11a/n
          Hardware: 168C:0033 168C:A120 [Atheros AR9580]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
[…]

Ergebnis:

Sending ...
[  5]   0.00-300.00 sec  1.77 GBytes  50.6 Mbits/sec   87             sender
[  5]   0.00-300.04 sec  1.76 GBytes  50.5 Mbits/sec                  receiver

Receiving ...
[  5]   0.00-300.04 sec  1.47 GBytes  42.0 Mbits/sec  12927             sender
[  5]   0.00-300.00 sec  1.47 GBytes  42.0 Mbits/sec                  receiver

Nur noch 40-60% Soft-IRQ …

Neuere HW

Ich habe dann 33332-FW-Test-1-4-0 (TP-Link TL-WDR3600 v1) gegen 33332-Schalueckstr-107-5c70 (TP-Link Archer C6 v2 (EU/RU/JP)) getauscht, 2,4, GHz-Mesh abgeschaltet und auf beiden Seiten auf VHT40 gestellt:

iwinfo:

root@33332-Schalueckstr-107-5c70:~# iwinfo 
[…]
mesh0     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 52:B2:D2:F9:45:E1
          Mode: Mesh Point  Channel: 44 (5.220 GHz)  HT Mode: HT40
          Center Channel 1: 46 2: unknown
          Tx-Power: 23 dBm  Link Quality: 70/70
          Signal: -39 dBm  Noise: -106 dBm
          Bit Rate: 123.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 168C:0056 0000:0000 [Qualcomm Atheros QCA9886]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0
[…]

root@33332-Schalueckstr-107-afd6:~# iwinfo
[…]
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 22:C5:E3:28:9B:A5
          Mode: Mesh Point  Channel: 44 (5.220 GHz)  HT Mode: HT40
          Center Channel 1: 46 2: unknown
          Tx-Power: 15 dBm  Link Quality: 66/70
          Signal: -44 dBm  Noise: -92 dBm
          Bit Rate: 270.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11a/n
          Hardware: 168C:0033 168C:A120 [Atheros AR9580]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
[…]

Ergebnis:

Sending ...
[  5]   0.00-300.00 sec  2.27 GBytes  65.0 Mbits/sec  9157             sender
[  5]   0.00-300.04 sec  2.27 GBytes  65.0 Mbits/sec                  receiver

Receiving ...
[  5]   0.00-300.05 sec  2.36 GBytes  67.7 Mbits/sec  400             sender
[  5]   0.00-300.00 sec  2.36 GBytes  67.7 Mbits/sec                  receiver

Noch neuere HW

33332-Schalueckstr-107-afd6 weicht 33332-Testnode-c3a7, einer 4040. VHT40, Mesh nur auf 5 GHz. Leider verlor der C5 immer wieder den Link zur 4040.

iwinfo:

root@33332-Schalueckstr-107-5c70:~# iwinfo mesh0 info
mesh0     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 52:B2:D2:F9:45:E1
          Mode: Mesh Point  Channel: 44 (5.220 GHz)  HT Mode: HT40
          Center Channel 1: 46 2: unknown
          Tx-Power: 23 dBm  Link Quality: 67/70
          Signal: -43 dBm  Noise: -106 dBm
          Bit Rate: 300.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 168C:0056 0000:0000 [Qualcomm Atheros QCA9886]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

root@33332-Testnode-c3a7:~# iwinfo mesh1 info
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 6E:AA:42:F2:B8:65
          Mode: Mesh Point  Channel: 44 (5.220 GHz)
          Tx-Power: 23 dBm  Link Quality: 63/70
          Signal: -47 dBm  Noise: -106 dBm
          Bit Rate: 400.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1

Ergebnis:

Sending ...
[  5]   0.00-300.00 sec  3.69 GBytes   106 Mbits/sec  10349             sender
[  5]   0.00-300.10 sec  3.68 GBytes   105 Mbits/sec                  receiver
Min/Max: 0.0/147.0 MBit/sec

Receiving ...
…

Zum Vergleich, beidseitig VT20 im 2,4-GHz-Band:

iwinfo:

root@33332-Schalueckstr-107-5c70:~# iwinfo mesh1 info
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 52:B2:D2:F9:45:E5
          Mode: Mesh Point  Channel: 5 (2.432 GHz)  HT Mode: HT20
          Center Channel 1: 5 2: unknown
          Tx-Power: 20 dBm  Link Quality: 68/70
          Signal: -42 dBm  Noise: -84 dBm
          Bit Rate: 144.4 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: 168C:0033 168C:9560 [Qualcomm Atheros QCA9560]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

root@33332-Testnode-c3a7:~# iwinfo mesh0 info
mesh0     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 6E:AA:42:F2:B8:61
          Mode: Mesh Point  Channel: 5 (2.432 GHz)
          Tx-Power: 20 dBm  Link Quality: 58/70
          Signal: -52 dBm  Noise: -93 dBm
          Bit Rate: 144.4 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy0

Ergebnis:

Sending ...
[  5]   0.00-300.00 sec  2.72 GBytes  77.9 Mbits/sec  7760             sender
[  5]   0.00-300.05 sec  2.72 GBytes  77.8 Mbits/sec                  receiver
Min/Max: 10.5/94.4 MBit/sec

Receiving ...
[  5]   0.00-300.04 sec  2.71 GBytes  77.6 Mbits/sec  608             sender
[  5]   0.00-300.00 sec  2.71 GBytes  77.6 Mbits/sec                  receiver
Min/Max: 28.4/91.5 MBit/sec

wusel · 16. Mai 2023 um 01:26

Das sah dann so aus:

root@33332-Schalueckstr-107-5c70:~# date ;iwinfo mesh0 info
Tue May 16 03:25:18 CEST 2023
mesh0     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 52:B2:D2:F9:45:E1
          Mode: Mesh Point  Channel: unknown (unknown)  HT Mode: NOHT
          Center Channel 1: unknown 2: unknown
          Tx-Power: 23 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -106 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 168C:0056 0000:0000 [Qualcomm Atheros QCA9886]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

vs.

root@33332-Testnode-c3a7:~# date ; iwinfo mesh1 info
Tue May 16 03:25:19 CEST 2023
mesh1     ESSID: "17:47:de:ca:fb:ad"
          Access Point: 6E:AA:42:F2:B8:65
          Mode: Mesh Point  Channel: 44 (5.220 GHz)
          Tx-Power: 23 dBm  Link Quality: 69/70
          Signal: -41 dBm  Noise: -105 dBm
          Bit Rate: 400.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy1

wusel · 21. Mai 2023 um 15:25

Des Rätsels Lösung: es gibt einen Bug in der Behandlung von mehreren in einem Funk-Paket übertragenen Datenpaketen — ohne ins Detail gehen zu wollen, betrifft das MediaTek-Geräte und der Bug liegt wohl im OpenWrt-Code (mir ist noch unklar, ob auch schon bei OpenWrt 19 oder erst ab OpenWrt 21). Atheros-Geräte teilen diese Mehrfachpakete – wenn ich das richtig verstanden habe – wohl in der Hardware schon auf, MediaTek kann das nicht.

Die 1.5er FW hat nun einen groben Patch drin, der diesen Übertragungsmodus generell verbietet, sodaß auch MT-Geräte nun wieder »schneller« emfangen. Damit kann ich das »C5-Problem« auch nicht mehr nachstellen.

Testsetup als Grafik:

Für Firmware 1.4 sollte das also kein Problem darstellen, was wir in/bis 1.5 nicht lösen können. (1.5 hat auch noch andere Unzulänglichkeiten gezeigt, OpenWrt 22 ist nicht wirklich witzig …)

Kurzum: ich würde die 1.4.0, die ja schon bis testing ausgerollt ist, dieserr Tage dann nach stable pushen wollen. Gegenstimmen?

wusel · 24. Mai 2023 um 20:35

FTR: Karte ist aktualisiert (Deprecation Warning) und Firmware 1.4.0 rollt als stable aus.

wusel · 30. Mai 2023 um 21:53

Praktisch abgeschlossen:

Zeitlicher Verlauf:

wusel · 6. Juni 2023 um 21:59

Es hat sich herausgestellt, daß OpenWrt 19.07/Gluon v2021.1.x kein Mesh auf DFS-Kanälen untertützt (tat mal, geht in OpenWrt schein’s immer mal wieder kaputt ). FW 1.4 wird also noch ein paar Inkarnationen bekommen …

m.bitterlich · 7. Juni 2023 um 09:36

Ich hatte gerade ein Problem mit der Installation bei uns in der Verwaltung …
Einige Clients bekamen kein IPv4 zugwiesen und ein Neustart von 17192-Stadtverwaltung-Waren und der APs, die hier im Haus die SSID verteilen, brachte keine Besserung. IPv6 lief ohne Probleme. Anfangs sah es aus, als ob 5GHz das verursacht und habe auf den APs nur 2,4GHz für Freifunk erlaubt … das war’s dann auch nicht.
Erst das Update auf die Firmware 1.4.0~108 brachte die Clients im Haus in die Lage, sich mit Freifunk sauber zu verbinden. In den anderen Häusern mit ähnlicher Installation war dieses Problem nicht.

Jetzt noch eine Frage … Ist heute zufällig etwas am Netz gemacht worden oder kann es doch an der FW liegen?

cul8er
Matthias

wusel · 7. Juni 2023 um 09:58

Puh. Gezielt gemacht wurde AFAIK am Netz nix. Müritz liegt, wie andere Meshes auch, aber noch arg verteilt, über FRA, DUS & 2x BER:

wusel@cohen:~$ host g01m05.4830.org
g01m05.4830.org is an alias for l2tp-fra01.4830.org.
l2tp-fra01.4830.org has address 193.26.120.227
l2tp-fra01.4830.org has IPv6 address 2a06:e881:1707:1:400:c1ff:fe1a:78e3
wusel@cohen:~$ host g02m05.4830.org
g02m05.4830.org is an alias for l2tp-dus02.4830.org.
l2tp-dus02.4830.org is an alias for l2tp-gut02.4830.org.
l2tp-gut02.4830.org has address 192.251.226.125
l2tp-gut02.4830.org has IPv6 address 2a06:e881:1700:1:400:c0ff:fefb:e27d
wusel@cohen:~$ host g03m05.4830.org
g03m05.4830.org is an alias for l2tp-ber01.4830.org.
l2tp-ber01.4830.org has address 193.26.120.99
l2tp-ber01.4830.org has IPv6 address 2a06:e881:1706:1:0:c1ff:fe1a:7863
wusel@cohen:~$ host g04m05.4830.org
g04m05.4830.org is an alias for l2tp-ber02.4830.org.
l2tp-ber02.4830.org has address 193.26.120.104
l2tp-ber02.4830.org has IPv6 address 2a06:e881:1706:1:0:c1ff:fe1a:7868

Kann natürlich sein, daß ein GW da bei IPv4/DHCP-Anfragen unpäßlich war — vom Knoten aus können wir das nicht testen, eigentlich braucht’s dafür Test-Clients, deren vorgeschaltete Knoten die GWs selektiv an- und abwählen …

wusel · 7. Juni 2023 um 22:21

FTR: 1.4.0~108 ist leider ein Fauxpas: in der FW fehlen etliche Pakete aufgrund meines Fehlers in der Änderung der site.mk

Die aktuelle rawhide-Version ist 1.4.0~113, und hier ist die primäre Änderung, daß ar71xx-tiny (841 & Co.) wie bisher eine Dummy-Implementation von wpa-supplicant an Bord haben (die für eine Verbindung zu einem unverschlüsselten WLAN reicht — ausreichend für tecff-autoupdater-wifi-fallback), alle anderen Builds den vollen wpa-supplicant[-openssl]. Heißt: sowohl 841- als auch »normale« Images müssen noch einmal bzgl. »autoupdater-wifi-fallback« getestet werden …

wusel · 8. Juni 2023 um 13:51

Non-841 sieht gut aus, hatte den 3600 mit 1.4.0~113 auf Lüneburg gestellt und das WAN getrennt, sodaß ihm nur Autoupdate-per-WiFi blieb:

  OS: 19.07-SNAPSHOT, r11430+27-ecbbb3    FW: 1.4.0~114                       
  HW: TP-Link TL-WDR3600 v1                                               

root@33332-wdr3600-v2021-afd6:~# uptime
 15:41:19 up 11:41,  load average: 1.60, 1.22, 0.64
root@33332-wdr3600-v2021-afd6:~# date
Thu Jun  8 15:41:23 CEST 2023
root@33332-wdr3600-v2021-afd6:~# /lib/gluon/ffgt-geolocate/get_domain_name.sh $(uci get gluon.core.domain)
Freifunk Lüneburg

Same goes for 841v9:

  OS: 19.07-SNAPSHOT, r11430+27-ecbbb3    FW: 1.4.0~114                       
  HW: TP-Link TL-WR841N/ND v9                                             
root@fflg-e894f6a4776a:~# uptime
 15:47:31 up 12:34,  load average: 2.07, 0.95, 0.41
root@fflg-e894f6a4776a:~# /lib/gluon/ffgt-geolocate/get_domain_name.sh $(uci get gluon.core.domain)
Freifunk Lüneburg

Vier Augen sehen mehr als zwei, daher würde ich gerne noch jemanden testen sehen, ob ein 1.4.0~113-Knoten (im rawhide-Branch!) sich auf >1.4.0~113 ohne WAN & ohne Mesh aktualisieren kann. Dazu muß ein offenes WLAN mit »Freifunk« im Namen in der Nähe ausgestrahlt werden und dieses WLAN muß öffentlichen IPv6-Zugang haben (die Knoten suchen die Firmware auf http://firmware.ipv6.4830.org/).