Verständnisfragen anhand des Versuchs einer Fehlersuche


#1

Hallo,

in den letzten Wochen erlebe ich es immer wieder, teilweise über mehrere Tage, inzwischen auch Wochen hinweg, dass über Freifunk keine Ip-Adressen verteilt werden, in Folge funktioniert auch der Internetzugang nicht, noch irgendetwas Anderes.
Logge ich mich via ssh auf entsprechenden Router von außen ein, kann ich mir problemlos die Gateways anzeigen lassen.
Ebenso kann ich die Gateways via ping erreichen.Das Anpingen anderer Ip-Adresse ist ebenfalls problemlos möglich.
Trage ich unter /etc/resolv.conf einen Nameserver ein (z.B. 8.8.8 von Google) funktioniert auch die Namensauflösung. Ohne Eintrag wird dort auf den Knoten selbst verwiesen (127.0.01).

Logge ich mich via ssh auf dem AP ein erreiche ich vom AP direkt problemlos den Internetzugang.
Hänge ich einen Client hinter den AP erhält dieser, wie gesagt, meistens nicht einmal eine Ip-Adresse.
Traceroute geht vom Knoten aus problemlos (s.u.).

root@wup-KiHo-wlan:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1  5.10.178.89 (5.10.178.89)  0.912 ms  0.422 ms  0.378 ms
 2  *  *  *
 3  81.210.131.109 (81.210.131.109)  14.927 ms  13.495 ms  15.771 ms
 4  84.116.197.18 (84.116.197.18)  15.831 ms  21.799 ms  15.768 ms
 5  84.116.197.22 (84.116.197.22)  15.021 ms  14.582 ms  15.772 ms
 6  84.116.133.118 (84.116.133.118)  15.795 ms  18.766 ms  84.116.133.97 (84.116.133.97)  18.717 ms
 7  213.46.177.42 (213.46.177.42)  13.965 ms  13.863 ms  21.303 ms
 8  209.85.243.73 (209.85.243.73)  15.986 ms  16.316 ms  209.85.241.213 (209.85.241.213)  15.743 ms
 9  216.239.63.243 (216.239.63.243)  21.637 ms  216.239.63.249 (216.239.63.249)  20.543 ms  209.85.247.21 (209.85.247.21)  13.891 ms
10  8.8.8.8 (8.8.8.8)  15.272 ms  13.597 ms  14.442 ms

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=54 time=16.855 ms
64 bytes from 8.8.8.8: seq=1 ttl=54 time=11.669 ms
64 bytes from 8.8.8.8: seq=2 ttl=54 time=14.361 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 11.669/14.295/16.855 ms

Daraufhin versuchte ich mich an batctl um der Ursache etwas näher zu kommen:
Erst einmal welche Gateways verfügbar sind, danach ob diese erreichbar sind:

batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2015.0, MainIF/MAC: mesh-vpn/16:d0:20:cd:4f:1c (bat0)]
   04:be:e1:ba:fe:20 (118) 04:be:e1:ba:fe:20 [  mesh-vpn]: 92.0/92.0 MBit
   04:be:e1:ba:fe:10 (167) 16:cf:21:cd:4d:2a [     mesh0]: 92.0/92.0 MBit
=> 04:be:e1:ba:fe:00 (255) 04:be:e1:ba:fe:00 [  mesh-vpn]: 92.0/92.0 MBit

 batctl p 04:be:e1:ba:fe:00
 PING 04:be:e1:ba:fe:00 (04:be:e1:ba:fe:00) 20(48) bytes of data
20 bytes from 04:be:e1:ba:fe:00 icmp_seq=1 ttl=50 time=29.50 ms
20 bytes from 04:be:e1:ba:fe:00 icmp_seq=2 ttl=50 time=22.13 ms
20 bytes from 04:be:e1:ba:fe:00 icmp_seq=3 ttl=50 time=20.54 ms
20 bytes from 04:be:e1:ba:fe:00 icmp_seq=4 ttl=50 time=21.30 ms
20 bytes from 04:be:e1:ba:fe:00 icmp_seq=5 ttl=50 time=22.75 ms
^C--- 04:be:e1:ba:fe:00 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
rtt min/avg/max/mdev = 20.540/23.243/29.498/3.216 ms
 
 batctl p 04:be:e1:ba:fe:10
PING 04:be:e1:ba:fe:10 (04:be:e1:ba:fe:10) 20(48) bytes of data
20 bytes from 04:be:e1:ba:fe:10 icmp_seq=1 ttl=49 time=28.44 ms
20 bytes from 04:be:e1:ba:fe:10 icmp_seq=2 ttl=49 time=26.58 ms
20 bytes from 04:be:e1:ba:fe:10 icmp_seq=3 ttl=49 time=25.18 ms
^C--- 04:be:e1:ba:fe:10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
rtt min/avg/max/mdev = 25.182/26.734/28.438/1.334 ms
 
 batctl p 04:be:e1:ba:fe:20

PING 04:be:e1:ba:fe:20 (04:be:e1:ba:fe:20) 20(48) bytes of data
20 bytes from 04:be:e1:ba:fe:20 icmp_seq=1 ttl=50 time=15.44 ms
20 bytes from 04:be:e1:ba:fe:20 icmp_seq=2 ttl=50 time=15.86 ms
20 bytes from 04:be:e1:ba:fe:20 icmp_seq=3 ttl=50 time=18.04 ms
20 bytes from 04:be:e1:ba:fe:20 icmp_seq=4 ttl=50 time=19.56 ms
^C--- 04:be:e1:ba:fe:20 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 15.438/17.224/19.561/1.672 ms

Das scheint soweit alles ganz gut.
Wenige Minuten später jedoch, als ich einmal ausversehen ein ping auf einen der Gateways wiederhole:

batctl p 04:be:e1:ba:fe:20
PING 04:be:e1:ba:fe:20 (04:be:e1:ba:fe:20) 20(48) bytes of data
Reply from host 04:be:e1:ba:fe:20 timed out
Reply from host 04:be:e1:ba:fe:20 timed out
Reply from host 04:be:e1:ba:fe:20 timed out
Reply from host 04:be:e1:ba:fe:20 timed out
Reply from host 04:be:e1:ba:fe:20 timed out
Reply from host 04:be:e1:ba:fe:20 timed out
^C--- 04:be:e1:ba:fe:20 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss
rtt min/avg/max/mdev = 0.000/0.000/0.000/0.000 ms

kurz darauf ist wieder alles ok.

Ich versuchte ein trace mit batman

batctl -m bat0 tr 04:be:e1:ba:fe:20
traceroute to 04:be:e1:ba:fe:20 (04:be:e1:ba:fe:20), 50 hops max, 20 byte packets
 1: 16:d0:20:cd:4d:2a  1.050 ms  1.297 ms  4.244 ms
 2: 04:be:e1:ba:fe:10  24.923 ms  20.791 ms  21.291 ms
 3: 32:b6:c2:22:e8:0a  83.200 ms  78.151 ms  80.514 ms
 4: 04:be:e1:ba:fe:20  119.085 ms  107.718 ms  111.899 ms

Hier irritiert es mich etwas, das zwischen mir und den Gateway noch weitere Stellen liegen.

batctl tl |grep W |wc -l
0

Clients gibt es derzeit keine (mehr).
Das erklärt zumindest die Beschwerden die mich aktuell auf meinen Handy erreichen. Ich selbst bin leider derzeit nicht vor Ort. Angeblich funktioniert “wieder einmal garnichts”. Das kann nicht stimmen, zumindest mit den Telefonen ist leider alles ok. :wink:

Nun noch ein paar Fragen, und ich hoffe hier kann mir irgendwer weiterhelfen.

br-wan    Link encap:Ethernet  HWaddr 16:CD:20:CD:4F:1C
          inet addr:5.10.178.93  Bcast:5.10.178.95  Mask:255.255.255.248
          inet6 addr: fe80::14cd:20ff:fecd:4f1c/64 Scope:Link
          inet6 addr: 2002:5fde:4811:0:14cd:20ff:fecd:4f1c/128 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5023978 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2085529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1553373705 (1.4 GiB)  TX bytes:480901378 (458.6 MiB)

Frage: Ist dies das externe Interface über das dann später auch die vpn Verbindung zum Freifunk rausgeht.

local-node Link encap:Ethernet  HWaddr 04:BE:E1:BA:FE:AA
          inet addr:10.3.0.1  Bcast:10.3.255.255  Mask:255.255.0.0
          inet6 addr: fda0:747e:ab29:e1ba::1/128 Scope:Global
          inet6 addr: fe80::6be:e1ff:feba:feaa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:562435 errors:0 dropped:0 overruns:0 frame:0
          TX packets:512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:25623395 (24.4 MiB)  TX bytes:21996 (21.4 KiB)

Ist, soweit ich das verstehe, die Adresse des Knotens im Freifunknetz. Oder liege ich hier falsch? Wie erhält der Knoten diese? Dhcp?

mesh-vpn  Link encap:Ethernet  HWaddr 16:D0:20:CD:4F:1C
          inet6 addr: fe80::14d0:20ff:fecd:4f1c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1426  Metric:1
          RX packets:4907222 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1773049 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1219181926 (1.1 GiB)  TX bytes:243106142 (231.8 MiB)

mesh0     Link encap:Ethernet  HWaddr 16:CF:21:CD:4F:1C
          inet6 addr: fe80::14cf:21ff:fecd:4f1c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1532  Metric:1
          RX packets:2685979 errors:0 dropped:21 overruns:0 frame:0
          TX packets:3341540 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:311070038 (296.6 MiB)  TX bytes:400727757 (382.1 MiB)

Was hat es mit diesen Interfaces auf sich?

Gibt es irgendwo eine Übersicht, wie das Freifunknetz strukturiert ist?

Liebe Grüße und vielen Dank fürs Lesen,
Patrick


#2

Hallo Patrick,

danke für Deine ausführliche Symptombeschreibung.

Strukturbeschreibung findet sich auf
https://wiki.freifunk-rheinland.net/wiki/Wupper

Derzeit hängt es häufig an der Netzanbindung “für die Client-router” für die Fastd-Server, die virtualisiert auf Maschinen des Freifunk-Rheinland laufen.
Die leiden bisweilen an zweistellen Packetloss-Raten, so dass man schon fast von “Packet-Survival” sprechen kann.

Und dadurch wird alles was über die VPN-Tunnel läuft per TCP sehr, sehr langsam (GPRS-“Speed”) und UDP-Dienste (wie DHCP) grenzen an die Unbenutzbarkeit.
Abhilfe wird meines Erachtens nur lokal beschafftes (und damit nicht “Fremd-Überbuchbares”) Blech bringen.
Aber das ist ist eine politische Diskussion, die jede Community für sich führen muss.


#3

Sehr gute Fehlerbeschreibung; gute Arbeit. Grund heute für diesen Fehler: ich habe seit diesem Beitrag, in dem ich angekündigt habe w0 und w1 wieder als kaputte GWs laufen zu lassen, vergessen auf w1 und w0 den DHCP-Server einzuschalten. Entschuldigt bitte die Umstände. Wenn ich seit Stunden versuche Probleme zu beseitigen, für die es keine Lösung mit den zur Verfügung stehenden Mitteln gibt, dann sieht man schon mal den Wald und die Bäume nicht mehr.

DHCP ist wieder eingeschaltet, w0 und w1 werden aber in den Spitzenzeiten (und vor und nach diesen) Pakete verschlucken; w6 täte das noch stärker, deshalb lasse ich den mal außen vor. w2 ist über w4 angebunden, deshalb ist w4 auch aus …

ja, mit diesem Problem habe ich auch gekämpft. Die Ursache dafür: w2 als privat gesponserter Server, bricht einfach ab und zu weg.


#4

Ich kann nur dringend die Verwendung von Check_MK ans Herz legen.
Das hat mich auch schon häufiger mal “wecken” müssen.


(P.S.: Ja, der Monitor steht wirklich so)


#5

Erst einmal vielen Dank für die guten Antworten. Besonders an phip:
Ich finde Dein Engagement sowie ich es hier im Forum wahrnehme einfach nur beeindruckend und habe da größten Respekt vor! Deine Antwort hat auch einige Fragezeichen aus meinem Kopf eliminiert.

Ich gehe noch einmal ins Rektorat und schaue ob man dort wenigstens via Rundmail ein Spendenaufruf an alle Studierenden durchbekommt und vielleicht eine kleine Spende. Versprechen kann ich da aber nichts. Nur sehe ich nicht ein, dass wir es nutzen und nichts beitragen.

root@wup-KiHo-wlan:~# batctl tl |grep W |wc -l
1

Es läuft wieder, seit 3 Uhr sind auch keine Beschwerden mehr diesbezüglich bei mir eingegangen.

Der Link bringt mich etwas weiter. Ich stehe zwar ob der technischen Zusammenhänge noch etwas auf
dem Schlauch, aber lese einfach weiter. Das wiki konnte schon einige bisher nur wage Vorstellungen etwas konkretisieren. Aktuell warte ich auch auf eine Fernleihe, die interessant werden könnte.