Offline von stable zu rawhide/tng (Vorbereitung fastd -> L2TP)

**wusel** · 18. September 2020 um 20:17

Moin,

mein Test-841 v8 ist erfolgreich binnen einer Nacht »offline« (kein WAN, kein Meshpartner im WLAN) von 1.0.1~6 (stable) nach 1.1.2~43 (rawhide) im Müritzer Netz aktualisiert worden. Es läuft nun noch ein Test zur Verifikation (rawhide => tng, 1.1.5~23).

Wäre klasse, wenn das jemand an der Müritz/in Feldberg ebenfalls noch mal probieren würde; Voraussetzung ist zweiter Knoten mit Uplink in Funkreichweite, der normal im Mesh funktioniert.
Vorbereitung auf dem Testknoten wie folgt:

Testnoten auf aktuelle stable-FW downgraden, falls notwendig (ssh-Zugang einrichten nicht vergessen)

Testknoten auf ‘rawhide’-Zweig zwingen:

root@17258-FW-Test-4830-b9d0:~# sed -e "s/option branch .*$/option branch 'rawhide'/g" -i /etc/config/autoupdater

Testknoten im WLAN isolieren und neu starten:

root@17258-FW-Test-4830-b9d0:~# sed -e 's/00:21:de:ca:fb:ad/de:ca:fb:ad:20:20/g' -i /etc/config/wireless 
root@17258-FW-Test-4830-b9d0:~# reboot

Sofern vorhanden, WAN-Verbindung des Testknotens jetzt kappen

Damit ist der Knoten isoliert und sollte nach ein paar Stunden versuchen, sich als Client über den anderen Freifunk-Knoten mit dem Netz zu verbinden und dann ein Autoupdate auf die aktuelle »rawhide«-Firmware durchzuführen. (Falls der andere Freifunk-Knoten schon auf »tng« läuft, bitte entsprechend oben »rawhide« durch »tng« ersetzen; die Mesh-SSIDs sind unterschiedlich.)

Ergebnis sollte sein, daß der Testknoten nach ~1 Tag als Meshknoten wieder auf der Karte (wg. Legacy/TNG am besten newmap.4830.org nehmen) und als online gelistet wird.

**wusel** · 4. Juni 2020 um 20:09

Hat bislang nicht funktioniert, aber das Netz war ja auch den größten Teil des Tages ausgeknipst

**wusel** · 18. September 2020 um 01:58

So, dankenswerterweise hat ein Gluon-Mitentwickler sich des Themas angenommen und wohl das Problem gefunden.

wg 1.1.6~6, tng 1.1.5~32 und rawhide 1.1.2~49 haben die entsprechenden Fixes. Bitte diese FW mal auf Knoten installieren und diese “isolieren” (ggf. in /etc/config/wireless die Mesh-SSID ändern), aber im Update-Pfad belassen (wg/tng/rawhide). Wenn’s klappt, müßten die Knoten sich auf 1.1.6~7, 1.1.5~33 bzw. 1.1.2~50 aktualisieren.

**wusel** · 18. September 2020 um 20:18

Sieht gut aus:

  OS: 18.06-SNAPSHOT, r7945+26-83ce31d    FW: 1.1.2~49                        
  HW: TP-Link TL-WR841N/ND v9                                             
root@33332-Schalueckstr-AZ1:~# iwinfo 
client0   ESSID: "KreisGT.freifunk.net"
[…]

Mon Sep 14 16:27:10 2020 user.info : autoupdater-wifi-fallback: connecting to radio0 muenchen.freifunk.net/welt 5E:71:CF:F9:41:80
[…]
Mon Sep 14 16:27:15 2020 daemon.notice netifd: Interface 'fallback6' is enabled
Mon Sep 14 16:27:15 2020 daemon.notice netifd: Network alias 'fallback' link is up
Mon Sep 14 16:27:15 2020 daemon.notice netifd: Interface 'fallback6' has link connectivity
Mon Sep 14 16:27:15 2020 daemon.notice netifd: Interface 'fallback6' is setting up now
Mon Sep 14 16:27:15 2020 daemon.notice netifd: Interface 'fallback' is now up
Mon Sep 14 16:27:15 2020 daemon.info dnsmasq[888]: reading /tmp/resolv.conf.auto
Mon Sep 14 16:27:15 2020 daemon.info dnsmasq[888]: using local addresses only for domain lan
Mon Sep 14 16:27:15 2020 daemon.info dnsmasq[888]: using nameserver 10.80.200.8#53
Mon Sep 14 16:27:15 2020 user.notice firewall: Reloading firewall due to ifup of fallback (fallback)
Mon Sep 14 16:27:19 2020 daemon.notice netifd: Interface 'fallback6' is now up
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: reading /tmp/resolv.conf.auto
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: using local addresses only for domain lan
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: using nameserver 10.80.200.8#53
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: using nameserver 2001:608:a01::40#53
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: using nameserver 2001:608:a01::41#53
Mon Sep 14 16:27:19 2020 daemon.info dnsmasq[888]: using nameserver 2001:608:a01::42#53
Mon Sep 14 16:27:19 2020 user.notice firewall: Reloading firewall due to ifup of fallback6 (fallback)
[…]
Mon Sep 14 16:27:36 2020 user.info : autoupdater-wifi-fallback: executing the autoupdater...
Mon Sep 14 16:27:38 2020 daemon.err haveged[846]: haveged: Stopping due to signal 15
Mon Sep 14 16:27:38 2020 daemon.err haveged[846]:
Mon Sep 14 16:27:39 2020 kern.info kernel: [15328.343159] sysctl (18511): drop_caches: 3
[…]

  OS: 18.06-SNAPSHOT, r7945+26-83ce31d    FW: 1.1.2~50                        
  HW: TP-Link TL-WR841N/ND v9                                             
root@33332-Schalueckstr-AZ1:~#

Bitte gerne also die Tests jetzt mit der entsprechende Legacy- oder TNG-Version (TNG: 1.1.5~32; rawhide: 1.1.2~49) als Ausgangs-Firmware wiederholen, der Knoten sollte dann sich binnen ~5 Stunden auf die letzte aktualisieren.

**Echo** · 18. September 2020 um 22:11

Prima. Ich teste morgen.

**wusel** · 18. September 2020 um 22:53

Bedankt.

**Thomas** · 19. September 2020 um 05:49

Ich kann leider gerade nicht testen. Werde es sobald die Möglichkeit wieder da ist machen.

**Echo** · 19. September 2020 um 08:22

Da sich meine 4040 nicht auf die ~34 aktualisiert hat, habe ich das Update manuel durchgeführt.

  OS: 18.06-SNAPSHOT, r7945+26-83ce31d    FW: 1.1.5~31
  HW: AVM FRITZ!Box 4040
root@33332-Buschkoettersweg-63-a86c:~# autoupdater
Retrieving manifest from http://firmware.ipv6.4830.org/tng/sysupgrade/tng.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found

Hmm. Da klemmt noch was.

  OS: 18.06-SNAPSHOT, r7945+26-83ce31d    FW: 1.1.5~34
  HW: AVM FRITZ!Box 4040
root@33332-Buschkoettersweg-63-a86c:~# autoupdater
Retrieving manifest from http://firmware.ipv6.4830.org/tng/sysupgrade/tng.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
root@33332-Buschkoettersweg-63-a86c:~# cd /tmp
root@33332-Buschkoettersweg-63-a86c:/tmp# wget http://firmware.ipv6.4830.org/tng/sysupgrade/tng.manifest
Downloading 'http://firmware.ipv6.4830.org/tng/sysupgrade/tng.manifest'
Failed to establish connection

root@33332-Buschkoettersweg-63-a86c:/# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-9, MainIF/MAC: primary0/72:ac:8e:b6:27:43 (bat0/cc:ce:1e:34:a8:6c BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:01:05 (225) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:11 (225) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:01:10 (255) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:02 (225) 02:ca:ff:ee:01:10 [  mesh-vpn]: 1024.0/1024.0 MBit

**wusel** · 19. September 2020 um 08:45

Hmm. Bitte parallel checken, ob – insbesondere bei TNG –, das Netz generell tut. Also mit Handy rein und z. B. mal v6.de ansurfen: funktionieren beide IP-Versionen?

**Echo** · 19. September 2020 um 10:53

v6.de geht über TNG. Speedtest App meldet Plusserver anstelle von Kai.

root@33332-Buschkoettersweg-63-2dbc:~# autoupdater
Retrieving manifest from http://firmware.ipv6.4830.org/stable/sysupgrade/stable.manifest ...
No new firmware available.

Der 841 kann über seine direkte Verbindung prüfen. Ist dann classic Freifunk.

**wusel** · 19. September 2020 um 14:52

Ich guck’s mir gleich Mal von Unterfranken aus an …

**wusel** · 19. September 2020 um 15:57

root@l2tp-gut01 ~ # ps -Aelf | grep -i dhc
0 S root     19493 19424  0  80   0 -  3518 pipe_w 17:53 pts/0    00:00:00 grep -i dhc
root@l2tp-gut01 ~ # systemctl restart isc-dhcp-server
root@l2tp-gut01 ~ # ps -Aelf | grep -i dhc
4 S dhcpd    19496     1  4  80   0 - 12493 poll_s 17:53 ?        00:00:00 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
0 S root     19502 19424  0  80   0 -  3518 pipe_w 17:53 pts/0    00:00:00 grep -i dhc

Also sterbende isc-dhcpd sind wohl ein generelles Problem

Ein anderes ist wohl v6:

root@97270-Am-Rosengarten-f24d:~# traceroute google.com
traceroute to google.com (2a00:1450:4001:81e::200e), 30 hops max, 64 byte packets
 1  2001:bf7:1310:666::5 (2001:bf7:1310:666::5)  63.575 ms  67.880 ms  73.106 ms
 2  *  *  *
 3  *  *  *
 4  *

root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:666::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:128::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
 1  2001:bf7:1310:128::a (2001:bf7:1310:128::a)  19.260 ms  19.279 ms  19.207 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:176::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
 1  2001:bf7:1310:176::a (2001:bf7:1310:176::a)  42.408 ms  42.390 ms  42.347 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Da muß ich dann wohl heute abend 'bei …

**wusel** · 20. September 2020 um 00:21

Yepp, v6 ist broken …

… zumindest bei zzz. Ich werde die L2TP-Gateways wohl mal komplett neu machen auf Basis der aktuellen Ansible-Rollen.

Edit: Legacy tut aber