ich glaube, ich habe Hinweise, warum camp-ross-office seinen Feed verloren hat und nicht wieder zurück kam.
root@camp-ross-office-2OG-2602:~# uci show | grep chann
keep_settings.wireless.radio0_channel=‚5‘
wireless.radio0.channel=‚9‘
wireless.radio0_channel=5
Ich kenne das ja nicht im Detail, aber ich mutmasse, OFFLINE SSID wird immer auf 9 ausgestrahlt und das keep_setting merkt sich den Kanal für den Rückweg, also periodisch umtunen, schauen ob Feed wieder da ist und dann wieder auf 9, wenn nein.
Der letzte Key oben scheint mir ein Vertipper zu sein, der dafuer sorgt, dass
a) das umtunen nicht klappt und der Feed nie wieder gefunden wird.
und
b) in der Tat (siehe uci I/O error thread) möglicherweise hier ein periodisches
Flash schreiben vorliegt, dass zu o.a. I/O Errors geführt hat, nach Monaten offline.
Ich habe noch die Alternative im Hinterkopf, dass I/O errors moeglicherweise beim OFFLINE mechanismus nicht wahrgenommen werden, und daher unvorhergesehene Dinge passieren
(also Henne vs Ei Unklarheit).
Irgendwann war Stromausfall oder so oder auch nur Notselbstreboot des Feed-AP und dann bloedes Timing und Offline schlaegt zu und aus die Maus.
Du meinst, das UCI Problem und das Kanalprobleme verschwinden beide durch neu flashen ? Oder hast Du was anderes vor ? Für die Aufräumaktion ohne den Hammer fehlt mir bisher das Hintergrundwissen, Der office2.OG steht im Moment bei mir. Flashen kann ich den eigentlich auch selbst, Ich werde aber vor allem probieren, das o.a. Verhalten mit dem 1043 Dagotest zu prüfen.
Dann hat es nicht mit dem FS zu tun, wenn es auch damit auftritt.
Welche Meldung gibt es denn wenn man irgendwas ändert und dann einen UCI commit versucht?
Wenn da nur ein Error zurückkommt, dann ist das schlicht was hinüber, was durch Neuflashen verschwindet.
Weil dann das FS wieder beschreibbar ist.
lol jau, habe ich… hatte den eben gerade neu geflashed… dann meshten die beide gerade wieder und er war auf der Karte, kam ich ploetzlich nicht drauf… gerade waehnt er sich offline, Gerade war ich dabei erst mal, per Handy genau zu checken, wo sich wer jetzt waehnt…aber evtl trage ich ihn erst mal rueber, wo ich noch eine Steckdose für VPN hatte.
irgendwas muss mit dem eintrag der pubkeys schiefgegangen sein…probier mal Du auf beiden, wenn Du auf dem 2602 rein kommst, koenntest Du bitte meinen vom Dagotest rueberholen, Du hattest ihn ohnehin ja. Andernfalls muss ich morgen noch mal in den Config mode…aehh heute.
Der Wert Kanal 7 laut Map ist aber falsch, die sind beide erst mal 9.
danke, einloggen klappt jetzt wieder. Evtl hat auch wieder mein 4K pubkey hier eine Rolle gespielt. UU erst mal nur mich per config mode eintragen, mehr dann per vi.
Problem ist anscheinend nun auch weg.
Wenn es da keine besondere intelligente Logik gibt wie „ich folge meinem Mesh auf seinen Kanal“ oder „bei offline kehre ich auf die Std 9 zurück“, dann ist das fixe statische Verhalten „ich bleibe auf meinem Kanal egal ob offline oder nicht und wenn Mesh wieder kommt mache ich weiter…“ genau das was ich jetzt beim Testen festgestellt habe, Insofern ist das Problem wohl gelöst. Kaputte keep_settings Einträge habe ich auch nicht mehr gefunden.
Ich habe nicht gesehen, wo der im 2.OG genau gestanden hat, aber der hat uU genau der Security im EG noch ermoeglicht, bis nach oben an den Treppenhaus AP heran zu kommen. Da geht im Moment ja nichts, weil auch die Fenster ziemlich dicht sind. Und bei so spitzen Winkeln muss man ja auch immer durch viel Material durch.
Möglicherweise ist es da sogar sinnvoll, dem Trph das Client WLAN abzustellen, dann kann der sich auf VPN und MoL fokussieren und der Office dann auf Client und Mesh und die Airtime ist ja sowieso geteilt. Aber dazu sehe ich mir erst noch mal die Oertlichkeiten an.
so sollte es eigentlich auch sein.
Wo dieser defekte UCI-Schlüssel herkam, kann ich nicht mehr nachvollziehen. Vermutlich irgendeine Firmware aus 2015/2016, die den mal gesetzt hatte.
