Wechsle dann mal wieder auf MTU 1312 zurück…
Warum machst Du eigentlich Speed-Tests? Die MTU wird da wohl keine Wunder bewirken.
Ich dachte, es geht hier um die Stabilität des fastd-Tunnels? (Oder hab ich einen an der Mütze?)
btw: Der Durchsatz ist so oder so gerade etwas… grenzwertig.
Hi,
Speedtest weil ja performance einbüßen prognostiziert wurden…
Stabil scheint es zu sein - wenn die performance aber bei teilweise <= 2 im download ist bin ich allerdings geneigt „fast alles“ in Frage zu stellen.
Wer viel misst, misst Mist 
Werde die Kiste wohl auf „Null“ setzen und mal an einem Telekom-DSL hängen um auszuschließen das nicht die Hardware einen am Schlappen hat, am UM-Anschluss einen 841er Anschlüssen zur Gegenprobe.
Aktuell (Sonntag 15:45) ohne VPN
(Konfig mit MTU 1312)
Bei einem „kaputten“ VPN hat
nicht geholfen - erst ein reboot hat die VPN-Verbindung wieder hergestellt
Hi,
„back-2-normal“ ginge dann so?!?!?!
uci set fastd.mesh_vpn.mtu=1426
uci set fastd.mesh_vpn_backbone_peer_moehne0.enabled=1
uci set fastd.mesh_vpn_backbone_peer_moehne1.enabled=1
uci set fastd.mesh_vpn_backbone_peer_moehne2.enabled=1
uci set fastd.mesh_vpn_backbone_peer_moehne3.enabled=1
uci set fastd.mesh_vpn_backbone_peer_moehne4.enabled=0
uci commit fastd
/etc/init.d/fastd restart
Ja zurück sollte so funktionieren.
Kannst du mal wenn die VPN Verbindung nicht geht „logread“ auf dem Knoten absetzen und den Output teilen?
Was für einen Anschluss hast du genau? UM mit DSLite?
Viele Grüße,
Lars
schaut ganz danach aus als hätte sich vor eingen Tagen etwas geändert (bei einem Netzbetreiber oder neuerdings Nodes bei einem problematischen Netzbetreiber), die Fragmentierung der Pakete auf dem Supernode nehmen deutlich zu. Da werden wir wohl in Aachen auch ein Update auf eine geringere MTU verteilen müssen.
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)
http://map.freifunk-moehne.de/meshviewer/#!n:c46e1ffef72a
- IPV6 + IPV4-DSL-Lite
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?
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.
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“
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
Kann man das Script nachträglich auf meinen Möhne-Router „schieben“?
Falls ja - wie 
Aber das hat doch sicherlich nichts mit der mtu zu tun oder? Haben die Router denn ansonsten noch normales Netz?
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.
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?
- Router verliert batman-connectivity zum meshvpn-GW, merkt das aber nicht(?)
- Router bemerkt verlust batman-connectivity zum Meshvpn-GW, fastd ist jedoch gestorben
- Router bemerkt verlust batman-connectivity zum Meshvpn-GW, fastd gelingt jedoch kein reconnect bei anderem supernode
- 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.
Diese Skripte sollten erstmal explizit eingeschaltet werden müssen in Standard-Firmware, wenn sie das Geräte restarten
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.