Wie Debugge ich einen nicht funktionierenden Node

Technik Gluon
1

ich habe mal hier einen schäbigen Anfang gewagt:
https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr

3 „Gefällt mir“
2

  • Wichtig wäre zunächst mal die Fallunterscheidung „was für ein Freifunk habe ich hier denn überhaupt“

  • Wenn es eine Gluon-Community ist:

  • Kann ich den nextnode via IPv6 anpingen? (Adresse siehe site.conf) Nein? Dann geht schon der Router lokal nicht.

  • kann ich den nextnode via IPv4 anpingen? Habe ich überhaupt eine RFC1918er erhalten (10…) Nein? Dann gibt es in meiner Wolke keinen funktionsfähigen DHCP-Server

  • Bitte auf dem lokalen Router einloggenper SSH (nextnode IPs, siehe oben), schauen was der so meint in lastlog (offensichtliche Misstände)

  • schauen ob batctl gwl denn Gateways ausgibt. Wenn nein, batctl o schauen ob da mindestens mehr als nur 3-4 Zeilen kommen, ansonsten ist mein FF-Node allein ohne Verbindung zur Wolke.

  • wenn es gateways gibt, diese per batctl p <gateway> anpingen

  • schauen ob öffentliche IPv6-Adressen per ICPM erreichbar sind ping6 2001:4860:4860::8888 (hier: google-DNS)

  • nachschauen ob man per ping6 www.google.com den vorigen Schritt „inkl Namensauflösung“ wiederholen

3

Hehe… starten wir das mal :stuck_out_tongue_winking_eye:

Fehler: kein Zugriff auf IPv6-Ressourcen über Freifunk

  • Community: Ruhrgebiet
  • ping nextnode IPv6: ok (Node und Client)
  • ping nextnode IPv4: ok (Node und Client)
  • logread: keine Errors, keine Warnings
  • batctl gwl gibt einen Haufen Gateways aus
  • batctl o gibt einen Haufen Zeilen aus
  • batctl p auf Gateway: ok
  • ping6 2001:4860:4860::8888 von Node: 100% loss
  • ping6 2001:4860:4860::8888 vom Client aus: 100% loss
  • nslookup auf Node www.google.de: can’t resolve (meint, 127.0.0.1 sei sein DNS… ist das richtig?)
  • nslookup auf Node www.google.de bei Server 8.8.8.8: ok
  • nslookup auf Client www.google.de bei Server 2001:4860:4860::8888: can’t resolve
  • nslookup auf Client www.google.de bei Server 8.8.8.8: ok

=> IPv4 ok, IPv6 kaputt. Was nun?

5

Nein, ist nicht richtig, aber kommt auf dem Node öfters vor, trotzdem ist normalerweise Surfen für Clients möglich.

Ich bekomme gerade mit meiner VM an dem x86-Gluon-Clientnetz gar keine IPv4-Adresse.
UPDATE: Ich habe eine v4-Adr, aber IPv6 ist immernoch kaputt

6

Ich habe auch festgestellt, das mein PC plötzlich als DNS Server 127.0.0.1 bzw ::1 benutzt, wenn ich von einem Wlan (Privat) nach Freifunk oder von Freifunk zum privaten WLan wechsle.

Bei mir hilft dann immer ‚wlan aus‘ 10 sec warten und Wlan an.

Danach bekomme ich wieder einen DNS Server zugewiesen.
Vielleicht hilft es euch ja als work around.

Ausserdem glaube ich bemerkt zu haben, das die Vergabe der IPv6 Adresse für den PC deutlich länger dauert, als die der IPv4 Adresse. Eventuell hat der Client schon aufgegeben, wenn die IPv6 Adresse endlich kommt?

Das sieht bei mir also eher nach einem Problem im WLAN stack des PC (Linux) aus, als ein reines FF Problem

7

Eine ernstgemeinte N00b-Frage:
Was genau bedeutet das, und von wo werden diese Pings ausgeführt (am FF-Router, nehme ich an)?

8

Die Adressen der „nextnode“ sind, wie adorfer schrieb, in der site.conf festgelegt. Welche Bedeutung diese Adressen genau haben bzw. welche Aufgaben die so bezeichneten Geräte haben, müssen die Experten beantworten, dazu bin ich noch nicht tief genug im Thema.

Ansonsten werden die angegebenen Adressen einfach von der Node (FF-Router) bzw. vom Client aus angepingt mit ping <ip-Adresse der nextnode>. Fertig.

9

Vielen Dank, matze!
Wo genau kann ich die site.conf für meine Community nachschlagen um an die nextnode-Adressen zu gelangen?

10

Der ping vom Node ist sinnlos, es ist der Node selber.

Bei GE ist es, wie fürs ganze Ruhrgebiet, 10.53.254.254

11

z.B. so:

  • Einloggen per ssh auf der Node
  • cat /lib/gluon/site.conf
  • Eintrag für next_node finden… wird nach meinem Ermessen für die jeweilige Community immer gleich sein
  • hier: 10.53.254.254 bzw. 2a03:2260:50:1::cafe
1 „Gefällt mir“
12

Danke nochmals!
Ich habe einen kleinen Text hier abgelegt:
https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr#next_nodes_anpingen

muss hier evtl. erweitertert werden, dass auch von den Clients diese Pingtests durchgeführt werden sollen?
Ich hab das noch nicht ganz verstanden, ich war davon ausgegangen, dass erstmal alle Tests auf dem FF-Router selbst durchgeführt werden…
@wirfman schreibt allerdings, dass diese Pingtests vom FF-Router aus „unsinnig“ seien… bin nun etwas verwirrt…

1 „Gefällt mir“
13

Den Router, zu dem du gerade per Freifunk verbunden bist, kannst du per „nextnode“-Addresse erreichen. Wenn der Router nicht gerade im Config-Mode ist, sollte er also beim Ping auf die Nextnode-Adresse selbst antworten (zu erkennen z.B. an der Ping-Zeit <1ms oder ttl=64, die TTL wird bei jedem benutzten Router um 1 reduziert). Ein Weg, die Nexthop-Adresse herauszufinden, ist die site.conf vom eigenen Router zu holen, was natürlich nur geht, wenn man den per SSH erreichen kann. Alternativ kann man auch in die site.conf des Quelltextes (oft bei Github) für die eigene Freifunk-Firmware nachgucken.

Wenn du die nextnode-Adressen kennst und über beide den lokalen Router nicht erreichen kannst, gehe ich davon aus, dass das bedeutet, dass es ein Problem mit dem lokalen Router gibt. Allerdings kann man den eigenen Router dann wahrscheinlich auch nicht per SSH erreichen (Ausnahme: Router ist im Config-Mode).

14

vielen Dank Benedikt,
das bedeutet:
wenn ich per ssh auf meinem Node eingeloggt bin, und dann die nextnode-Adresse anpinge, dann pinge ich mich immernoch selber an, richtig?

15

Ja!

20 Zeichen, asdfasfd!

16

bonus-deppenfrage: man würde also immer nur von den Clients aus die next_node anpingen, aber nicht vom node selbst aus, richtig?

17

Wie erreiche ich das lastlog?

18

Auf der Console mit dem Befehl logread. Wenn du logread -f eingibst so wird dir das Log fortlaufend angezeigt und die Ausgabe aktualisiert sich wenn neue Meldungen generiert werden.

1 „Gefällt mir“
19

Ok, nach welchen „offensichtlichen Missständen“ kann man hier schauen?
Mein Problem ist derzeit, dass mein Uplink nicht an Freifunk weitergereicht wird.

  • ich komme per ssh auf den Node

  • ping6 2001:4860:4860::8888 (google) funktioniert

  • ping6 www.google.com liefert „bad adress“

  • batctl gwl zeigt viele Gateways, die ich per batctl p anpingen kann

  • ifconfig zeigt für bat0 nur eine IP6 an, inet6 addr: fe80::a2f3:c1ff:fe99:277a/64 Scope:Link. Müsste da nicht auch eine „globale“ IP6 auftauchen?

    logread
    zeigt mir zB sowas an:

    Sun Apr 26 13:56:44 2015 daemon.info dnsmasq[1087]: reading /var/gluon

    /wan-dnsmasq/resolv.conf
    Sun Apr 26 13:56:44 2015 daemon.info dnsmasq[1087]: using nameserver fd00::2665:11ff:fea7:ebc8#53
    Sun Apr 26 13:56:44 2015 daemon.info dnsmasq[1087]: using nameserver 192.168.0.1#53

ist das nicht falsch, dass er meinen LAN-Router (192.168.0.1) als Nameserver benutzt?
Ich habe meinen Router per WAN an einer Fritzbox hängen…

20

Das mit dem Nameserver ist richtig so, IPv4-Traffic des Knoten selber wird nicht durchs VPN geschickt, ich weiß zwar nicht mehr warum, aber es ist so

21

Wenn ein Knoten ein MeshVPN über FastD aufbauen will muss er ja die Server Namen irgendwie auflösen können. Für Freifunk Clients wird aber niemals der lokale DNS benutzt. Die lösen die Namen über die per DHCP und Radvd übermittelten DNS Server auf den Supernodes/Gateways auf.