Hallo Reka,
einfach in die
/etc/sysctl.conf
eintragen.
Es kann aber sein, dass die Datei beim nächsten Firmware-Update wieder überschrieben wird. Das kann Dir aber sicherlich @pberndro sagen
Gruß Jörg
Hi Adorfer,
hast du vielleicht eine Idee woran es liegen könnte, das diene betas keinen Verbindung aufbauen können?
@pberndro: könntest du vielleicht eine aktuelle beta mit umac und den aktuellen bugfixes bauen?
Gruß
Thomas
-vv bitte.
Wer verbindet sich nicht mit was?
Du meinst ein paar Testnodes hier lokal oder bei Dir welche? kein fastd-vpn oder kein wifimesh?
Ich hoffe doch, dass der Workarround mit dem nächsten FW-Update obsolete wird 
Aber ich hab eh ein paar Kleinigkeiten, die bei nem Update überbügelt werden.
-vv sollst du haben 
Ich rede natürlich von deiner Testsuite und von dem Phänomen das er versucht sich zu verbinden und in einen loop Gerät.
Aber gerade habe ich den Router noch einmal gestartet und siehe da
Fri Nov 21 09:15:18 2014 daemon.notice fastd[1099]: connection with <mesh_vpn_backbone_peer_ruhrgebiet0> established.
Fri Nov 21 09:15:18 2014 daemon.info fastd[1099]: new session with <mesh_vpn_backbone_peer_ruhrgebiet0> established using method `salsa2012+umac'.
Entsprechend Funktioniert das gerade offenbar 
Ik freu mir.
Danke für deine Mühen.
Gruß
Thomas
Ich suche derzeit noch, wie ich den loglevel von dnsmasq „generell“ herunterdrehen kann.
Die Images auf http://www.nadeshda.org/ff/gluon-ruhr/sysupgrade/ habe ich nochmal refreshed.
Ernsthaft empfehlen kann ich es aber "zum drüberinstallieren auf einen schon laufenden (registrierten) 2014.3er (0.4/0.5er).
Bei der „Frischinstallation“ hakt irgendwas. Vermutlich wird der vpn-Key nicht korrekt ausgewürfelt.
Hi,
also muss schon sagen die Version von gestern Abend lief auf einer 841er V8 solange gut bis sich ein client connected hat. Dann ist diese binnen einer Minute gecrashed.
Außerdem ist diese nicht im Alfred aufgetaucht obwohl sie verbunden war. (War ja über V6 auf dem Hobel drauf)
Dann habe ich mal die neue Version von heute auf einer Ubiquiti Picostation probiert.
Nach dem Sysupdate und dem ersten reboot hat es ebenfalls nicht lange gehalten.
Aber dann.
Alles super 
Es geht sogar Youtube und Amazon Instand Video parallel
Auch wenn speedtest.net bescheinigt das nur ca 2 Mbit/s zur Verfügung stehen…
Ich werde gleich mal diese 841er mit einem neuen image versorgen mal sehen ob das was hilft.
Die Picostation läuft nun seit 27 min. das habe ich hier schon lange nicht mehr gesehen … ik freu mir.
Warum ließt der dnsmasqd ständig die Datei aus (/var/gluon/wan-dnsmasq/resolv.conf). Einmal sollte doch reichen. Zumal ich nicht sicher bin ob das so eine gute Idee ist den lokalen DNS Server (per DHCP zugewiesenen) zu benutzen. Ich sehe da ein potenzielles Angriffsszenario.
Gruß
Thomas
Nachdem ich in der letzten Zeit immer recht unglücklich mit der Performance war, habe ich aktuell 6 x youtube am laufen und eine speedtest.net liefert immer noch 3mbit/s. So kann es bleiben…
2 „Gefällt mir“
Eigene Firmware für das Münsterland, analog zur Ruhrgebiet Fw ... Basierend auf 2014.3.1 mit einem 3600er.
Paulo
1 „Gefällt mir“
Nur so… hier gerade wieder ups und downs der uplinks. 
Bei mir in Essen läuft es nun sehr stabil! Kein reboot seit dem ‚fix‘.
Die Einstellungen sind persistent und sollten auch ein Update überleben.
Wobei die Einstellung bezüglich der Speicher-Vergrößerung nicht mehr notwendig ist.
Gruß,
Philip
Dieses Problem ist gelöst.
Es handelte sich um ein Problem bei der Auswertung der MAC Adressen im Backend von Alfred.
Die MAC Adressen der beiden Router waren nur um ein Bit unterschiedlich und somit wurden diese auf der Map nicht richtig angezeigt.
Im neuen Backend der Map ist dieses Problem behoben.
Gruß,
Philip
Ist das neue Backend der Map schon online? bzw. wann soll es online gehen?
Die Ups und Downs Ampel rast hier wieder rum…
Da gehen übrigens auch Router in die Knie, die nicht vermascht sind und keinen erhöhten Traffic haben.
Du musst unterscheiden zwischen
- „nicht per IP aus dem Internet erreichbar“
- „Router bootet durch, uptime wieder auf 0h“
Dieser Thread behandelt afaik Letzteres, nicht UDP-Downtimes wegen temporär versagender Routen.
3 „Gefällt mir“
… Sorry, ich passe.
Nur weil ein Router aus dem Internet (von einem Ping-Monitor) nicht erreichbar ist bedeutet das nicht zwangsläufig, dass er abgestürzt ist, heruntergefahren wurde oder ein Watchdog die Reißleine gezogen hat.
Es heisst nur „Derzeit antwortet niemand auf Requests an diese Adresse“.
Dabei kann der Router durchaus laufen, nur eben ohne funktionsfähige Außenanbindung sein.
Das kann ein überlasteter Supernode sein. Oder defekt konfigurierte Routen beim Provider.
Oder Batman-Routing-Tabellen, die in die falsche Richtung zeigen, weil das Netz schneller fluktuiert als sich die Routing-Tabellen updaten. Und derweil läuft der jeweilige Plasterouter wacker durch… stellt nur ebenfalls fest „ich kann nicht wie ich gern würde“.
Aka „SSID sichtbar, DHCP aber nicht verfügbar, weil kein Weg zu den Supernodes“-> „eingeschränkte Internetverbindung“ (wie Windows das dann nennt).
Worum es hier geht (siehe erstes Posting von @apo): Router die selbstständig alle x Stunden (x < 24) neu starten, ohne dass ein Grund ersichtlich ist. Teilweise war es, dass einige Routerchen alle 30 Minuten einen Boot hingelegt haben. Und bei etwa 4-6 Minuten, die vergehen, um wieder vollständig im Netz und von außen erreichbar zu sein, ein kaum haltbarer Zustand.
P.S: „Fehlende Außenanbindung“ und „unflexibler Batman“ sind nicht minder problematisch, wenn sie zur AnwenderIn durchschlagne. Nur hat das nichts mit diesem Thread zu tun.
2 „Gefällt mir“