[Freifunk Franken Firmware 0000093]: "bat0: Changing gw mode from" consumes log
Mantis Bug Tracker
mbt at chrisi01.de
Do Jul 26 12:45:54 CEST 2018
Der folgende Eintrag wurde erledigt.
======================================================================
https://mantis.freifunk-franken.de/view.php?id=93
======================================================================
Berichtet von: Adrian Schmutzler
Zugewiesen an:
======================================================================
Projekt: Freifunk Franken Firmware
Eintrag-ID: 93
Kategorie: Freifunk Franken Firmware
Reproduzierbarkeit: N/A
Auswirkung: Unschönheit
Priorität: niedrig
Status: erledigt
Zielversion: later
Lösung: erledigt
Behoben in Version: next-stable
======================================================================
Erstellt am: 2018-02-26 15:09 CET
Zuletzt geändert: 2018-07-26 12:45 CEST
======================================================================
Zusammenfassung: "bat0: Changing gw mode from" consumes log
Beschreibung:
Since "bat0: Changing gw mode from" is written to the log every minute, it is
not possible to find older real entries there, as the newer info entries just
overwrite them.
This makes it impossible to debug errors older than from the same day.
======================================================================
Eintrags-BeziehungenID Zusammenfassung
----------------------------------------------------------------------
hat Duplikat 0000082 Batman Reset jede Minute
======================================================================
----------------------------------------------------------------------
(0000248) rola (Reporter) - 2018-02-27 14:51
https://mantis.freifunk-franken.de/view.php?id=93#c248
----------------------------------------------------------------------
Ich habs grad mal getestet. Die Router reagieren prompt auf Aenderungen der
announcten Bandbreiten, auch ohne cronjob. Gab es noch einen anderen Grund fuer
den cronjob?
----------------------------------------------------------------------
(0000249) reddog (Administrator) - 2018-03-03 12:19
https://mantis.freifunk-franken.de/view.php?id=93#c249
----------------------------------------------------------------------
Wie hast du das getestet? Ich meine, dass das früher zwar auch immer so aussah,
als ob, aber die Dinger die DHCP Requests dann trotzdem erst nach unserem Hack
umgeswitcht haben.
----------------------------------------------------------------------
(0000250) rola (Reporter) - 2018-03-03 18:41
https://mantis.freifunk-franken.de/view.php?id=93#c250
----------------------------------------------------------------------
Ja, stimmt, der dhcpdiscover geht immer zum gleichen. Geht nicht ohne :-(
----------------------------------------------------------------------
(0000252) Adrian Schmutzler (Administrator) - 2018-03-04 02:06
https://mantis.freifunk-franken.de/view.php?id=93#c252
----------------------------------------------------------------------
Falls wir es nicht komplett rausschmeißen, könnte man nicht zumindest von alle
Minute auf alle fünf Minuten wechseln?
----------------------------------------------------------------------
(0000262) Adrian Schmutzler (Administrator) - 2018-03-20 12:09
https://mantis.freifunk-franken.de/view.php?id=93#c262
----------------------------------------------------------------------
Auch hier stellt sich wieder die Frage, ob es so gut ist, wenn wir jede volle
Minute batctl umkonfigurieren und gleichzeitig alle 5 Min. batctl gwl in
configurehood nutzen.
Ich habe jetzt in meiner Firmware auf 2-59/10 * * * * umgestellt...
----------------------------------------------------------------------
(0000264) fbl (Administrator) - 2018-03-26 18:46
https://mantis.freifunk-franken.de/view.php?id=93#c264
----------------------------------------------------------------------
Ich hab dazu nochmal fix die man-Page gelesen. Man kann dem batman das durchaus
sagen, was es tun soll:
Man kann beim setzen des gw_mode client zusätzlich eine "selection class"
übergeben:
1 -> consider the gateway's advertised throughput as well as the link quality
towards the gateway and stick with the selection until the gateway disappears
2 -> chooses the gateway with the best link quality and sticks with it (ignore
the advertised throughput)
3 -> chooses the gateway with the best link quality but switches to another
gateway as soon as a better one is found
XX -> chooses the gateway with the best link quality but switches to another
gateway as soon as a better one is found which is at least XX TQ better than the
currently selected gateway (XX has to be a number between 3 and 256).
Default ist 20, das wird bei unserer Firmware aber mit 1 überschrieben.
Automatisch aktualisieren funktioniert scheinbar nur auf basis der link quality
(TQ).
Daher werden wir diesen Hack wohl behalten müssen.
Bleiben für mich zwei Fragen:
- Den Output nach /dev/null?
- Macht es ggf. Sinn, das weniger häufig auszuführen?
----------------------------------------------------------------------
(0000265) Adrian Schmutzler (Administrator) - 2018-03-26 19:30
https://mantis.freifunk-franken.de/view.php?id=93#c265
----------------------------------------------------------------------
Vielen Dank für die Erleuchtung.
Könnte man evtl. Gatewayseitig anstatt der announcten Bandbreite einfach
Penalties setzen? (Von der Idee also das, was ich bei den wireguard-peers bei
der GW-Firmware mache)
Dann müsste ein Switch mit der Methode ja klappen?!
----------------------------------------------------------------------
(0000281) reddog (Administrator) - 2018-07-26 12:45
https://mantis.freifunk-franken.de/view.php?id=93#c281
----------------------------------------------------------------------
Durch a88484a63dc9ebd8c0a85bb3372453480a0c13d6 behoben.
Eintrags-Historie
Änderungsdatum Benutzername Feld Änderung
======================================================================
2018-02-26 15:09 Adrian SchmutzlerNeuer Eintrag
2018-02-27 14:51 rola Notiz hinzugefügt: 0000248
2018-03-03 12:19 reddog Notiz hinzugefügt: 0000249
2018-03-03 18:41 rola Notiz hinzugefügt: 0000250
2018-03-03 19:00 reddog Zielversion next-feature => later
2018-03-04 02:06 Adrian SchmutzlerNotiz hinzugefügt: 0000252
2018-03-20 12:09 Adrian SchmutzlerNotiz hinzugefügt: 0000262
2018-03-26 18:46 fbl Notiz hinzugefügt: 0000264
2018-03-26 19:30 Adrian SchmutzlerNotiz hinzugefügt: 0000265
2018-07-25 15:07 reddog Beziehung hinzugefügt hat Duplikat 0000082
2018-07-25 15:07 reddog Beobachten: Adrian Schmutzler
2018-07-26 12:45 reddog Status neu => erledigt
2018-07-26 12:45 reddog Lösung offen => erledigt
2018-07-26 12:45 reddog Behoben in Version => next-stable
2018-07-26 12:45 reddog Notiz hinzugefügt: 0000281
======================================================================
Mehr Informationen über die Mailingliste franken-dev