Troubleshooting

• 25 Befehle für Anfänger in Linux anfänger
• wavemon - WLAN-Monitoring wavemon
• glances - System-Monitoring glances
• atop - System-Monitoring atop
• bmon - Netzwerk-Monitoring bmon
• nethogs - Bandbreite pro Prozess nethogs
• speedtest - Bandbreitenmessung speedtest-cli
• wget - Download wget-befehle
• ncdu - Datei und Ordnergröße ermitteln ncdu

Folgende Punkte sollen Dir helfen, wenn Du meinst, dass Dein Knoten sich nicht mit einem unserer Freifunk-Gateways verbinden kann.

• WLAN mit ESSID „Freifunk“ sichtbar
• Statusseite per http://[fd21:711::1]/ abrufbar?
• Freifunk-Router hat vom Heim Router eine IPv4-Adresse bekommen (am Heim-Router prüfen)?
• Auf http://karte.freifunk-stuttgart.de/#nodeList (→Node List) prüfen, ob Router angezeigt wird. Hier erfolgt die Aktualisierung nur alle 5 Minuten!
• Der Fritzbox-Gastzugang nicht zu restriktiv eingestellt ist, falls der Freifunk-Router an LAN4 der Fritzbox angeschlossen ist.
• Der VPN-Schlüssel von uns schon eingetragen wurde. Kann unter https://github.com/freifunk-stuttgart/peers-ffs kontrolliert werden.
• Das Kabel zwischen Heim-Router und Freifunk-Router auch wirklich ok ist, am Freifunk-Router an WAN angeschlossen ist und die Stecker auch wirklich eingerastet sind.
• Bei direktem Anschluss an einem Kabel-Modem (nicht Kabel-Router!) z.B. von Unitymedia könnte die MAC-Adresse vom Freifunk-Router nicht mehr im Kabelmodem registriert sein. Dazu Strom vom Kabelmodem für mindestens 1 Minute wegnehmen und neu registrieren lassen.
• Bei Problemen mit der IPv6 Verbindung kann es (mindestens bei Unitiymedia Routern) helfen diesen aus dem Webfrontend neuzustarten (einfaches Strom weg, 1 Minute warten, Strom wieder dran hat nicht geholfen).

Folgende Punkte sollen dir helfen, wenn sich Dein Knoten mit einem Freifunk-Gateway verbunden ist, aber ein Client per LAN oder WLAN Beispielsweise keinen Internet-Zugang hat.

• Routen zu anderen Segmenten sind nicht möglich? Überprüfen, ob die Präfix-Länge limitiert ist. „sysctl -a | grep accept_ra_rt_info_max_plen“ (>=64?)

Ein Einblick was die Geschwindigkeit beeinflusst und vielleicht auch was eher nicht.

Die Geschwindigkeit von TCP hängt von der Bandbreite, von der Latenz und der Verbindungsqualität (Paketverlust) ab.

1. Nummerierter Listenpunkt Client - Node
   • Hier via WLAN
   • rtt min/avg/max/mdev = 1.233/2.834/23.875/2.692 ms,
2. Node - Node (Mesh, eventuell viele Hops)
   • Hier bei zwei Nodes über 100 Pakete:
   • round-trip min/avg/max = 1.680/4.135/29.468 ms
3. Node VPN - GW
   1. Lokaler Internetanschluss
      • Hier Vodafone, VDSL, 30ms bis zur Gegenstelle
   2. Internetprovider Backbone
      • Hier Vodafone, 7ms bis zum nächsten Provider
   3. Transfer zum Gatewayprovider
      • Sind wohl direkt verbunden, peeren in Düsseldorf, 0ms
   4. Gateway Rechenzentrum
      • gw05n03, steht irgendwo bei Düsseldorf, 1ms
4. GW - Ziel
   1. Gateway Rechenzentrum
      • Lokal, 0ms
   2. Transfer zum Zielprovider
      • Frankfurt, wohl DECIX, 5ms
   3. Zielprovider Rechenzentrum
      • heise.de, stehl wohl am DECIX, 0ms extra

Meine Erfahrung sagt Glasfaser direkt bringen:

• Stuttgart-München: 8ms
• Stuttgart-Karlsruhe: 4ms

Wenn ich hier die Spielekiste an mache, dann sagt mir mein System, direkt,ohne Freifunk, 55ms zu den battle.net-Servern. Das ist die in der Applikation angezeigte Latenz. Die ist normalerweise schlechter als 'ICMP echo'. Auch das muss bei Vergleichen berücksichtiogt werden. Die großen Teile der Latenz sind

• der lokale Internetzugang
• der Weg vom GW zum Ziel, abhängig vom Ziel, Content Delivery Networks sind potentiell immer nah am GW, egal wo das steht.

Relativ irrelevant ist der Weg zum GW. gw08n01 ist von mir 7ms weiter weg als bei gw05n03. Der Ping durch das Freifunk-Netz zu eu.battle.net ist aber nur <6ms langsamer.

via gw08n01:

• round-trip min/avg/max = 42.433/45.260/70.966 ms
• lokal direkt ohne Freifunk:
  • rtt min/avg/max/mdev = 34.735/39.851/127.069/15.251 ms

Diese resultiert aus der kleinsten Bandbreite aller beteiligten Hops zum Ziel.

Normalerweise ist die geringste Bandbreite der lokale Internetzugang oder die WLAN/Mesh-on-WLAN-Strecke. Da muss jeder lokal selbst nach einer Optimierung suchen. Bekannte Methoden sind z.B. Mesh-on-LAN und getrennte Client/Mesh-Netzeauf unterschiedlichen Kanälen

Wenn TCP Pakete verliert, wird meistens mit einer Reduzierung der Bandbreite reagiert. Paketverlust tritt in Deutschland im festen Internet heute nur sehr wenig auf, in WLAN-Netzen aufgrund von Störungen aber doch recht häufig. Hier kann der Client und der Serverbetreiber eventuell durch lokale Einstellungen die Auswirkungen lindern. Die Serverbereiber werden wir kaum erreichen, die Clients sind die User selbst.

Zentral können wir nur an A drehen und auch da nur am Standort der GWs. Die sollten so nah wie möglich an den Clients (Internetprovider) und an den Zielen liegen. Die Ziele sind uns nicht bekannt. Die Provider selbst recht gut angebunden. Wir können natürlich pauschal GWs ablehnen, die nicht an großen deutschen Austauschpunkten sind, aber selbst nach Paris sind es nur 7ms mehr, ich glaube nicht dass das den Durchsatz erhöht. Selbst eine Verbindung nach Shanghai (250ms Latenz) schafft anständige Bandbreiten wenn die Leitung nicht gerade überlastet ist.

Die größten Einsparungen an der Latenz bringen lokale, direkt ausleitende GWs an Leitungen die nicht DSL-Latenzen bringen. Aber auch das wird kaum eine Auswirkung auf die Bandbreite haben. Dicke Internetanbindungen und gut aufgesetze WLAN-Installationen bringen da bis zur Kapazitätsgrenze der GWs sicher am meisten. Letzere lassen sich mit lokalen Ausleitungen umgehen, dafür gibt es aber noch keine einfache Möglichkeit.

Wenn die Bandbreite zum User trotz sauberer lokaler Installation mit ausreichend starkem VPN-Node noch gering ist, kann es auch an einem ausgelasteten GW liegen. Das läßt sich unter https://netinfo.freifunk-stuttgart.de/grafana/d/000000008/gateways?orgId=1 an der Abwesenheit von Kurven beim eth0-Traffic erkennen. Wenn das morgens hoch geht und dann den Tag über eher flach ist, am Abend wieder runter geht, dann ist das GW ausgelastet. Prinzipiell haben wir ausreichend Kapazitäten auf den GWs, aber wir haben derzeit keine Möglichkeit Nodes auf andere GWs zu schicken um die verfügbare Bandbreite besser zu verteilen. Das Gateway wird derzeit bei der Verbindung von den Nodes zufällig gewählt.

Stand: Mo 21. Okt 10:23:04 CEST 2019

Wenn Du auf den Node kommst:

Hat der Node ein BATMAN Gateway?

Die Ausgabe von

batctl gwl

sollte einige MAC-Adressen ausspucken, eine Zeile sollte ein ⇒ vorne dran haben:

Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2015.1, MainIF/MAC: ibss1/a2:f6:c3:8c:21:12 (bat0)]
       02:00:38:02:01:00 (225) 02:00:38:02:05:03 [  mesh-vpn]: 96.0/96.0 MBit
       02:00:35:02:07:00 (225) 02:00:38:02:05:03 [  mesh-vpn]: 80.0/80.0 MBit
       02:00:38:02:08:02 (225) 02:00:38:02:05:03 [  mesh-vpn]: 64.0/64.0 MBit
       02:00:38:02:07:02 (225) 02:00:38:02:05:03 [  mesh-vpn]: 64.0/64.0 MBit
    => 02:00:35:02:05:03 (255) 02:00:38:02:05:03 [  mesh-vpn]: 96.0/96.0 MBit
       02:00:37:02:05:01 (225) 02:00:38:02:05:03 [  mesh-vpn]: 96.0/96.0 MBit
       02:00:38:02:08:00 (221) 02:00:38:02:05:03 [  mesh-vpn]: 64.0/64.0 MBit
       02:00:38:02:10:00 (225) 02:00:38:02:05:03 [  mesh-vpn]: 96.0/96.0 MBit
       02:00:37:02:05:02 (225) 02:00:38:02:05:03 [  mesh-vpn]: 96.0/96.0 MBit

Wenn ja: Problem liegt wahrscheinlich nicht an diesem Node sondern eher irgendwo ab oder nach dem Gateway Wenn nicht: Der Node hat kein batman-Gateway. In dem Fall:

Kennt der Node andere Nodes?

batctl o

sollte eine Liste von anderen Nodes zeigen die der Node sieht. Wenn das so ist hat entweder die ganze Wolke keinen Uplink oder der Node hat sich noch kein GW ausgesucht, das dauert einen Moment. Wenn keine Nodes angezeigt werden, hat der Node keine Verbindung zu irgend welchen anderen per LAN/WLAN und auch kein VPN. Z.B. weil die VPN-Verbindung nicht durch die Firewall kommt. Fritzbox Gast WLAN z.B.blockt per Default die VPN-Ports von FFS.

Wenn das alles geklaert ist, ist der Node in Ordnung, wenn es immer noch nicht tut, muss auf dem Client weiter gesucht werden.

Auf dem Client, tja, keine Ahnung wie man da mit Windows tiefer analysiert, unter Linux oder auch MacOS mit root ist es einfacher.

1. hat der Client eine IP?

• 2a nein: Gibt es Traffic auf dem WLAN-Interface? z.B.

  tcpdump

  hilft da

• 3a nein: WLAN ist nicht richtig, da kommt immer was, mindestens ARP Requests ab und an. Client hat irgendein lokales Problem.

• 3b ja: WLAN zum Node steht, wahrscheinlich keine IP vom GW, GW-Betreiber kontaktieren, behelfsweise Gateway wechseln, z.B. durch Node-Neustart

• 2b ja: funktioniert ping auf 8.8.8.8?

• 4a ja: funktioniert ping auf heise.de?

• 5a ja: Es gibt kein Problem.

• 5b nein: DNS funktioniert nicht. Lokal genutzten DNS-Server pruefen, oft sind da noch Reste vom anderswo drin. Richtig waere zumindest einer der so heisst wie das Gateway. Wenn die korrekt sind: GW-Betreiber kontaktieren., behelfsweise Gateway wechseln, z.B. durch Node-Neustart

• 4b nein: Internet geht schonmal nicht. Geht ping auf das Default Gateway?

• 6a ja: GW-Betreiber kontaktieren, behelfsweise Gateway wechseln, z.B. durch Node-Neustart

• 6b nein: phuu, WLAN neu starten, wahrscheinlich hat er dann keine IP mehr, weiter bei 2a. Oder es funktioniert jetzt.

30-30-30-Methode: Bei laufendem Betrieb die ganze Zeit (90sek lang) den Reset Button drücken, nach 30 sek den Strom wegnehmen, nach weiteren 30 sek wieder einschalten und nach erneuten 30 sek den Reset-Knopf los lassen. Man befindet sich nun im Failsafe-Modus. Mithilfe von Telnet kann man sich auf die IP 192.168.1.1 aufschalten und mit

mount_root

das Dateisystem mounten. Mit

firstboot

die Firmware-Einstellungen löschen und gegebenfalls mit

sysupgrade /tmp/pfad.bin

eine vorher mit netcat übertragene Firmware aufspielen.

cat firmware.bin | nc -l -p 1234

nc 192.168.1.1 1234 > /tmp/pfad.bin

Auf dem Router:

 nc -l -p 1234 > /tmp/ff.bin

Auf dem PC:

 cat firmware.bin | nc 192.168.1.1 1234

Nach 2 Min abbrechen auf Router und md5sum prüfen!

 sysupgrade /tmp/ff.bin