Netzupdate läuft


(Kai 'wusel' Siering) #1

Orginaler Blog-Post: https://freifunk-kreisgt.de/netzupdate-laeuft/

Das angekündigte »Zwischenupdate« als Vorbereitung auf Firmware 1.0 rollt durchs Netz.

Wie im alten Jahr angekündigt, updaten sich derzeit auch alle auf den Firmwarestand »stable« konfigurierten Freifunkknoten nach erfolgreicher »testing«-Phase über den Jahreswechsel — bzw. sollten sich mit der Veröffentlichung dieses Beitrags aktualisiert haben:

Um auf Nummer Sicher zu gehen, gibt es, quasi als Weihnachtsgeschenk, eine neue Version der 0.7.9er Firmware, die die letzten Patches der Gluon-v2016.2.7er-Reihe beinhaltet und somit als Brückenbauer u. a. für die CPE dienen kann.
Ein Problem können wir aber leider nicht per Firmwareupdate fixen:
Another potential issue mostly affects virtual machines: Gluon 2017.1 images are bigger than 2016.2.x images on x86. If your virtual harddisk is based on a 2016.2.x image, it must be resized to 273MB or bigger before upgrading to Gluon 2017.1. Using qemu, the command
qemu-img resize $IMAGE 273MB
can be used to do this.

Sprich, alle VMs benötigen eine größere virtuelle Festplatte für eine Version jenseits Firmware 0.7.9 (Gluon v2016.2), und dieser Schritt muß lokal und manuell vollzogen werden! (Inwieweit dies Hardware-Offloader betrifft, also z. B. einen Futro, ist gerade nicht ganz klar; das testen wir derzeit noch, gehen aber von vergleichbaren Problemen aus!)

Da wir in 1-2 Wochen Firmware 1.0 ausrollen wollen, hiermit also der dringende Aufruf an alle, die im Kreis GT, der Müritz-Region oder der Feldberger Seenlandschaft virtuelle oder physische Offloader auf x86-Basis betreiben, kurzfristig selbst kontrolliert ein Upgrade auf eine »experimental«-Version von Firmware 1.0 vorzunehmen; im Falle von VMs definitiv erst nach einem Shutdown & qemu-img-resize-Aufruf.


(René) #2

Vielleicht ist es Zufall, aber mein Knoten ist seit ein paar Stunden offline (SSID). Soll ich etwas nachschauen bevor ich reboote?

SSH geht. Ping vom Knoten nach nach IP geht. Namensauflösung (nslookup) geht nicht (no servers could be reached).


(Kai 'wusel' Siering) #3

Hatte ich in der 4ma auch, beide Offline, plötzlich ging’s wieder, aber der WNDRMAC2 hatte keinen eigenen Uplink …

‘logread’ wäre mal interessant, was da als Grund für ‘fastd tut nicht’ steht; hatte ich heute leider keine Zeit zu.


(Kai 'wusel' Siering) #4

Hmm. V4-DNS kommt von Deinem DHCP-Server, warum sollte das nicht gehen?


(René) #5

logread kann ich per mail schicken. Sind 600 Zeilen.

root@33332-freifunk-buschkoettersweg:~# nslookup www.heise.de
;; connection timed out; no servers could be reached

Edit: Habe rebootet. Läuft wieder. Soll ich das Log per Mail schicken?


(Kai 'wusel' Siering) #6

Nützt eher nix, die Frage ist ja, warum kein Server erreichbar war (und welche überhaupt kommuniziert würden). Mal gucken, IIRC gibt’s 'n Watchdog-Paket, welches nach n Stunden ohne Verbindung rebooten kann …


(Kai 'wusel' Siering) #7

Nächstes mal bitte  cat /tmp/gluon/wan-dnsmasq/resolv.conf  machen und gucken, welche DNS-Server vom DHCP-Server des WANs kamen und ob diese erreichbar sind.


(Kai 'wusel' Siering) #8

Ein Mysterium gelöst: die neuen fastd-Instanzen (176-179) waren auf je 90 Verbindungen begrenzt. Firmware 0.7.x nutzt davon derzeit in “Pool 1” 176-178, in “Pool 2” 179; jeweils max. 1 Verbindung. Firmware 1.0.x nutzt derzeit einzig fastd179. Im Ergebnis gehen auf 179 ggf. zuviele Verbindungen ein, sodaß 1.0er-Knoten nicht mehr reinkommen :frowning:

Heute morgen Die Anzahl der Verbindungen erst auf je 110 erhöht, dann dieses Limit nur bei 176-178 forciert; 179 hat z. Zt. ein Limit von 300 Verbindungen:

fastd connections
=================
fastd176: 71
fastd177: 78
fastd178: 81
fastd179: 148

(Limit 176-178: 110 -- updated at Tue Jan  8 16:14:01 2019)

(René) #9

Nachdem mein Knoten wieder offline und ein nslookup wieder fehlgeschlagen ist, habe ich mehr Informationen.

root@33332-freifunk-buschkoettersweg:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
nameserver fd00::be05:43ff:feb2:4051
nameserver 192.168.0.1

Und ein nslookup über meine Haupt FritzBox:

root@33332-freifunk-buschkoettersweg:~# nslookup www.heise.de 192.168.0.1
Server:         192.168.0.1
Address:        192.168.0.1#53

Name:      www.heise.de
Address 1: 193.99.144.85
Address 2: 2a02:2e0:3fe:1001:7777:772e:2:85


root@33332-freifunk-buschkoettersweg:~# nslookup www.heise.de fd00::be05:43ff:feb2:4051
Server:         fd00::be05:43ff:feb2:4051
Address:        fd00::be05:43ff:feb2:4051#53

Name:      www.heise.de
Address 1: 193.99.144.85
Address 2: 2a02:2e0:3fe:1001:7777:772e:2:85

root@33332-freifunk-buschkoettersweg:~# nslookup www.heise.de
;; connection timed out; no servers could be reached

Verstehe ich leider nicht :frowning: Warum gehen beide Nameserver, aber nicht die Abfrage ohne Angabe des NS?

/etc/init.d/network restart hat leider nichct ausgereicht. Ich musste rebooten.


(Thomas Hollenbeck) #10

Habe gerade mal bei meinem 0.7 er Knoten geschaut. Der hat einen lokalen DNS Server

root@33397-Lu-Hollenbeck-2:~# nslookup heise.de
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

Name: heise.de
Address 1: 2a02:2e0:3fe:1001:302:: redirector.heise.de
Address 2: 193.99.144.80 redirector.heise.de

root@33397-Lu-Hollenbeck-2:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
nameserver fd4b:1853:fc09:1:c225:6ff:fe21:2ba4
nameserver 192.168.10.1

root@33397-Lu-Hollenbeck-2:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
root@33397-Lu-Hollenbeck-2:~#

scheinbar hängt sich der DNSMasq Dienst dann auf. Kannst ja beim nächsten mal einmal prüfen.

root@33397-Lu-Hollenbeck-2:~# ps |grep dns
1794 nobody 932 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
1801 root 1076 S /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/resolv.conf
32644 root 1384 S grep dns

bei nem 1.x er Knoten sieht das ganze bei mir so aus:

root@33397-Lu-Hollenbeck-1:~# ps |grep dns
1864 root 1120 S /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid
2175 dnsmasq 1048 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c
21197 root 1184 S grep dns


(Kai 'wusel' Siering) #11

Kleiner Exkurs:

  OS: 17.01-SNAPSHOT, r3981+103-184fe1    FW: 1.0.0~116                       
  HW: Ubiquiti UniFi AP Pro                                               
root@33332-Schalueckstr-107-11d9:~# nslookup heise.de
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:      heise.de
Address 1: 193.99.144.80
Address 2: 2a02:2e0:3fe:1001:302::
root@33332-Schalueckstr-107-11d9:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
nameserver 2001:678:2c0:1::1
nameserver 192.168.5.31
nameserver 192.168.5.33
nameserver 8.8.8.8
root@33332-Schalueckstr-107-11d9:~# 

Allerdings ist sie aktuell auch connected — Gluon hat zwei Resolver, einen auf Port 53, den normale Anwendungen fragen (und der nur tut, wenn Verbindung zum Mesh besteht), und einen auf Port 54, der die NS aus /tmp/gluon/wan-dnsmasq nutzt und (nur) von fastd/tunneldigger genutzt wird:

root@33332-Schalueckstr-107-11d9:~# netstat -anu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
udp        0      0 0.0.0.0:53              0.0.0.0:*                           
udp        0      0 0.0.0.0:54              0.0.0.0:*                           
udp        0      0 0.0.0.0:42112           0.0.0.0:*                           
udp        0      0 0.0.0.0:48081           0.0.0.0:*                           
udp        0      0 :::546                  :::*                                
udp        0      0 :::546                  :::*                                
udp        0      0 :::53                   :::*                                
udp        0      0 :::54                   :::*                                
udp        0      0 ff02::1:16962           :::*                                
udp        0      0 fe80::26a4:3cff:feb1:11d9:16962 :::*                                
udp        0      0 :::1001                 :::*                                
root@33332-Schalueckstr-107-11d9:~# ps w | grep dnsmas
 2016 dnsmasq   1052 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg02411c -k -x /var/run/dnsmasq/dnsmasq.cfg02411c.pid
 2083 root      1120 S    /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/reso
23418 root      1184 S    grep dnsmas
root@33332-Schalueckstr-107-11d9:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
[…]

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  anywhere             localhost            owner GID match gluon-mesh-vpn udp dpt:domain to::54

Sprich: fastd läuft unter GID gluon-mesh-vpn, dadurch werden dessen DNS-Anfragen an localhost auf Port 54 umgeleitet, wo der dnsmasq für’s externe Resolving läuft. Kann man auch simulieren:

root@33332-Schalueckstr-107-11d9:~# nslookup -query=TXT o-o.myaddr.l.google.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
o-o.myaddr.l.google.com text = "2a06:e881:1700:1:400:c0ff:fefb:e251"

root@33332-Schalueckstr-107-11d9:~# start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- -query=TXT o-o.myaddr.l.google.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
o-o.myaddr.l.google.com text = "91.1.346.266"

91.1.346.266 ist meine aktuelle Telekom-IP, über die der interne Resolver rausgeht, was beweißt, daß die Anfrage nicht über’s Mesh läuft.
2a06:e881:1700:1:400:c0ff:fefb:e251 die IP des FFGT-Gateways, welches auch den Resolver bietet.

Mesh-only-Knoten, verbunden:

root@33330-mail-de-AVM4020-test:~# cat /tmp/gluon/wan-dnsmasq/resolv.conf
root@33330-mail-de-AVM4020-test:~# nslookup -query=TXT o-o.myaddr.l.google.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
o-o.myaddr.l.google.com text = "2a06:e881:1700:1:400:c0ff:fefb:e251"

root@33330-mail-de-AVM4020-test:~# start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- -query=TXT o-o.myaddr.l.google.com
;; connection timed out; no servers could be reached

Ergo:

Ohne Mesh-Verbindung hast Du auf dem Knoten kein DNS, nur fastd/tunneldigger können, über den Upstream-DNS via DHCP, Namen auflösen. In obigem Status müßte ein start-stop-daemon -S -c root:gluon-mesh-vpn -x nslookup -- heise.de  funktionieren.

0.7.9/Gluon 2016.2.x (2016!) hat das noch anders gelöst, IIRC; es gilt aber das oben gesagte prinzipiell auch: lokale Kommandos außer dem VPN-Kram laufen gegen den normalen Resolver, der nur tut, wenn Verbindung ins Mesh besteht. VPN-Daemons hingegen laufen gegen den/die WAN-DNS-Server, weshalb fastd auf mesh-only-Knoten i. d. R. auch kein VPN über’s Mesh aufbaut (mangels DNS-Auflösung) und aktiviert bleiben kann.


(Kai 'wusel' Siering) #12

(Und das ist auch der Grund, warum man nicht einfach ein paar Pakete auf OpenWrt werfen kann und z. B. einen Turris Omnia zur Freifunk-Knoten zu machen. Da steckt recht viel in Softwaremagie transformiertes Knowhow und Hirnschmalz drin :wink:

Und ein Grund, warum ich bei …

… auch nicht direkt drauf kam, daß “nslookup geht nicht” ggf. “normaaaal” ist. seufz)