Freifunk Kreis GT

Freifunk-Community für den Kreis Gütersloh

Netzupdate läuft

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.

Netzupdate läuft

Bisherige Kommentare

  1. Echo says:

    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).

  2. wusel says:

    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.

  3. Echo says:

    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.

  4. Thomas says:

    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

  5. wusel says:

    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.

Weitere Diskussion über diesen Beitrag bitte im Forum forum.freifunk-kreisgt.de

6 more replies

Diskussionsteilnehmer