- läuft das Gerät denn derzeit?
- kannst du es auf 192.168.1.1 pingen? Hast du dir mal eine manuelle IP gegeben, der DHCP-Server lahmt manchmal
- Was passiert, wenn du ihn starten lässt und nochmal durch Drücken des Resetknopfes für 10-12 Sekunden in den Konfigurationsmodus bringst?
Das hatte ich auch. Das liegt daran das es kein Luci mehr gibt in den neuen Firmwares aber der Browser noch den Rewrite im cache hat. Versuch Mal privaten Modus und oder Cache löschen.
-
Ja, läuft. Hab es via SSH in Normalbetreib gebootet.
-
Es lies sich während des Konfigurationsmodus auf 192.168.1.1 anpingen und der DHCP Server hat auch funktioniert.
-
Jup, Aus- und Einschalten hat natürlich funktioniert
Heißt das dass der Webserver noch was laden musste, was beim Updaten nicht geladen wurde?
Also hier auf einem 1043v2 und auf 2 picostations sysupgrade gemacht. Lief problemlos durch. Habe bisher auch keine Loadspitzen feststellen können. Neuflash habe ich noch nicht getestet.
Jo, wird wohl der Browsercache gewesen sein…
Bin wohl nicht so ganz auf der Höhe heute 
Kannst du es nochmal auf die alte Version zurücksetzen und den Test wiederholen?
Hab noch nicht im Detail verstanden, wo es klemmt…
Genau dort. Ganz nach Anleitug die ich ins Wiki geschrieben hab 
https://wiki.freifunk-muensterland.de/x/D4DBAg
Gibt es eine andere/bessere Möglichkeit?
Man könnte es alternativ über UCI probieren.
Ich würde sagen, wir machen mal ein Ticket bei Gluon auf, dass sie die Netzwerkkonfiguration persistent lassen…
Dass das doch nicht persistent ist, müssen wir dann wohl an den diversen Standorten berücksichtigen, wo wir auf VLANs gesetzt haben.
Geklemmt hats bei mir im Kopf. Wie @corny456 richtig geahnt hat, der Cache meines Browsers war schuld 
1 „Gefällt mir“
Okay, dann ist das abgehakt.
1 „Gefällt mir“
Mein FF-Router mit LEDE war jetzt drei Tage offline. Er hatte sogar das DHCP-Release zur FritzBox verlorgen. Ohne ersichtlichen Grund. Der Link bestand laut Switch und LED am 841er. Nach einem Neustart lief wieder alles. Krasser Fehler, den ich so noch nicht erlebt habe in den Jahren zuvor.
Das Offline-SSID-Skript funktioniert aber soweit.
Ich hatte wahrscheinlich an einem 1043 das selbe Problem,Das der Knoten den Tunnel nicht mehr zum GW aufgebaut hatte obwohl ich an diesem Knoten mit der Privaten ssid weiterhin auf die Fritz.Box und auch ins Internet gelangte erst der neustart nach ein paar Tagen schafte Abhilfe.Das meshen zwischen den Knoten lief weiter.Aufgetreten ist es ca. zu der Zeit als die Karte auf ein anderes Blech umgezogen ist(vielleicht Zufall).
1 „Gefällt mir“
Ich sehe hier gerade ein Problem mit der Meshverbindung, das recht seltsam aussieht. Diese beiden Router meshen nicht mehr richtig:
https://karte.freifunk-muensterland.de/map36/#!v:m;n:687251165e59
https://karte.freifunk-muensterland.de/map36/#!v:m;n:ec086b3516f2
Über das bat0-Interface komme ich aber auf den ersten drauf. Man beachte, dass die Zeit für den letzten Kontakt negativ ist.
root@stratmann-baumers-NM2loco:~# iwinfo mesh0 assoclist
[...]
AE:35:9F:32:42:ED -85 dBm / -95 dBm (SNR 10) -46230 ms ago
RX: unknown 562 Pkts.
TX: 1.0 MBit/s 606 Pkts.
Auf der Gegenseite sieht alles in Ordnung aus:
root@ffwaf-eloh-alleestr-1:~# iwinfo mesh0 a
B6:3D:B0:75:31:49 -85 dBm / -95 dBm (SNR 10) 20 ms ago
RX: 6.5 MBit/s, MCS 0, 20MHz 7002 Pkts.
TX: 6.5 MBit/s, MCS 0, 20MHz 1119 Pkts.
[...]
Bisher ist das Problem auf beiden Seiten “rebootfest” 
2 „Gefällt mir“
Irgendetwas klemmt mit dem Meshing.
wifi
logread
Wed Jan 10 23:03:00 2018 daemon.notice hostapd: client1: interface state ENABLED->DISABLED
Wed Jan 10 23:03:00 2018 daemon.notice hostapd: client1: AP-DISABLED
Wed Jan 10 23:03:00 2018 daemon.notice hostapd: client1: CTRL-EVENT-TERMINATING
Wed Jan 10 23:03:00 2018 daemon.notice hostapd: nl80211: deinit ifname=client1 disabled_11b_rates=0
Wed Jan 10 23:03:00 2018 kern.info kernel: [84432.209444] device client1 left promiscuous mode
Wed Jan 10 23:03:00 2018 kern.info kernel: [84432.214351] br-client: port 3(client1) entered disabled state
Wed Jan 10 23:03:00 2018 daemon.notice netifd: Network device 'client1' link is down
Wed Jan 10 23:03:00 2018 kern.info kernel: [84432.266881] batman_adv: bat0: Interface deactivated: mesh1
Wed Jan 10 23:03:00 2018 daemon.notice netifd: Network device 'mesh1' link is down
Wed Jan 10 23:03:00 2018 daemon.notice netifd: Interface 'mesh_radio1' has link connectivity loss
Wed Jan 10 23:03:01 2018 kern.info kernel: [84432.368610] batman_adv: bat0: Removing interface: mesh1
Wed Jan 10 23:03:01 2018 daemon.notice netifd: Interface 'mesh_radio1' is disabled
Wed Jan 10 23:03:01 2018 daemon.info respondd[8195]: unable to read providers from '/usr/lib/respondd', ignoring
Wed Jan 10 23:03:11 2018 kern.emerg kernel: [84442.575791] unregister_netdevice: waiting for mesh1 to become free. Usage count = 1
Wed Jan 10 23:03:21 2018 kern.emerg kernel: [84452.715786] unregister_netdevice: waiting for mesh1 to become free. Usage count = 1
Wed Jan 10 23:03:31 2018 kern.emerg kernel: [84462.855816] unregister_netdevice: waiting for mesh1 to become free. Usage count = 1
2 „Gefällt mir“
Bei der NSM2 loco in der Wolke ist seit kurzem weniger RAM frei, Ursache noch unbekannt.
EDIT: Der kworker läuft wohl Amok (s.o.)
EDIT2: Der Versuch, bei der NSM2 loco ein Downgrade auf das aktuelle ‘stable’-Release (2016.2.6) vorzunehmen, ist fehlgeschlagen. An das Gerät muss ich wohl händisch dran.
EDIT3: Die M2 loco war gründlich gebrickt. Nach Factory-Reset und Firmware per TFT läuft sie wieder.
2 „Gefällt mir“
Habe das Gleich jetzt auch bei einem WR841v11 beobachtet. Load war bei ca. 6. Nach einem Reboot ist jetzt aber wieder Ruhe. Weitere Probleme habe ich bisher aber nicht gefunden.
Dazu gibt es ein sehr langes Ticket im Gluon auf Github.
Da gibt es auch Lösungsansätze und Rückfragen zur Diagnose dieses Problems.
Wenn das jemand durcharbeitet und den Entwicklern Rückmeldung gibt, geht es evtl. voran.
Ist den eine Aktualisierung auf 2017.3 keine Option?