SSH-Verbindung zu Knoten gestört

[tobox]

Ich habe aktuell das Problem, dass ich unter Linux mit openssh meine Freifunk-Knoten mit Stable Firmware nicht per SSH erreichen kann.

Was ich bisher festgestellt habe:

• mit putty geht es
• Knoten mit experimental erreiche ich auch (da die an einem anderen Gateway hängen)
• das Problem (wahrscheinlich) nicht auf, wenn man bereits im Freifunk-Netz ist
• das Problem tritt von verschiedenen Netzen aus identisch auf (Telekom Natives IPv6, vServer bei Hetzner, Hurricane Electric)

Ich vermute, dass es ein MTU-Problem irgendwo im Freifunk-Netzwerk ist, wobei ich das mangels Debugmöglichkeiten nicht beweisen kann.

Kann jemand außer mir das Problem reproduzieren?

Bei ssh -v hängt bei mir der Verbindungsaufbau mit der Meldung “debug1: expecting SSH2_MSG_KEX_ECDH_REPLY”, was normalerweise auf MTU-Probleme hindeutet.

Verdächtig finde ich auch, dass schon ein ping -6 -s 1241 knotenname.nodes.ffrn.de fehlschlägt. Soweit ich weiß, muss bis 1272 oder 1280 alles gehen, sonst bekommt man definitiv probleme.

Bei Knoten mit experimental läuft bis ping -s 1354 alles problemlos.

Sobald ich mehr Infos habe, für ich die hier an.

[Update1]

Da ich per putty drauf komme, wollte ich jetzt debuggen. Dazu habe ich versucht, tcpdump zu installieren. Leider schlägt opkg update fehl (timeout?). Manuelle Downloads von IPv4-Server gehen normal, Downloads per IPv6 gehen nicht.

[Update2]

Das Problem ist symmetrisch. Man kann weder pings vom Knoten rausschicken die größer als 1240 sind, noch werden sie empfangen, wenn sie von extern kommen. Könnte ein reinges Ping-Filterungs-Problem sein, wenn nicht auch gleichzeitig TCP-Probleme da wären.

Leider macht Linux auf Interfaces mit MTU < 1280 kein IPv6. Sobald ich die MTU kleiner stelle, weigert Linux sich beharrlich, darüber IPv6 zu sprechen :-( Zum debuggen nicht gerade hilfreich, aber wahrscheinlich Standardkonform.

[Cheatha]

Ich kann das beschrieben Verhalten mit ping nachvollziehen. Mit der --mtu-Option von traceroute6 denke ich, kann man das auch eingrenzen, oder?

MTU 1200:

┌─[cheatha@mira] - [~] - [2017-09-28 04:37:58]
└─[0] <> traceroute6 --mtu $stable-knoten.nodes.ffrn.de 1200     
traceroute to $stable-knoten.nodes.ffrn.de (2a01:4f8:171:fcff:c24a:ff:fe0b:d3f0), 30 hops max, 1200 byte packets
 1  2a01:4f8::a:20:a (2a01:4f8::a:20:a)  0.915 ms  0.866 ms  0.790 ms
 2  core23.fsn1.hetzner.com (2a01:4f8:0:3::10d)  1.000 ms core24.fsn1.hetzner.com (2a01:4f8:0:3::111)  2.331 ms core23.fsn1.hetzner.com (2a01:4f8:0:3::10d)  1.545 ms
 3  ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)  0.896 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::16a)  0.911 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)  0.989 ms
 4  vm01.rz17.fks.de.ffrn.de (2a01:4f8:171:3242::2)  0.975 ms  0.868 ms  0.959 ms
 5  ext.v6upstream.rz17.fks.de.noc.ffrn.de (2a01:4f8:171:fcfe::1)  0.906 ms  0.961 ms  0.931 ms
 6  2a01:4f8:171:fcff:c24a:ff:fe0b:d3f0 (2a01:4f8:171:fcff:c24a:ff:fe0b:d3f0)  49.441 ms  27.375 ms  20.198 ms

MTU 1300:

┌─[cheatha@mira] - [~] - [2017-09-28 04:38:05]
└─[0] <> traceroute6 --mtu $stable-knoten.nodes.ffrn.de 1300
traceroute to $stable-knoten.nodes.ffrn.de (2a01:4f8:171:fcff:c24a:ff:fe0b:d3f0), 30 hops max, 1300 byte packets
 1  2a01:4f8::a:20:a (2a01:4f8::a:20:a)  1.007 ms  0.902 ms  0.917 ms
 2  core23.fsn1.hetzner.com (2a01:4f8:0:3::10d)  1.073 ms core24.fsn1.hetzner.com (2a01:4f8:0:3::111)  1.004 ms  1.901 ms
 3  ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)  0.962 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::16a)  1.001 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)  0.947 ms
 4  vm01.rz17.fks.de.ffrn.de (2a01:4f8:171:3242::2)  0.939 ms  0.896 ms  0.828 ms
 5  ext.v6upstream.rz17.fks.de.noc.ffrn.de (2a01:4f8:171:fcfe::1)  0.923 ms  0.414 ms  0.889 ms
 6  * * *

Gleiche MTU, aber ein experimenteller Knoten:

 ┌─[cheatha@mira] - [~] - [2017-09-28 04:41:10]
 └─[130] <> traceroute6 --mtu $experimentale-knoten.nodes.ffrn.de 1300         
 traceroute to tri-0.nodes.ffrn.de (2a01:4f8:171:fcff:32b5:c2ff:feb0:55ca), 30 hops max, 1300 byte packets
  1  2a01:4f8::a:20:a (2a01:4f8::a:20:a)  6.734 ms  13.864 ms  0.891 ms
  2  core24.fsn1.hetzner.com (2a01:4f8:0:3::111)  1.089 ms  1.046 ms  0.950 ms
  3  ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::166)  0.958 ms ex9k1.dc8.fsn1.hetzner.com (2a01:4f8:0:3::16a)  0.464 ms  1.008 ms
  4  * vm01.rz17.fks.de.ffrn.de (2a01:4f8:171:3242::2)  0.979 ms *
  5  ext.v6upstream.rz17.fks.de.noc.ffrn.de (2a01:4f8:171:fcfe::1)  0.916 ms  0.906 ms  0.945 ms
  6  2a01:4f8:171:fcff:32b5:c2ff:feb0:55ca (2a01:4f8:171:fcff:32b5:c2ff:feb0:55ca)  44.219 ms  22.809 ms  31.740 ms

[leah]

Moin,

@tobox

Ich vermute, dass es ein MTU-Problem irgendwo im Freifunk-Netzwerk ist, wobei ich das mangels Debugmöglichkeiten nicht beweisen kann.

Ja es gibt Probleme, die treten aber nur sporadisch auf, sonst hätte das ja früher nie funktioniert. Wir haben seit ziemlich langer Zeit da nichts im Backbone verändert.

@tobox

Ich habe aktuell das Problem, dass ich unter Linux mit openssh meine Freifunk-Knoten mit Stable Firmware nicht per SSH erreichen kann.

Ich kann es aktuell mit einem aktuellen Debian Testing über meinen v6 Tunnel nicht nachvollziehen. Über einen Server mit Debian stable und oldstable schon. Alle drei sind wie unsere Gateways im Netz von Hetzner.

@tobox

Bei ssh -v hängt bei mir der Verbindungsaufbau mit der Meldung “debug1: expecting SSH2_MSG_KEX_ECDH_REPLY”, was normalerweise auf MTU-Probleme hindeutet

Es kann gut sein, dass dieses Paket bzw. die Pakete einfach zu groß sind, es durch ein DF Bit dazu kommt, dass die Pakete verworfen werden weil nicht zu fragmentieren oder es zu einer ungeschickten doppelten Fragmentierung kommt wodurch die Pakete auch verworfen werden.

@tobox

Verdächtig finde ich auch, dass schon ein ping -6 -s 1241 knotenname.nodes.ffrn.de fehlschlägt. Soweit ich weiß, muss bis 1272 oder 1280 alles gehen, sonst bekommt man definitiv probleme.

Damit die Werte aussagekräftig bleiben, solltest du hier noch das DF Bit setzen.

@tobox

Bei Knoten mit experimental läuft bis ping -s 1354 alles problemlos.

Dort haben wir ja auch die MTU verbessert und so angepasst das Probleme in Zukunft vermieden werden sollen. Das bekommen mit dem nächsten großen Update auch alle Knoten. Siehe auch dieses Issue hier: docs: fastd: recommend better default mtu by mweinelt · Pull Request #1210 · freifunk-gluon/gluon · GitHub

@tobox

Leider schlägt opkg update fehl (timeout?). Manuelle Downloads von IPv4-Server gehen normal, Downloads per IPv6 gehen nicht.

Bitte ein eigenes Thema dafür aufmachen.

[tobox]

@leah

Ja es gibt Probleme, die treten aber nur sporadisch auf, sonst hätte das ja früher nie funktioniert. Wir haben seit ziemlich langer Zeit da nichts im Backbone verändert.

Nun ja, es gab vor kurz vor @NurticVibe’s Urlaub ein Problem mit GW02, der sich auf ein MTU Problem in Verbindung mit noch einem anderen Problem zurückführen ließ. Und da sowohl die Experimental als auch die Stable denselben IPv6-Gateway benutzen, ist vielleicht in dem Zuge was kaputtrepariert worden (Fehler so behoben, dass Experimental ging, und dabei Stable kaputt gemacht). Ich will nicht sagen, dass es so war, ich sage nur, es könnte so passiert sein.

@leah

Ich kann es aktuell mit einem aktuellen Debian Testing über meinen v6 Tunnel nicht nachvollziehen. Über einen Server mit Debian stable und oldstable schon. Alle drei sind wie unsere Gateways im Netz von Hetzner.

Ich glaube, mit Stable und Testing hat es nichts zu tun. VIelleicht hat Deine Tunnellösung schon eine MTU oder MSS Clamping, die das ganze repariert.

@leah

Es kann gut sein, dass dieses Paket bzw. die Pakete einfach zu groß sind, es durch ein DF Bit dazu kommt, dass die Pakete verworfen werden weil nicht zu fragmentieren oder es zu einer ungeschickten doppelten Fragmentierung kommt wodurch die Pakete auch verworfen werden.

Kann sein, darf aber nicht. SSH benutzt einfach TCP, und das weiß nichts von MTUs und Fragmentierung. Es ist kein Fehler im SSH client, es ist nur so, dass der Fehler bei diesem einen Client vermehrt auftritt.

@leah

Damit die Werte aussagekräftig bleiben, solltest du hier noch das DF Bit setzen.

Das habe ich vorhin auf die Schnelle nicht kapiert. Bei IPv4 weiß ich noch, wie man das genau machen musste. Bei IPv6 gibt es ja keine Fragmentierung, und man kann halt PMTU forcieren oder ignorieren, und ich habe auch mit -M do/want/dont rumgespielt, aber die Ergebnisse ehrlich gesagt nicht verstanden.

@leah

Bitte ein eigenes Thema dafür aufmachen.

Da ich mir relativ sicher bin, dass es ein Folgefehler ist (TCP geht halt nicht richtig), halte ich das für nicht sinnvoll. Wenn wir das SSH-Problem lösen, bin ich mir sicher, dass auch opkg wieder funktioniert.

Schonmal Danke, dass Du Dich um das Problem kümmerst, trotz Master Thesis, neuer Backbone Hardware, kaputtem Internetanschluss und dem sonstigen Papierkrieg :-)

[leah]

@tobox

Ich will nicht sagen, dass es so war, ich sage nur, es könnte so passiert sein.

Da kann ich die Beruhigen. Nein das ist nicht passiert.

@tobox

Kann sein, darf aber nicht. SSH benutzt einfach TCP, und das weiß nichts von MTUs und Fragmentierung. Es ist kein Fehler im SSH client, es ist nur so, dass der Fehler bei diesem einen Client vermehrt auftritt.

Es kann aber auch gut sein, dass das Problem auf einer Schicht unter TCP auftritt und TCP weiß sehr wohl etwas von der MTU und Fragmentierung wenn vielleicht auch nur sehr indirekt. All das wirkt sich dann trotzdem auf SSH aus.

@tobox

Wenn wir das SSH-Problem lösen, bin ich mir sicher, dass auch opkg wieder funktioniert.

Tut es denn woanders? Bzw. kannst du den Mirror von extern über IPv6 korrekt erreichen?

[tobox]

@leah

Tut es denn woanders? Bzw. kannst du den Mirror von extern über IPv6 korrekt erreichen?

Ja, auf den aktuellen Experimental Knoten geht es. Und die benutzen dieselbe Update-URL wie Knoten mit der 0.7.1, und damit geht es nicht.

Mit stable Knoten geht es auch nicht, wobei da scheinbar wirklich die Dateien fehlen:

root@Bensheim-Roadwarrior-001:~# opkg update
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/ar71xx/gener                                                   ic/packages/base/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/ar71xx/generic/packages/packages/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/ar71xx/generic/packages/luci/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/ar71xx/generic/packages/routing/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/ar71xx/generic/packages/telephony/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found

[tobox]

Da aktuell die Experimental deutlich besser läuft als die Stable, mal ein Vorschlag:

Sollten wir vielleicht statt dieses SSH Problem zu fixen und @hdvalentin’s Seitenladeproblem weiter zu verfolgen einfach die Experimental zur Stable machen?

[NurticVibe]

@tobox

einfach die Experimental zur Stable machen

Ist aktuell in Planung

[leah]

Als mögliche Erklärung. Es könnte sein das die Fragmentierung an den Bridges in unser Netz nicht korrekt läuft bzw. nicht korrekt möglich ist. Mit der Umstellung von gw02 auf eine MTU von 1312 sind wir auch auf den Verbindungen zwischen den Knoten auf 1312 als MTU gewechselt, die das früher vielleicht noch besser hinbekommen haben. Auf jeden Fall sollte das Problem mit der aktuellen Stable nicht mehr auffallen.

[tobox]

@leah

@tobox

Nun ja, es gab vor kurz vor @NurticVibe’s Urlaub ein Problem mit GW02, der sich auf ein MTU Problem in Verbindung mit noch einem anderen Problem zurückführen ließ. Und da sowohl die Experimental als auch die Stable denselben IPv6-Gateway benutzen, ist vielleicht in dem Zuge was kaputtrepariert worden (Fehler so behoben, dass Experimental ging, und dabei Stable kaputt gemacht). Ich will nicht sagen, dass es so war, ich sage nur, es könnte so passiert sein.

Da kann ich die Beruhigen. Nein das ist nicht passiert.

…

@leah

Mit der Umstellung von gw02 auf eine MTU von 1312 sind wir auch auf den Verbindungen zwischen den Knoten auf 1312 als MTU gewechselt, die das früher vielleicht noch besser hinbekommen haben.

Nenn mich Klugscheißer, aber hatte ich nicht genau das vermutet? ;-)
Oder war es doch noch was anderes?

Aber Hauptsache, das Netz läuft wieder!

[leah]

Ja, das hatte ich vergessen. Soll vorkommen :P