Hallo!
Nach den ersten Schwierigkeiten mit der L2TP Firmware hat mein eigener FF Knoten mehrere Monate scheinbar problemlos gelaufen. Scheinbar, denn mein Knoten ist eher just-for-fun und hat so gut wie nie Last. Dies hat mich dazu bewegt, das von mir betreute Campingplatz FF Netz eines Kumpels wieder aus der Münsterländer Exildomäne nach Nordwest zurückzuholen. Dazu war viel Überzeugungsarbeit beim Kumpel notwendig, da das FF Netz nach dem Umzug in deren L2TP Ramschdomäne eine Saison einfach super gelaufen hat. Die Camper waren zufrieden. Keine Beschwerden mehr seitens der Camper wegen der FastD Auslastungssituation seinerzeit in der Richtung, ob das Internet kaputt wäre...
Nun ja. Nach jetzt knapp 4 Wochen fällt mein Fazit mit der L2TP Firmware unter Lastbedingungen leider erschreckend negativ aus. Damit hatte ich durch meine eigenen positiven Erfahrungen mit der FFNW L2TP Firmware überhaupt nicht gerechnet. Aber hier bei mir verfängt sich auch höchstes mal ein Smartphone ins FF Netz oder ich mache mal bewusst einen Speedtest.
Es ist halt so, dass der als L2TP Offloader eingesetzte 841nd v10 an Lasttagen mehrmals neu startet. Der Kandidat mit den zweitmeisten reboots ist die Außenantenne, ein 741nd v4. Sie befeuert den Campingplatz, stellt aber wie die anderen Access Points in diesem Netz die Verbindung zum Freifunk über den Offloader her.
Schaut man sich das Netz an, so hat schon jedes der Geräte im Netz einen Reboot hingelegt. Die Reboothäufigkeit verringert sich schlagartig, je weniger das Gerät benutzt wird.
Leider ist es dem Kumpel auch schon aufgefallen, dass das Netz nicht so wirklich stabil nach der Umstellung läuft. Es gab also wohl schon Nutzerbeschwerden.
Was kann man da machen? Interessant ist ja, dass die Geräte genauso betroffen sind, die nicht selber eine Verbindung ins FFNW Netz aufbauen und nicht nur der Offloader.
Schaue ich mir mal die Map an und klicke durch viele Geräte, so sind ja auch auffällig viele Geräte mit geringer Laufzeit, also vermutlich reboots dabei. Das Problem scheint also auch wohl bei den 'normalen' FastD Nutzern zu bestehen.
In der L2TP Münsterland Ramschdomäne haben die betroffenen Geräte zwischen den Firmware Updates monatelang problemlos ohne Reboots gelaufen.
Ich habe mal heute beim Offloader bis zum Absturz mitgeloggt, TOP laufen lassen. Vielleicht kann jemand mit den Daten etwas anfangen? Ansonsten schreibt mir, was ich loggen soll.
Knoten Name: ffnw-Dittrich-Offloader
https://www.file-upload.net/download-13200124/841v10.7z.html
Grüße
Michael
Hallo Leute,
anstatt wieder alle Leute mit Emails zu nerven, habe ich mir mal die Arbeit gemacht, ein paar alten nodes.json-Dateien (konkret: eine von kurz vor Einführung der hoods im Sommer 2016 und eine von vorm update auf die 20170822) nach routern zu filtern, deren node_id aktuell nicht mehr mehr online sind. Das ganze ist unter
https://map.ffnw.de/friedhof
zu sehen. Wenn alles so läuft, wie ich mir das denke, erscheinen dort in Zukunft alle Router, die mindestens seit 23h und 55min offline sind. Also kurz bevor sie aus der normalen Karte verschwinden. Sobald ein Router aus Friedhof wieder online ist, sollte dort verschwinden, aber das ist noch ungetestet. Der Abgleich automatische erfolgt minütlich.
Schaut euch dort mal ein wenig um, ob ihr vielleicht Router entdeckt, deren Wiederbelebung ihr euch vorstellen könntet. nicht wundern: viele Router werden da als online angezeigt, aber das liegt an meiner Faulheit. In wirklich sind die alle offline, vgl. zB map.ffnw.de
falls noch irgendjemand alte nodes.json-Dateien hat, immer her damit, ich verdinge mich dann als Totengräber. muhahaha
LG Lorenz
moin,
seit dem letztem update meshen einige router nicht mehr über das WLAN.
Betroffene Router: loy-wope4, loy-wope6, loy-wope13
Über SSH komme ich drauf, kann ich hier irgendwie das meshen über WLAN
wieder aktivieren?
Diese Router haben auch keine User mehr, wahrscheinlich ist das ganze
WLAN deaktiviert.
gruß, wope
Grüße Herr / Frau.
Ich bin Berater Bernard Held, und ich bringe Ihnen gute Nachrichten
von Nucleus Business Darlehen Rendering-Service aus dem Vereinigten
Königreich.
Nucleus Commercial Finance hat einen Meilenstein von 750 Millionen
Pfund mit dem bisher größten Darlehen angekündigt.
Nucleus führt innerhalb von einer Woche eine sehr schnelle
Darlehensrücknahme für Geschäft, Projekt, Bau, Marketing, Autokauf und
viel mehr bei 1,3% durch.
Wenn Sie daran interessiert sind, Erkenntnisse für Ihren Wunschzweck
zu erhalten, empfehlen wir Ihnen, Ihre Bewerbungsdetails unten für
weitere Details anzugeben.
Vollständiger Name:..........
Land:......Schweiz....
Darlehensbetrag:..........
Darlehensdauer:..........
Der Grund für den Kredit:..........
Telefon:..........
Wir warten so bald wie möglich auf die Bestätigung Ihrer
Darlehensdetails, damit wir Ihnen weitere Informationen senden können.
Bernard Held
Kreditagent / Berater.
Nucleus Business Loans
3rd Floor, Coin House, 2 Gee's Ct,
London W1U 1JA, United Kingdom
Schönen Tag.
Wir hoffen, Sie gut zu treffen.
Benötigen Sie einen dringenden Kredit für ein Geschäft oder ein Projekt?
Wir bieten Kredite zu 1,5% und wir können Ihre Transaktion innerhalb
von 3 bis 5 Arbeitstagen abschließen.
Wenn Sie ernsthaft an einem Kredit interessiert sind, empfehlen wir
Ihnen, unten die Einzelheiten zur Bearbeitung Ihrer Transaktion
anzugeben.
Vollständiger Name:..............
Darlehensbetrag: ..............
Darlehensdauer: ..............
Darlehen Zweck:..............
Telefon:..............
Wir erwarten Ihre Darlehensdaten wie oben beschrieben für die Abwicklung
Ihrer Transaktion.
Freundliche Grüße.
Wilson Rog.
Buchhalter / Berater
Moin,
ich optimiere meinen Lagerbestand und muss mich von einigen Dingen trennen.
https://mikrotik.com/product/RB951Ui-2HnD
Falls jemand Interesse hat, so möge er sich melden.
Preis ist VB
Gruß Andreas
Outlook for Android herunterladen
So Leute. Endlich.
Habe mich gerade anhand weiter unten beschriebener Methode durch den täglichen Hoodkurzschluss delmenhorst <-> default02 gegraben. Mein Dank geht an Robin -- er weiß, wieso :) Die Ursache ist (aus Ursachenforschungsgründen immer noch, aber keine Sorge, das Symptom wird weiterhin per iptables auf dem default02.sn.ffn.de weggemacht) ein Kabelmeshrouter mit festgefahrenem hoodselector.
Konnte mich gerade noch zurückhalten, den Router zu fixen. bitte den Router erstmal in seinem Fehlerzustand belassen. Nicht rebooten, keine Kabel abziehen. wir wollen die Ursache für das Problem herausfinden. Habe mir erlaubt, Tareks sshkey auf dem Router zu hinterlegen, damit er sich das Problem mal live anschauen kann.
root@Wuesting-Raiffeisenstrae-I1:~# hoodselector
The hoodselector is still running.
root@Wuesting-Raiffeisenstrae-I1:~# ls -l /var/run/hoodselector.pid
-rw-r--r-- 1 root root 0 Sep 27 19:28 /var/run/hoodselector.pid
root@Wuesting-Raiffeisenstrae-I1:~# cat /tmp/hoodselector_error
Command failed: Not found
Command failed: Not found
Command failed: Not found
ifconfig: SIOCGIFFLAGS: No such device
ifconfig: SIOCGIFFLAGS: No such device
Command failed: Not found
Failed to parse json data: unexpected end of data
/usr/bin/lua: /usr/sbin/hoodselector:110: attempt to index local 'a' (a nil value)
stack traceback:
/usr/sbin/hoodselector:110: in function 'h'
/usr/sbin/hoodselector:181: in function 'r'
/usr/sbin/hoodselector:481: in main chunk
[C]: ?
root@Wuesting-Raiffeisenstrae-I1:~#
root@Wuesting-Raiffeisenstrae-I1:~# batctl gwl
[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/8e:83:b2:79:67:3b (bat0/84:16:f9:c8:ac:f2 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
52:15:c8:12:c6:a8 (251) 52:15:c8:12:c6:a8 [ mesh-vpn]: 59.5/32.3 MBit
* ce:d3:06:0a:17:bf (179) 1a:e5:c9:ac:bb:58 [br-mesh_lan]: 1000.0/1000.0 MBit
das andere Ende des Kabels steckt im br-wan eines entsprechend konfigurierten Routers (Wuesting-Raiffeisenstraße-O2)
LG Lorenz
-------- Weitergeleitete Nachricht --------
Am 03.10.2018 um 12:06 schrieb lrnzo:
> moin,
>
> ich will dir die Idee kurz umreißen:
>
> ssh -A FF_OS_Martinistr_Lager_10feedc260a2
>
> den Welcome-screen erspare ich uns mal .... mit "batctl gwl" kannst du das bzw die Supernodes/Gateways eines routers sehen. Normalerweise ist dort ein Supernode aufgeführt. Eine gesunde Ausgabe sieht zb aus:
>
> root@FF-OS-Martinistr-Lager:~# batctl gwl
> [B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/3e:ff:38:f1:d6:2b (bat0/10:fe:ed:c2:60:a2 BATMAN_IV)]
> Router ( TQ) Next Hop [outgoingIf] Bandwidth
> * 82:f2:bd:50:be:33 (235) 0a:1d:84:d2:73:11 [ mesh0]: 1000.0/1000.0 MBit
>
> nun kennt man also die MAC des BATMAN-Interfaces des Supernodes. Dieses kann man nun tracen:
>
> root@FF-OS-Martinistr-Lager:~# batctl tr 82:f2:bd:50:be:33
> traceroute to 82:f2:bd:50:be:33 (82:f2:bd:50:be:33), 50 hops max, 20 byte packets
> 1: 0a:1d:84:d2:73:13 7.091 ms 1.119 ms 2.687 ms
> 2: 82:f2:bd:50:be:33 30.561 ms 34.256 ms 33.654 ms
>
> man sieht also die MACs der BATMAN-Interfaces der Mesh-hops bis zum Supernode, in diesem Fall einer. Nun habe ich mir mal die link-local Adressen meiner mesh-nachbarn angeschaut. Eine davon hat eine ziemliche Ähnlichkeit mit der MAC des nächste BATMAN-Hops in Richtung Supernode. Habe die Zeile mit nem Pfeil markiert.
>
> root@FF-OS-Martinistr-Lager:~# ping ff02::1%mesh0
> PING ff02::1%mesh0 (ff02::1%mesh0): 56 data bytes
> 64 bytes from fe80::3cff:38ff:fef1:d629: seq=0 ttl=64 time=0.467 ms
> 64 bytes from fe80::885:8ff:fe28:be31: seq=0 ttl=64 time=10.509 ms (DUP!)
> 64 bytes from fe80::cca6:51ff:fe65:a099: seq=0 ttl=64 time=13.085 ms (DUP!)
> 64 bytes from fe80::81d:84ff:fed2:7311: seq=0 ttl=64 time=13.697 ms (DUP!) <-
> 64 bytes from fe80::a889:48ff:fed0:d211: seq=0 ttl=64 time=14.859 ms (DUP!)
> 64 bytes from fe80::d05c:c1ff:fefe:40b9: seq=0 ttl=64 time=15.959 ms (DUP!)
> ^C
> --- ff02::1%mesh0 ping statistics ---
> 2 packets transmitted, 2 packets received, 10 duplicates, 0% packet loss
> round-trip min/avg/max = 0.467/7.148/15.959 ms
>
> Aus 0a:1d:84:d2:73:13 wurde fe80::81d:84ff:fed2:7311. Die Bildungsvorschrift scheint zu sein:
>
> 1. und 6. Oktett (0a bzw 13) um 2 reduzieren (gibt 08, die führende Null verschwindet dann in der ::-Abkürzung, bzw 11), zwischen 3. und 4. Oktett ein "ff:fe" einfügen (wird meistens so gemacht, wenn man aus einer MAC eine v6 ableiten will, vergleiche mal die Primary-MACs in der map in den dort gelisteten v6-Adressen) und dann noch zwei benachbarte Oktett zu einem "hextett" (heißt das so?) zusammenfassen (zB 84:ff -> 84ff). und sieht da, man landet über diese linklocal-Adresse auf dem nächsten Hop Richtung Supernode.
>
> root@FF-OS-Martinistr-Lager:~# ssh root@fe80::81d:84ff:fed2:7311%mesh0
>
> root@FF-OS-Martinistr-84:~# batctl gwl
> [B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/0a:1d:84:d2:73:13 (bat0/10:fe:ed:f4:07:2a BATMAN_IV)]
> Router ( TQ) Next Hop [outgoingIf] Bandwidth
> * 82:f2:bd:50:be:33 (254) 2e:65:38:c4:88:e2 [ mesh-vpn]: 1000.0/1000.0 MBit
>
> in der Spalte outgoingIf steht nun auch mesh-vpn
>
> Alles klar? Also Idee ist, mit "batctl gwl" und "batctl tr" die Fährte aufnehmen und sich dann von node zu node durchhangeln, bis man das ist, wo der falsche vpn-tunnel aufgebaut ist.
>
> Sobald du startklar bist, würde ich auf dem default-supernode die Anschluss-ip entblocken (damit es eine Spur zum verfolgen gibt) und mit etwas Glück kommen wir mit deinem key ist zum fraglichen Router. zumindest können wir ihn auf diese Weise herausfinden.
>
> LG Lorenz
