WR1043N v5, Clients bekommen kein Internet und andere Probleme

[wusel]

@ErwinLindemann

Das Argument „Freizeit und unentgeltlich“ gilt […] allerdings nicht mehr, wenn man die unentgeltlich in der Freizeit erbrachte Leistung nicht wirklich auf die Reihe bringt

Does not compute. Du kannst Deine Angestellten wegen Minderleistung abzumahnen versuchen und danach rauszuschmeißen. Als nicht involvierter Nutznießer im Falle Freifunk darfst Du es gerne nicht nutzen. Oder bei Treffen Deine Kritik anbringen und erklären, warum Du zwar mäkeln, aber nicht machen helfen kannst. (Ja, Spenden sind auch gerne gesehen, aber solange das Spenden­auf­kom­men keine Jobs finanziert, die die Arbeit machen, löst das das Grundproblem eben nicht. Vereine und vereinsähnliche Zusammenschlüsse leben davon, daß es auch Macher, nicht nur Zahler gibt.)

Aber zum Thema:

@wusel

Aber zwischen der Gluon-VM und dem Gateway könnten Daten verloren gehen, das müßte man alles genauer sich ansehen.

Ich hab’ mal eben ein kleines Script geschrieben, daß sich das genauer ansieht — wollte ich für unser Setup eh’ schon mal, nun läuft’s halt auf 2 VMs Das probiert 1.1.1.1 sowie, sofern vorhanden, das Default-GW anzupingen (Nutzersicht) und geht dann noch fix auf den Freifunk-Knoten (die Gluon-VM) und guckt sich das auf Batman-Ebene an:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 4.155/4.924/9.039/1.387 ms

PING 10.187.13.1 (10.187.13.1) 56(84) bytes of data.

--- 10.187.13.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 2.511/3.511/4.937/0.735 ms

2019-08-01 23:18:01: EXT. OK   / DEFAULT OK    

Gateway status:
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/72:48:a7:05:da:c3 (bat0)]
   fe:ed:be:ff:ff:03 (110) fe:ed:be:ff:ff:04 [  mesh-vpn]: 500.0/500.0 MBit
=> fe:ed:be:ff:ff:04 (154) fe:ed:be:ff:ff:04 [  mesh-vpn]: 500.0/500.0 MBit

traceroute to fe:ed:be:ff:ff:03 (fe:ed:be:ff:ff:03), 50 hops max, 20 byte packets
 1: fe:ed:be:ff:ff:04  2.478 ms  2.228 ms  2.093 ms
 2: fe:ed:be:ff:ff:03  2.767 ms  7.473 ms  2.521 ms

traceroute to fe:ed:be:ff:ff:04 (fe:ed:be:ff:ff:04), 50 hops max, 20 byte packets
 1: fe:ed:be:ff:ff:04  5.016 ms  3.090 ms  3.367 ms

Und wenn man mal fix durchgreppt – das Script läuft 1x in der Minute –, zeigen sich komische Effekte:

2019-08-01 23:27:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:28:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:29:01: EXT. OK   / DEFAULT FAIL  
2019-08-01 23:34:01: EXT. FAIL / DEFAULT MISSING 
2019-08-01 23:35:01: EXT. FAIL / DEFAULT MISSING 
2019-08-01 23:33:01: EXT. FAIL / DEFAULT FAIL  
2019-08-01 23:30:01: EXT. FAIL / DEFAULT FAIL  
2019-08-01 23:31:01: EXT. FAIL / DEFAULT FAIL  
2019-08-01 23:32:01: EXT. FAIL / DEFAULT FAIL  
2019-08-01 23:36:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:37:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:38:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:39:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:40:01: EXT. FAIL / DEFAULT FAIL  
2019-08-01 23:41:01: EXT. OK   / DEFAULT OK    
2019-08-01 23:42:01: EXT. OK   / DEFAULT OK    

Und das ist komisch, denn während IP(v4) um 23:40:01 nicht funktionierte, tat es auf Batman-Ebene noch:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9195ms


PING 10.187.13.1 (10.187.13.1) 56(84) bytes of data.

--- 10.187.13.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9196ms


2019-08-01 23:40:01: EXT. FAIL / DEFAULT FAIL  

Gateway status:
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/72:48:a7:05:da:c3 (bat0)]
=> fe:ed:be:ff:ff:03 (212) fe:ed:be:ff:ff:03 [  mesh-vpn]: 500.0/500.0 MBit
   fe:ed:be:ff:ff:04 (164) fe:ed:be:ff:ff:03 [  mesh-vpn]: 500.0/500.0 MBit

traceroute to fe:ed:be:ff:ff:03 (fe:ed:be:ff:ff:03), 50 hops max, 20 byte packets
 1: fe:ed:be:ff:ff:03  2.492 ms  2.344 ms  3.626 ms

traceroute to fe:ed:be:ff:ff:04 (fe:ed:be:ff:ff:04), 50 hops max, 20 byte packets
 1: fe:ed:be:ff:ff:03  2.720 ms  2.466 ms  3.278 ms
 2: fe:ed:be:ff:ff:04  2.769 ms  2.449 ms  2.523 ms

Vielleicht kennt ja jemand Gründe, warum IP über Batman klemmt, wenn Batman selbst offensichtlich noch die L2-Wolke zusammenhält? Weil: wenn IP-over-Batman klemmt, ist’s auch mit IP-basierten Diensten wie DHCP Essig …

[heini66]

@wusel
script? wo? sauger ist an …

deine frage nach den gründen wird aber wohl nur @anon68922371 oder @rubo77 beantworten können.

[wusel]

Neugiernase. Nimm dies, ist ja nicht Pulizer-verdächtig

Ja, weitere Analyse macht wahrscheinlich nur Sinn mit Zugriff auf die Infrastruktur.

[anon68922371]

Puh warum das so sein könnte übersteigt meine Administrativen Fähigkeiten…

@wusel
Wenn du willst aber nur wenn du wirklich möchtest kann ich dir ja mal SSH Zugriff zu den beiden GWs geben…

Sollst dich aber nicht genötigt fühlen das tun zu müssen. Hilfst uns ja schon genug!!

[adorfer]

@wusel

Weil: wenn IP-over-Batman klemmt, ist’s auch mit IP-basierten Diensten wie DHCP Essig

Solche Effekte kenne ich nur aus alten Batman-Versionen-Releases (2015/2016).
Aber traditionell haben wir da in unseren Firmwares packages drin, die bei verschwindenden IPv6 rebooten (anpingbarkeit einer anycast-Adresse, die auf allen Gateways vorhanden ist).

Beispiel:
https://github.com/eulenfunk/packages/blob/v2018.1.x/gluon-hotfix/files/lib/gluon/hotfix/rebootIfNoGw.sh

[anon68922371]

@adorfer

Solche Effekte kenne ich nur aus alten Batman-Versionen-Releases (2015/2016).

batctl -v
batctl 2019.2 [batman-adv: 2016.4]

Damit dürften wir doch das Problem gefunden haben?

##Edit
fixed!

batctl -v
batctl 2019.2 [batman-adv: 2019.2]

Komischer weise war das nur auf nord3, auf den anderen GWs auch auf denen für anderen Domänen war alles tutti.

[wusel]

@anon68922371

fixed

Hmm, wann?

root@ffnord-client:~# grep 2019-08- /var/tmp/ffnord.log | grep FAIL | tail -5
2019-08-02 15:06:01: EXT. FAIL / DEFAULT FAIL  
2019-08-02 15:14:01: EXT. FAIL / DEFAULT FAIL  
2019-08-02 15:15:01: EXT. FAIL / DEFAULT FAIL  
2019-08-02 15:43:01: EXT. FAIL / DEFAULT FAIL  
2019-08-02 15:42:01: EXT. FAIL / DEFAULT FAIL  

Im Detail (mittlerweile laufen die Pings sowie die batman-Auswertung parallel, um vergleichbare Werte zu haben; ToDo: auch die batman-Traces parallelisieren):

2019-08-02 15:42:01: EXT. FAIL / DEFAULT FAIL  

15:42:01 - PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9204ms

15:42:01 - PING 10.187.13.1 (10.187.13.1) 56(84) bytes of data.

--- 10.187.13.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9209ms

15:42:01 - Batman status:
      Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/72:48:a7:05:da:c3 (bat0)]
=> fe:ed:be:ff:ff:03 (231) fe:ed:be:ff:ff:03 [  mesh-vpn]: 500.0/500.0 MBit
   fe:ed:be:ff:ff:04 (171) fe:ed:be:ff:ff:03 [  mesh-vpn]: 500.0/500.0 MBit

traceroute to fe:ed:be:ff:ff:03 (fe:ed:be:ff:ff:03), 50 hops max, 20 byte packets
 1: *   *   *   *
 2: *   *   *   *
 3: *   *   *   *
 4: *   *   *   *
 5: *   *   *   *
 6: *   *   *   *
 7: *   *   *   *
 8: *   *   *   *
 9: *   *   *   *
10: *   *   *   *
11: *   *   *   *
12: *   *   *   *
13: *   *   *   *
14: *   *   *   *
15: fe:ed:be:ff:ff:03   *  2.701 ms  4.970 ms

traceroute to fe:ed:be:ff:ff:04 (fe:ed:be:ff:ff:04), 50 hops max, 20 byte packets
 1: fe:ed:be:ff:ff:03  2.730 ms  3.095 ms  5.888 ms
 2: fe:ed:be:ff:ff:04  3.042 ms  4.028 ms  3.589 ms

[anon68922371]

Als ich den Post verfasst habe, hatte ich kurz zuvor Batman-adv aktualisiert und das gw rebooted.

[adorfer]

Allo wenn ich paranoid werden wollt, dann schaut mal, ob da vielleicht mehrere Knoten mit der gleiche Mac (des Gateways) I’m Batman-Netz sind. Also entweder Vorsatz oder schlicht f’up von einem Gateway-Setup, das per Cloning gebaut wurde…

[anon68922371]

@adorfer

schlicht f’up von einem Gateway-Setup, das per Cloning gebaut wurde…

Das kann ich ausschließen.

Alle GWs hab ich mittels Puppet aufgesetzt.

Die Manifeste sind alle unique.

@adorfer

Allo wenn ich paranoid werden wollt, dann schaut mal, ob da vielleicht mehrere Knoten mit der gleiche Mac (des Gateways) I’m Batman-Netz sind.

Wie könnte ich das feststellen?

[wusel]

Habt Ihr was gemacht, @anon68922371?

Mein Testskript auf der VM hinter der FFNord-Gluon-VM zeigt für heute (ok, nur 22,75 von 24 Stunden) signifikant weniger Zeilen mit Problemen:

root@ffnord-client:~# for i in 2019-08-04 2019-08-05 2019-08-06 ; do grep ^${i} </var/tmp/ffnord.log >/tmp/${i}.delme ; lines=$(wc -l </tmp/${i}.delme); errors=$(grep FAIL </tmp/${i}.delme | wc -l) ; echo "${i}: Tests: $(printf %4d ${lines}) Fehler: $(printf %4d ${errors})" ; done
2019-08-04: Tests: 1440 Fehler:  328
2019-08-05: Tests: 1440 Fehler:  332
2019-08-06: Tests: 1373 Fehler:   14
root@ffnord-client:~# grep FAIL /tmp/2019-08-06.delme 
2019-08-06 03:01:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 03:02:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 03:04:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 03:03:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 03:05:01: EXT. FAIL / DEFAULT MISSING 
2019-08-06 03:06:01: EXT. FAIL / DEFAULT MISSING 
2019-08-06 03:07:01: EXT. FAIL / DEFAULT MISSING 
2019-08-06 03:12:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:00:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:02:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:04:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:05:01: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:10:02: EXT. FAIL / DEFAULT FAIL  
2019-08-06 21:11:01: EXT. FAIL / DEFAULT FAIL

[anon68922371]

Nichts.

Vor 5 Tagen auf nord3 Batman aktualisiert sonst nix!

[wusel]

Merkwürden. Danke für’s Feedback.

[adorfer]

@anon68922371

batctl -v
batctl 2019.2 [batman-adv: 2016.4]

Damit dürften wir doch das Problem gefunden haben?

Es ist zu hoffen, dass es das gewesen ist.
Fehlt noch Rückmeldung von den betroffenen Nutzern hier.

[wusel]

Das Timing paßt nicht zum Meßergebnis; aber mit nur 1 Meßstelle kann das auch ein Phantomproblem dort sein.

[adorfer]

@adorfer

Fehlt noch Rückmeldung von den betroffenen Nutzern hier.

@heini66 @ErwinLindemann
Wie schaut’s denn aktuell aus bei Euch in der lokalen Wahrnehmung?

[ErwinLindemann]

Bei mir zuhause gerade OK, zu den anderen Knoten kann ich erst morgen was sagen. Hab gleich noch Termine… Gestern früh waren da aber noch die gleichen Probleme, auch WLAN löschen und neu verbinden gab mit dem Smartphone nur „IP wird angefordert“ und nach langer Zeit Rückfall auf das andere WLAN.

[heini66]

Ich häng nicht ( mehr ) im ffnord seit wir ff nordheide gebaut haben… ca 2 jahre…

[wusel]

@Matze1

Bei Verbindung ins Freifunk-Netz dauert es manchmal eine ziemliche Ewigkeit, bis – wenn überhaupt – Zugriff auf das Internet möglich ist. Manchmal geht es auch gar nicht.

Das »Problem« an dieser Stelle ist, daß unterschiedliche Geräte heute unterschiedliche Methoden nutzen um zu erkennen, ob Internetzugang besteht. Wenn dieser Test auf das veraltete Internet Protokoll (Version 4, IPv4) setzt, gibt’s „kein Internet“, bis per DHCP eine IP-Adresse sowei die Nameserver zugewiesen wurden, und das passiert in »Gluon-basierten« Freifunknetzen eben vom Gateway im Rechenzentrum. Kurze Verzögerungen sind möglich, aber deutlich länger als ein paar Sekunden deutet auf Probleme hin.

Der positive Trend setzt sich in meinen Messungen allerdings fort, von vormals rund 23 Prozent Problemen beim Netzzugriff sind vorgestern und gestern nur noch unter 1% fehlerhafte Zugriffe verzeichnet worden:

2019-08-04: Tests: 1440 Fehler:  328
2019-08-05: Tests: 1440 Fehler:  332
2019-08-06: Tests: 1440 Fehler:   14
2019-08-07: Tests: 1440 Fehler:    9

Aber ich kann zu jeder Zeit die Statusseite anderer Knoten aufrufen bzw. deren IPv6 Adresse anpingen. Das finde ich auch ziemlich merkwürdig.

Das ist technisch erklärbar: IPv4 wird (vom Gateway) zugewiesen (Client stellt 'ne Anfrage, Server beantwortet diese mit einem IPv4-Angebot, Client bestätigt die Annahme dieses Angebotes und nutzt diese IPv4-Adresse für die zugewiesene Gültigkeit, nach Hälfte der Gültigkeit geht das Spiel von vorne los), bei IPv6 hingegen von den Gateways periodisch ein sogenannter »Präfix« (64 Bit) im Netz bekanntgegeben, aus diesem Präfix generiert ein Endgerät dann seine 128 Bit lange IPv6-Adresse. Daher kannst Du alle anderen Knoten im Netz erreichen, denn die Knoten untereinander nutzen nur IPv6. (Nextnode-IPs sind speziell, die sind auf jedem Knoten gleich und werden dort quasi netztechnisch „abgefangen“.)

@Matze1

Ich hatte testweise mal feste IP-Adressen eingetragen, mit der Folge, dass sich der Router gar nicht mehr mit Freifunk verbinden konnte und die Offline-SSID ausgestrahlt hat.

Ah, falsche Ebene: Du sollst nicht den Freifunk-Knoten umkonfigurieren, sondern Dein Endgerät (Daten kann man aus dem manifest.pp entnehmen.)

Wenn Dein Endgerät damit „ins Internet“ käme … hast Du irgendwo ein DHCP-Firewall-Problem; zumindest seit dem 6. August sehe ich keine gravierenden DHCP-Probleme mehr. Aber …

@Matze1

Ich habe jetzt noch mal die gespeicherte WLAN-Verbindung in Windows 10 gelöscht und mich neu mit Freifunk-WLAN verbunden. Es scheint jetzt zu klappen. Es hat jetzt nur wenige Sekunden gedauert, bis Zugriff auf das Internet möglich war.

… Dein Problem scheint ja auch sich in Wohlgefallen aufgelöst zu haben Genauso wie bei @michi84.

Warten wir also noch auf @ErwinLindemanns Bericht

[Ditschi]

Bei mir geht jetzt auch alles. Das ist eine Erwähnung wert, denn wir haben Freifunk hier eigentlich gar nicht mehr genutzt, weil es sowieso nie eine Verbindung gab.