Gateways bei APs mit Uplink nicht mehr direkt nutzbar

Korrupt · 2. September 2018 um 18:28

Hoi,

ich hatte meine Gateways immer mit Uplink versorgt, weils die Leitung hergibt und Verteilen ja ne gute Sache ist, seit den (verstärkten) Schwierigkeiten im Wuppertal-Netz verbinden die sich aber nicht mehr zu welchen Uplinks auch immer, sondern nur noch indirekt über andere Accesspoints in der lokalen Wolke (Utopiastadt). Ich denke, das ist nicht im Sinne des Erfinders. Neustart hat nichts gebracht.
Ist das ein known bug der weggebrochenen Supernodes? kann ich lokal da irgendwas machen? denn an sich sollten sich die APs ja einfach zu nem anderen verbinden, wenn ein Uplink steht.

Ab davon: ich bin kein Netzwerker, aber jenseits des Knowhows etc., kann man irgendwie was unterstützen, was die aktuelle Infrastruktursituation in WUP angeht?

greetz
Richie

DSchmidtberg · 2. September 2018 um 18:40

Um welchen Router geht es genau? Es sollten sich immer noch alle verbinden können.

Korrupt · 2. September 2018 um 18:42

Die Schafwolke neben Utopiastadt, Wolkenschaf, Fabrikschaf und Strassenschaf. Alle drei mit Uplink, aber gehen über externe Nodes raus. Die Gateway-IP, die sie vorher hatten, hab ich nun nicht auf dem Schirm. Liegts an mir? ich hab halt am Setup null verändert und bis vor kurzem waren sie immer über fastd angebunden.

DSchmidtberg · 2. September 2018 um 18:48

Sind die alle am selben Internetanschluss? Welcher Anbieter? Die installierte Firmware sollte funktionieren.

Korrupt · 2. September 2018 um 18:54

Am selben, Unitymedia.

Korrupt · 10. September 2018 um 19:52

Ich schubs mal hoch… Situation unverändert. Unitymedia war ja mal was wegen ipv4-Nat-nat, aber das war an sich lange her und die Updates nahmen die Router ja alle mit. Weiter, weil ggf. relevante Info: sollte die hier gar nicht wirklich betreffen, weil ich nicht mit DSLite gestraft bin, sondern an sich eine Businessleitung mit fixer IPv4 liegt. Nur mit fixer v4, eine IPv6 ist hier explizit keine dabei.
Hilft das beim Eingrenzen? ich finds nach wie vor schade um den Uplink, auch wenn grade die Flaschenhälse ja woanders liegen sollen…

Vincent · 11. September 2018 um 04:51

„Pauschal“ arbeite bitte mal diese kleine Anleitung durch:

https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr

Zusätzlich können Variablen wie der Teredo-Filter dir Probleme bereiten.

Korrupt · 21. September 2018 um 20:18

OK. Teredo-Filter sind aus. SSH komm ich drauf, Gateway ist pingbar.

root@Wolkenschaf:~# batctl p 00:be:e1:ba:fe:60
PING 00:be:e1:ba:fe:60 (00:be:e1:ba:fe:60) 20(48) bytes of data
20 bytes from 00:be:e1:ba:fe:60 icmp_seq=1 ttl=48 time=37.25 ms
20 bytes from 00:be:e1:ba:fe:60 icmp_seq=2 ttl=48 time=46.27 ms
20 bytes from 00:be:e1:ba:fe:60 icmp_seq=3 ttl=48 time=38.77 ms
20 bytes from 00:be:e1:ba:fe:60 icmp_seq=4 ttl=48 time=112.44 ms

Router pingt auch „ganz nach draußen“, nur ohne dns (8.8.8.8 pingbar, google.com nicht).

ifconfig scheint interessant: bat0 hat nur einen lokalen ipv6, keine Scope:global.

bat0 Link encap:Ethernet HWaddr 30:B5:C2:21:6C:99
inet6 addr: fe80::32b5:c2ff:fe21:6c99/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:100768 errors:0 dropped:0 overruns:0 frame:0
TX packets:20495 errors:0 dropped:61 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26047639 (24.8 MiB) TX bytes:2028059 (1.9 MiB)

Scope:global krieg ich aber unter
br-client Link encap:Ethernet HWaddr 30:B5:C2:21:6C:99
inet6 addr: fda0:747e:ab29:e1ba:32b5:c2ff:fe21:6c99/64 Scope:Global
inet6 addr: fe80::32b5:c2ff:fe21:6c99/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:129586 errors:0 dropped:0 overruns:0 frame:0
TX packets:10027 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26956311 (25.7 MiB) TX bytes:2810438 (2.6 MiB)

Auf die fda0:747e:ab29:e1ba:32b5:c2ff:fe21:6c99 kann er sich auch selber pingen, aber das mag nichts heißen. Auf den gateway hats leichten packetloss, aber das wird an der Anbindung liegen. fastd restart brachte nichts, uci show wirft vernünftig wirkende Configs.

Any ideas? getestet nun auf dem 901, nicht auf den bekannt schwachbrüstigen 841NDs.

phip · 23. September 2018 um 12:02

Leider nur ein wenig Hilfe auf die Schnelle, wegen Zeit und so. Tut mir Leid.

Die Frage ist, wie es aussieht, wenn Du dich im Freifunk befindest und nicht auf dem Router. Bekommt dein Endgerät eine IP, kann es Domainnamen auflösen und sie erreichen? ipv6 wurde vorerst deaktiviert bis die Sache mit den neuen Servern läuft … dauert noch ca. 2 Monde. Auf dem Router ist nur wichtig, ob der fastd-Tunnel zu Stande gekommen ist. Tests mit DNS kannst Du nicht auf dem Router ausführen, soweit ich weiß.

mit batctl tr 00:be:e1:ba:fe:60 kannst Du genau betrachten, über welche Knoten Batman läuft. batctl tr 10.3.0.246 mit dem GW als Ziel sollte auch laufen. Dauert nach dem Neustart um die 2-10 min. Auf deinem fastd-Router sollte nur ein Hop zu sehen sein.

Im Sinne des Erfinders ist es ein flächendeckendes, vermaschtes Netzwerk aufzubauen. Das mit dem Tunnel ist nur Brückentechnologie.

Korrupt · 23. September 2018 um 15:46

Kein Problem, und wenn ein „Nebenwirkung von ipv6 weg“ rauskommt, ists ja auch erst mal gut. Über „meine“ Nodes komm ich mit im FF angemeldeten geräten durchaus ins Netz, krieg ne ipv4 und 2 ipv6, es tut schon, wie es soll, nur eben nicht auf den fastd, und damit eben langsamer/schmalbandiger, als die Wolke sein müsste.

Hops macht der Knoten via ipv4 wie auch -6 2 -

root@Wolkenschaf:~# batctl tr 00:be:e1:ba:fe:60
traceroute to 00:be:e1:ba:fe:60 (00:be:e1:ba:fe:60), 50 hops max, 20 byte packets
1: 2a:05:37:e6:bd:c8 49.422 ms 6.023 ms 8.824 ms
2: 00:be:e1:ba:fe:60 170.038 ms 24.882 ms 241.390 ms
root@Wolkenschaf:~# batctl tr 10.3.0.246
traceroute to 10.3.0.246 (00:be:e1:ba:fe:60), 50 hops max, 20 byte packets
1: 2a:05:37:e6:bd:c8 16.170 ms 247.472 ms 159.346 ms
2: 00:be:e1:ba:fe:60 272.335 ms 21.496 ms 481.397 ms

Was mich irritiert: Als Gateway hat das Schaf aber die Mirker59 gewählt, https://wup.map.eulenfunk.de/#!v:m;n:10feed9c2868 und die 2a:05:37…-IP springt mir jetzt bei den benachbarten Knoten nicht ins Auge.

Kurz noch zur „Dringlichkeit“: An sich „funktionierts ja“, nur eben mit der bekannt langsamen anbindung, und mein persönliches Seelenheil hängt nicht an fastd für drei Nodes hier. Gedanke ist eher, wenn hier Probleme auftreten, die vielleicht anderswo auch da sind und auf Schwierigkeiten/Nebenwirkungen mit der aktuellen Nodesituation hindeuten, ists vielleicht hilfreich. Von daher, wegen mir sehr gern Prio bei den frischen Kisten

phip · 23. September 2018 um 19:09

Danke für den Link. Jetzt wird die Situation einigermaßen klarer: man kann sich auf die Karte nicht wirklich verlassen … und auf Batman auch nicht. Die Situation auf w6 sieht so aus:

phip@w6_c01:~# batctl -m bat-wup tr 10:fe:ed:9c:28:68
traceroute to 10:fe:ed:9c:28:68 (2a:05:37:e6:bd:c8), 50 hops max, 20 byte packets
 1: 2a:05:37:e6:bd:c8  19.343 ms  20.003 ms  19.960 ms

„Wolkenschaf“ wird also direkt vom w6 erreicht.

phip@w6_c01:~# batctl -m bat-wup tr f8:1a:67:cb:02:8c
traceroute to f8:1a:67:cb:02:8c (e6:ad:ca:c9:f0:20), 50 hops max, 20 byte packets
 1: 2a:05:37:e6:bd:c8  19.927 ms  19.757 ms  21.002 ms
 2: ea:09:8f:dc:59:42  20.919 ms  22.726 ms  23.934 ms
 3: e6:ad:ca:c9:f0:20  24.330 ms  38.436 ms  34.658 ms

Nehme ich aber den „Straßenschaf“ als Ziel

phip@w6_c01:~# batctl -m bat-wup tr 60:e3:27:c6:cb:68
traceroute to 60:e3:27:c6:cb:68 (1e:27:d8:1e:87:52), 50 hops max, 20 byte packets
 1: 2a:05:37:e6:bd:c8  21.230 ms  19.279 ms  20.803 ms
 2: ea:09:8f:dc:59:42  27.109 ms  27.952 ms  21.730 ms
 3: 0a:f5:0f:11:71:4a  24.099 ms  22.068 ms  35.081 ms
 4: 1e:27:d8:1e:87:52  46.184 ms  23.763 ms  33.441 ms

oder „Mirker39“, geht es durch „was weiß“ ich durch. Vor Gluon gab es noch eine Möglichkeit zu erfahren, welche MAC zu welchem Knoten gehört. Egal/anderes Thema.

KjuBie ~ # batctl tr 60:e3:27:c6:cb:68
traceroute to 60:e3:27:c6:cb:68 (1e:27:d8:1e:87:52), 50 hops max, 20 byte packets
 1: 00:be:e1:ba:fe:60  32.662 ms  32.385 ms  32.026 ms
 2: 2a:05:37:e6:bd:c8  51.398 ms  57.767 ms  62.970 ms
 3: ea:09:8f:dc:59:42  67.036 ms  57.098 ms  54.577 ms
 4: 0a:f5:0f:11:71:4a  65.844 ms  60.656 ms  62.262 ms
 5: 1e:27:d8:1e:87:52  78.261 ms  58.378 ms  56.013 ms

selbst von mir zu Hause zu Dir wird fehlerhaft geroutet.

KjuBie ~ # batctl tr 10:fe:ed:9c:28:68
traceroute to 10:fe:ed:9c:28:68 (2a:05:37:e6:bd:c8), 50 hops max, 20 byte packets
 1: 00:be:e1:ba:fe:60  32.073 ms  34.574 ms  32.134 ms
 2: 2a:05:37:e6:bd:c8  53.804 ms  51.928 ms  59.186 ms

„Wolkenschaf“ aber nicht

ich glaube, woanders gibt es schlimmere Probleme. Bei Dir gibt es eine Verbindung zum Mirker Bf/Hebebühne. Vom Bahnhof gibt es ja die 400 Mbit Richtfunkstrecke zum Rathaus, die durch Batman möglicherweise bevorzugt genommen wird. Außerdem hat @WUPTRaXX an den Knoten im Bahnhof undokumentiert hantiert und ich weiß nicht, wie gut die Verbindung zu Dir ausgerichtet wurde.

Dies sind Faktoren, die bei Dir zusätzlich eine Rolle spielen.

Derzeitige Probleme im Tal:

Serverausfall. Wird in ca. 2 Monden behoben
„Altes“ (von allen und überall genutztes) Batman-Routing-Verfahren, welches die Anzahl der Hops berücksichtigt und nicht die zur Verfügung stehende Bandbreite. Wird in ca. 5 Monden umgestellt.

Korrupt · 29. Mai 2019 um 20:50

Fürs Protokoll: seit heute sehe ich bewusst zum ersten Mal wieder einen direkten fastd-Uplink vom Wolkenschaf zu 00:be:e1:ba:fe:60 - nur bei dem, bei den beiden anderen nicht. Ich hatte in der Zwischenzeit meine alte Fritzbox fürs Homerouting gegen einen Edgerouter X ausgetauscht, kann mir aber nicht recht vorstellen, dass es damit was zu tun hat, insbesondere, weil ich immer noch kein natives IPv6 zu Hause hab (falls das je überhaupt eine Rolle spielt) und weiter, weils eben nur den einen und nicht alle drei betrifft. Scheint mir dennoch grundsätzlich eine deutlich bessere Situation wie alles über einen je nach Wetterlage mehr oder weniger guten Uplink mit weiteren Hops richtung Utopiastadt zu routen.
Theorie: wegen was auch immer nimmt die Remote-Kiste unter 00:be:e1:ba:fe:60 wieder mehr fastd-Connections entgegen?

adorfer · 30. Mai 2019 um 21:41

Zumindest schaut es für mich hinsichtlich dhcp-Leistung und Gateways konstant aus.
Und der Test auch per fastd-Link erfolt, scheint auch mindestens ein Server immer Connections anzunehmen.

Korrupt · 4. Juni 2019 um 17:42

Protokollzusatz: nach neuer IP-Zuweisung intern und einigen Neustarts haben die anderen Knoten nun auch wieder fastd-Connections. Nachdem mir der Utopiastadt-Uplink regelmäßig überlastet scheint (der lokalen performance zufolge, wenn ich dort eingeloggt bin) scheint mir das eine Gute Sache™. Korrigier mich wer, wenn ich hier Milchmädchenrechnungen mache, aber aktuell schiebt jeder der drei APs hier sein Gig am Tag über die Leitung und ich nehme an, besser hier als übers mesh und den AP gegenüber, an dem eh immer schon zwanzig Leute aufwärts hängen.

Korrupt · 1. Juli 2019 um 19:50

Jetzt ist alles tot. Hier flog ne Sicherung und anschließend ging nichts mehr online. Keine Routen nach draußen mehr, keine erreichbaren externen IPs. nachdem halb W’tal auch platt ist, vermute ich, es liegt nicht an mir, sondern dass neu angemeldete Knoten einfach nicht mehr eingebunden werden.

adorfer · 1. Juli 2019 um 20:52

hmm, also zumindest auf der Karte schaut es nicht völlig defekt aus.
Aber ich vermag natürlich nicht zu sagen, was für Traffic dort läuft.

Korrupt · 2. Juli 2019 um 17:42

Siehe meine Vermutung: was läuft, läuft durch, was neu dazukommt, kommt nicht rein. Von Utopiastadt weiss ich nun nicht, ob/was da wieder anlaufen sollte, aber die Schafwolke darunter kam eigentlich immer hoch, auch wenn mal die Sicherung flog.
Lokal komm ich auf die Router (nun, auf die, bei denen ich SSH aufgesetzt hab), und mit den einschlägigen batctl-Commands krieg ich nach draußen nullkommanull.

ifconfig zeigt soweit ich sehe alle notwendigen Schnittstellen an und auch keine Paketfehler, aber ein Client kriegt eine 169.254.189.73 zugewiesen bzw. nimmt die, weil er keine IP zugewiesen kriegt. Er pingt Adressen hier im internern Lan und die 10.3.0.1, und alles, was draußen ist, nicht.

ust-ff