MTU für fastd an Unitymedia anpassen bzw. kontrollieren

Technik
41

Hab die Geduld verloren und den Router mit „firstboot“ resettet und gegen einen 3600er mit aktueller „untouched“ Möhne-Firmware getauscht. Den 1043 werde ich an einem T-DSL hängen… (berichte später)

EDIT:
Der 3600er scheint an dem UM-Anschluss* seit 18:00h (27/4) nun stabil UND relativ performant zu laufen (6-8 Mbit down 1-2 Mbit up)

c46e1ffef72a.png881×455 16.1 KB

http://map.freifunk-moehne.de/meshviewer/#!n:c46e1ffef72a

  • IPV6 + IPV4-DSL-Lite
42

Kann ich irgendwie auf dem Knoten gucken, ob meiner zu den problematischen dazu gehört?
Also: Gibt es die Statistik, die Du da geplottet hast, auch in Alfred oder anderswo lokal?

43

Nein, das ist die Statistik des gesamten Traffics auf dem Supernode, da werden auch keine Details gespeichert.

Ich habe gestern auch mal kurz versucht mit tcpdump einen netzbetreiber zu identifizieren, habe aber nur ein paar fragmentierte dns Pakete von extern angezeigt bekommen.

44

Wir haben in Troisdorf das selbe Problem…

Router an Unitymedia Anschlüssen Sterben bei uns nach 4-48h. Einzige hilfe: Reboot.

Weil wir hier ein paar haben, und die Zeit das genau zu untersuchen nicht da ist haben wir ein ganz Primitives gluon-package gebaut weilches die Nodes automatisch rebootet.

Wie gesagt: Sehr Primitiv! Das bootet neu sobald kein Supernode mehr in sicht ist…

1 „Gefällt mir“
45

Hatte heute (zusätzlich) ein seltsames Problem…

  • VPN lief noch !!
  • WLAN 2.4 ausgefallen
  • WLAN 5 aktiv

„wifi“ per ssh hat den WLAN-Ausfall gefixed

c46e1ffef72a.png881×455 16.1 KB

46

Kann man das Script nachträglich auf meinen Möhne-Router „schieben“?
Falls ja - wie :wink:

47

Aber das hat doch sicherlich nichts mit der mtu zu tun oder? Haben die Router denn ansonsten noch normales Netz?

48

Könnte man nicht übergangsweise einfach ein Testskript in cron hauen?

Mein Pi ist auch zu blöd eine WLAN-Verbindung zu halten, daher hab ich sowas hier in Cron:

#!/bin/bash

TESTIP=192.168.178.1

ping -I wlan0 -c2 ${TESTIP} > /dev/null

if [ $? != 0 ]
then
    logger -t WLAN "Keine Verbindung zu ${TESTIP}, WLAN wird neu gestartet"
    ifdown --force wlan0
    ifup wlan0
fi

Ja ich weiß, ist nicht updatesicher. Aber besser als nichts. Und wer weiß, vllt. könnte man daraus ein Paket basteln. Statt WLAN neu zu starten, müsste man dann halt einfach einen reboot machen.

49

Es gibt für mich da folgende Szenarien
a) Router an IPv6 mit DSlite
b) Router an IPv6 mit DualStack
c) Router an lokalem Providerrouter mit public IPv4
d) Router an lokalem Providerrouter mit CGN aber abgefilterter IPv6

Und was kann dann passieren?

  1. Router verliert batman-connectivity zum meshvpn-GW, merkt das aber nicht(?)
  2. Router bemerkt verlust batman-connectivity zum Meshvpn-GW, fastd ist jedoch gestorben
  3. Router bemerkt verlust batman-connectivity zum Meshvpn-GW, fastd gelingt jedoch kein reconnect bei anderem supernode
  4. batman und fastl laufen „eigentlich“, aber irgendwie sind wahlweise der Supernode oder der Client halb weggedämmert und bemerkten nicht, dass sie nicht nutzbar sind.

Gegen welche Szenarien hilft das Script? Gegen alle? Oder gibt es Szenarien wo einer der Pings durchgeht, aber keine Pakete von Nutztraffic-Größe? In dem Fall evt die Pingpaketsize erhähen.

Nur: Ich würde evtl zwe Prüfungs-Scripts kaskadieren und den Pingcount auf mindestens 3 setzen, einfach um nicht zu schnell die Reissleine zu ziehen.

Und bei „absichtlichen lokalwolken“ gibt es dann dauer-Bootschleifen.

P.s. ich würde eher mit
batctl gwl mir die Gatewayliste holen und dann mi t
batctl p schauen ob ich mindestens einen Gateway erreiche.

50

Diese Skripte sollten erstmal explizit eingeschaltet werden müssen in Standard-Firmware, wenn sie das Geräte restarten

51

Naja, das Skript stammt von meinem Pi, der das lokale WLAN testet. Dass für eine Internetverbindung ein paar mehr Pings genutzt werden sollten, ist klar.