[Berlin-wireless] OLSRD Abstürze auf der NSM2

[Neels Hofmeyr]

On Mon, Feb 15, 2016 at 11:10:15PM +0100, Malte wrote:
> >Deshalb haben wir (stsp und ich) in unserer crontab immer einen Eintrag,
> >der schaut ob die olsrds noch laufen
> 
> ...und deshalb wäre es toll, wenn ihr genau das NICHT machen würdet, sondern

sicher würde ich gerne jedem Tag N weitere Stunden einfügen bevor schon
wieder Schlafenszeit ist... ;) debug image hatten wir auch mal und m.W.
core gepostet, schon länger her, kann mich nimmer erinnern... :/

Ich habe konkret gar keine olsrd crashes beobachtet. Unser crontab entry
ist das sicherheitsnetz anstelle des nicht greifenden watchdogs damit
falls mal was passiert die teile wieder von selbst hochkommen.  Stimmt
natürlich dass wir so die crashes auch nicht mehr wirklich bemerken falls
doch welche passieren.

dass wir selber mal debuggen steht auf jeden fall auf der todo liste, wenn
mal zeit übrig ist.

(Ein Problem das wir konkret hatten war dass auf der NanoStation M2 der
WLAN dual mode AP + OLSR crashy ist. Das konnten wir nur beheben indem
wir M2 teile nur noch entweder als Mesh oder als AP betreiben...)


> >Das ist irgendein routing bug den wir noch eines tages mal lösen wollen.
> >Ein olsrd restart behebt dann meist das "Destination Net Unreachable".
> 
> Hm. OLSRd und Firewall und OpenVPN hängen etwas komisch zusammen, z.B.
> frickeln die OLSRd-Startskripte an der Firewall rum; startet man die
> Firewall nach OLSRd neu, geht nichts mehr (bis zu einem OLSRd-Neustart).
> Möglich, dass das da irgendwie sowas in die Richtung ist.

Ja genau ... das rauszufinden wäre meine prio, weil wenn das gelöst ist
können wir alle unsere Installationen IPv6-enablen. Können wir ja jetzt
schon aber eben immer nur bis zum jeweils nächsten umkippen. Dann läuft
nur noch v6, v4 geht kaputt, und dann sagen einem die heimbewohner: ja,
facebook geht, aber whatsapp nicht :)

hmm vielleicht sind die umkipper ja doch olsrd crashes? hehe
(aber auch nach power cycle ist immer erstmal v4 im oasch)

~Neels

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: Digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160221/3b87e53e/attachment.sig>