IPv4 sporadisch nicht funktional

Mitsch · 25. September 2016 um 12:56

Hallo,
wie im Chat schon bekannt gegeben habe ich immer wieder Probleme mit IPv4.
Bei mir lokal läuft Alles rund, IPv4 und v6 laufen sauber, wenn ich mich jedoch mit der Freifunk Node verbinde sagt mir Windows direkt: IPv4 Konnektivität: kein Internet, v6 läuft.

Sieht dann (wie erwartet) so aus:

C:\Users\michi>ipconfig
Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix: ffka
   IPv6-Adresse. . . . . . . . . . . : 2a03:2260:a:b:3c32:4790:db6c:126f
   Temporäre IPv6-Adresse. . . . . . : 2a03:2260:a:b:4024:6eaf:9925:d8fc
   Verbindungslokale IPv6-Adresse  . : fe80::3c32:4790:db6c:126f%23
   IPv4-Adresse  . . . . . . . . . . : 10.214.58.219
   Subnetzmaske  . . . . . . . . . . : 255.255.224.0
   Standardgateway . . . . . . . . . : fe80::1%23
                                       10.214.56.8


C:\Users\michi>ping 10.214.56.8

Ping wird ausgeführt für 10.214.56.8 mit 32 Bytes Daten:
Antwort von 10.214.56.8: Bytes=32 Zeit=39ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=38ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=34ms TTL=64

C:\Users\michi>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Kann das eventuell jemand bestätigen und eventuell auch mal nachvollziehen/weiter debuggen?

Es handelt sich um die node: ffka-schuetzen8a_WBS210, aktuell verbunden mit alb7 ; hatte die Probleme jedoch auch mit anderen Nodes schon.

Vielen Dank im Voraus!

Grüße
Mitsch

psy · 25. September 2016 um 13:22

Ja, es scheint da gerade Probleme zu geben (du bist nicht der einzige). Du kannst versuchen den Knoten neuzustarten und hoffen, dass er sich ein anderes Gateway als alb7 aussucht.

Mitsch · 25. September 2016 um 13:26

Danke erst mal für die Antwort - dachte zuerst es wäre ein lokales Problem…

Hatte ich schon mehrfach ohne Erfolg - werde ich jedoch auch gleich nochmal versuchen.

Aber hat auch schöne Seiteneffekte: Auf meiner FritzBox läuft jetzt IPv6 richtig und die wichtigen Sachen sind nun auch via IPv6 erreichbar…

EDIT: ist nur alb7 betroffen? Hatte die Probleme auch schon mit anderen Gateways in den letzten Tagen…

EDITEDIT: nachdem nach dem reboot noch immer alb7 aktiv war habe ich mit:

fastd.mesh_vpn_backbone_peer_alb7.enabled='0'
uci commit

diesen mal deaktiviert und habe nun (mit alb6) wieder IPv4 Konnektivität. Aber die Laufzeiten sind irgendwie nicht so der Knaller:

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=682ms TTL=50
Antwort von 8.8.8.8: Bytes=32 Zeit=240ms TTL=50
Antwort von 8.8.8.8: Bytes=32 Zeit=297ms TTL=50
Antwort von 8.8.8.8: Bytes=32 Zeit=641ms TTL=50

rgr · 25. September 2016 um 16:27

Für albufer7 kann die Probleme bestätigen. Bei anderen hab ich es in letzter Zeit nicht gesehen, albufer3 hab ich getestet und tut (falls jemand für den Test eine Referenz braucht).

Beim Testen jedes Mal nach einem Wechsel der albufer die Defaultroute überprüfen. Die wird beim Client nicht unbedingt erneuert, nur weil die Node wechselt.

herrbett · 26. September 2016 um 19:52

Hi zusammen,

über das Wochenende hatte ich leider noch keine Chance gehabt mir das Problem genauer anzuschauen.

Wie schon in der Mailingliste vermutet, war nicht die gesamte Konfiguration von albufer7 nicht 100%. Ich habe also die Konfiguration noch einmal von Hand geladen und aus meiner Sicht tut jetzt alles wieder. Ich hoffe ihr könnt das bestätigen.

rgr · 28. September 2016 um 17:32

Kann ich, client an nodes an albufer7 rennen wieder mit ipv4.

Mitsch · 4. November 2016 um 18:43

Beim albufer2 geht aktuell kein IPv4 mehr…

C:\Users\michi>ping 10.214.32.5

Ping wird ausgeführt für 10.214.32.5 mit 32 Bytes Daten:
Antwort von 10.214.32.5: Bytes=32 Zeit=34ms TTL=64
Antwort von 10.214.32.5: Bytes=32 Zeit=79ms TTL=64
Antwort von 10.214.32.5: Bytes=32 Zeit=37ms TTL=64
Antwort von 10.214.32.5: Bytes=32 Zeit=34ms TTL=64

Ping-Statistik für 10.214.32.5:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 34ms, Maximum = 79ms, Mittelwert = 46ms

C:\Users\michi>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

rgr · 5. November 2016 um 10:41

albufer7 mag auch nicht:

rgr@euit-Laptop:~$ ping www.google.de
PING www.google.de (108.177.96.94) 56(84) bytes of data.
^C
--- www.google.de ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

rgr@euit-Laptop:~$ ping6 www.google.de
PING www.google.de(2a00:1450:4013:c06::5e) 56 data bytes
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=1 ttl=57 time=64.2 ms
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=2 ttl=57 time=67.6 ms
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=3 ttl=57 time=65.1 ms
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=4 ttl=57 time=65.6 ms
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=5 ttl=57 time=68.2 ms
64 bytes from 2a00:1450:4013:c06::5e: icmp_seq=6 ttl=57 time=66.0 ms
^C
--- www.google.de ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5003ms
rtt min/avg/max/mdev = 64.202/66.163/68.272/1.397 ms

rgr@euit-Laptop:~$ ip r
default via 10.214.56.8 dev wlan0  proto static  metric 600 
10.214.32.0/19 dev wlan0  proto kernel  scope link  src 10.214.58.46  metric 600

rgr@euit-Laptop:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b0:5a:da:b3:57:9a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1378 qdisc mq state UP group default qlen 1000
    link/ether 18:4f:32:ce:31:99 brd ff:ff:ff:ff:ff:ff
    inet 10.214.58.46/19 brd 10.214.63.255 scope global dynamic wlan0
       valid_lft 545sec preferred_lft 545sec
    inet6 2a03:2260:a:b:a99b:6a7f:304b:9fb1/64 scope global temporary dynamic 
       valid_lft 10798sec preferred_lft 3598sec
    inet6 2a03:2260:a:b:6212:5046:7b24:9d42/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 10798sec preferred_lft 3598sec
    inet6 fe80::5f04:edb3:462:c60a/64 scope link 
       valid_lft forever preferred_lft forever

Mitsch · 5. November 2016 um 10:53

Danke @rgr für die Bestätigung - habe gestern auch noch supernodes deaktiviert und geprüft.
Geht glaube ich aktuell gar nicht…

Mein Monitoring RasPI im FF Netz hat sofort Alarm geschlagen…

herrbett · 6. November 2016 um 12:59

Hallo zusammen, habe gestern Abend den Fehler gefunden und behoben. Hoffe jetzt klappt wieder alles wie gewohnt.

rgr · 6. November 2016 um 14:26

albufer6 und 7 funktionieren

Mitsch · 7. November 2016 um 13:29

@herrbett Hallo Simon, kannst du eigentlich mal erklären wo es geklemmt hat? Was genau war zu tun?

herrbett · 7. November 2016 um 17:23

Hallo @Mitsch,

Es gab ein Routing Problem auf albufer2, das dazu geführt hat, da die IPv4 Rückroute für allen Traffic auf der anderen Gatewayserver über albufer2 liefen.
Habe die Fehlkonfiguration behoben und das ganze sollte jetzt nicht noch einmal vorkommen.

Mitsch · 7. November 2016 um 17:53

@herrbett da ich ja doch etwas Ahnung habe würde mich das Problem genauer interessieren, woher kam das Routing Problem? Weshalb hatten alle anderen Gateways dann alb2 als Rückroute? Wie wurde es behoben? Was wurde getan, dass das Problem nicht erneut auftritt?

herrbett · 7. November 2016 um 19:04

@Mitsch Das kann ich gerne auf den nächsten Freifunk Treffen genauer erläutern.

Mitsch · 7. November 2016 um 19:18

@herrbett Gerne! Vielen Dank dir jetzt schon mal…

Mitsch · 13. November 2016 um 21:19

Bin gerade dran meinen neuen Raspberry 3B einzurichten bezüglich FFKA-Monitoring und die Skripte etwas zu härten.
Dabei ging es wieder los:
C:\Users\michi>ping 10.214.56.8

Ping wird ausgeführt für 10.214.56.8 mit 32 Bytes Daten:
Antwort von 10.214.56.8: Bytes=32 Zeit=33ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=34ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=44ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=32ms TTL=64

Ping-Statistik für 10.214.56.8:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 32ms, Maximum = 44ms, Mittelwert = 35ms

C:\Users\michi>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),

Bei verbundenen Clienten funktioniert IPv4 wohl noch (mein Raspi1B) aber bei neuen Clienten nicht mehr…
Achja: alb3

EDIT: das wird das Problem von Freitag sein, der wird noch immer nicht neu gestartet sein - oder? Dann deaktiviere ich den entsprechend mal auf meinen Nodes…

Mitsch · 13. November 2016 um 21:51

Bekomme noch immer das selbe Default Gateway. Habe alb3 auf beiden Nodes deaktiviert und die nodes sogar neu gestartet.

Mit meinem Laptop und dem Raspi3B habe ich noch immer kein IPv4:

Drahtlos-LAN-Adapter WLAN:

   Verbindungsspezifisches DNS-Suffix: ffka
   IPv6-Adresse. . . . . . . . . . . : 2a03:2260:a:b:8139:919b:fad8:6f24
   Temporäre IPv6-Adresse. . . . . . : 2a03:2260:a:b:a9f9:eeef:d2e2:b81e
   Verbindungslokale IPv6-Adresse  . : fe80::8139:919b:fad8:6f24%7
   IPv4-Adresse  . . . . . . . . . . : 10.214.59.34
   Subnetzmaske  . . . . . . . . . . : 255.255.224.0
   Standardgateway . . . . . . . . . : fe80::1%7
                                       fe80::3c88:27ff:fe34:96a1%7
                                       10.214.56.8

C:\Users\michi>ping 10.214.56.8

Ping wird ausgeführt für 10.214.56.8 mit 32 Bytes Daten:
Antwort von 10.214.56.8: Bytes=32 Zeit=31ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=31ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=30ms TTL=64
Antwort von 10.214.56.8: Bytes=32 Zeit=32ms TTL=64

Ping-Statistik für 10.214.56.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 30ms, Maximum = 32ms, Mittelwert = 31ms

C:\Users\michi>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

herrbett · 13. November 2016 um 22:42

Hey @Mitsch,

Also als Router hast du Alb7 per DHCP bekommen. Albufer3 auszutragen bringt also erst mal nichts.

Was auf Alb7 los ist schaue ich mir grade an.