Ff_offline und abgehängte Knoten

[m.bitterlich (Matthias Bitterlich)]

Moin,

wir haben bei einigen Knoten, die etwas “ungünstige” Verbindungen zueinander haben, jetzt häufig das Problem, dass sie sich vom Netz abhängen bzw. nicht mehr erreichbar sind. Auf dem letzten erreichbaren Knoten sind sie noch zu sehen … aber von dort gehts nicht weiter/zurück.
Häufig hilft ein Reboot - manchmal nicht - manchmal kommen die Knoten wieder allein zurück.

Wie funktioniert das ff-offline-Feature, kann es das Mesh zwischen den Knoten beeinflussen?

[wusel (Kai 'wusel' Siering)]

Nope, also, eigentlich nicht. Das Package schaltet mit Absicht nur die AP-Kennung von (normaler SSID) auf FF_OFFLINE_xxxxxxxxxxxx. (Der AP-Modus bleibt auch aktiviert, wer sich mit statischer Konfiguration verbindet, kann sich umgucken/debuggen.)

Das Feature soll eigentlich nur davor schützen, daß großflächig Freifunk-Verfügbarkeit signalisiert wird, beim Versuch, es zu nutzen, dann aber nix geht. Also im Grunde das zu verhindern, was den verregneten Start des Berliner Public-WLAN zum Medienfiasko werden lies: wenn nicht tut, tue nicht so, als ob.

Festgemacht wird das an der Verbindungsqualität zum Gateway — derzeit leider nicht an dessen korrekter Funktion. Aber es ist ein Anfang.

Da das Mesh nicht betroffen sein sollte, was heißt »Auf dem letzten erreichbaren Knoten sind sie noch zu sehen … aber von dort gehts nicht weiter/zurück« genau?

[m.bitterlich (Matthias Bitterlich)]

Hi,

[…]
Festgemacht wird das an der Verbindungsqualität zum Gateway — derzeit leider nicht an dessen korrekter Funktion. Aber es ist ein Anfang.

OK. Wie sieht die Qualitätsdefinition aus und kann sie auch unsererseits verändert werden?
Bei schlechteren Knoten-zu-Knoten-Verbindungen ist es blöd, wenn die SSID “flackert”.

[…]
Da das Mesh nicht betroffen sein sollte, was heißt »Auf dem letzten erreichbaren Knoten sind sie noch zu sehen … aber von dort gehts nicht weiter/zurück« genau?

Genau. der letzte erreichbare Knoten sieht den/die anderen Knoten auf der “Web/Statistikseite”, RX zählt hoch, TX verändert sich nicht, rx/tx-Bitrate liegt bei 1MBit/s und batctl o zeigt den/die “abgehängten” Knoten nicht an.
Zurzeit habe ich leider kein Beispiel … sende ich nach.

Gruß Matthias

[m.bitterlich (Matthias Bitterlich)]

Jetzt hab ich zwei abgehängte Knoten …

Station 62:e6:28:c7:98:24 (on mesh0)
inactive time: 40 ms
rx bytes: 372612
rx packets: 5274
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -80 [-83, -84] dBm
signal avg: -79 [-82, -83] dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

root@17194-Tressow-1ac8:~# batctl o | grep -i 62:e6:28:c7:98:24
root@17194-Tressow-1ac8:~#

Station 32:b8:c3:b5:70:02 (on mesh0)
inactive time: 80 ms
rx bytes: 545804
rx packets: 7740
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -71 [-74, -74] dBm
signal avg: -71 [-73, -74] dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

root@17194-Tressow-1ac8:~# batctl o | grep -i 32:b8:c3:b5:70:02
root@17194-Tressow-1ac8:~#

Die Geräte sollten sich gegenseitig sehen/meshen, da “17194-Tressow-1ac8” zurzeit für diese Knoten der Uplink ist.

[m.bitterlich (Matthias Bitterlich)]

Da haben sich zwei doch schon während des Schreibens wieder gefunden …
Der andere ist noch weg:

Station 62:e6:28:c7:98:24 (on mesh0)
inactive time: 20 ms
rx bytes: 706479
rx packets: 10018
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -66 [-68, -71] dBm
signal avg: -66 [-68, -71] dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

root@17194-Tressow-7002:~# batctl o | grep -i 62:e6:28:c7:98:24
root@17194-Tressow-7002:~#