| Message ID | 20181209150725.2447-1-fabian@blaese.de |
|---|---|
| State | Rejected |
| Headers | show |
diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv index f312c49..ad522b5 100644 --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv @@ -3,8 +3,6 @@ uci batch <<EOF delete batman-adv.bat0 set batman-adv.bat0=mesh - set batman-adv.bat0.gw_mode='client' - set batman-adv.bat0.gw_sel_class='1' set batman-adv.bat0.bridge_loop_avoidance='0' set batman-adv.bat0.network_coding='0' set batman-adv.bat0.aggregated_ogms='1' diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv deleted file mode 100644 index 21c857b..0000000 --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv +++ /dev/null @@ -1 +0,0 @@ -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client
Hallo Fabian, wenn das funktioniert, klingt das für mich sinnvoll. Die Frage ist, wie sich hier ein "kaputter" DHCP auswirkt, aber ein fehlender sollte ja abgefangen werden. In einem Setup, wo beide Gateways durch GRE den gleichen Exit verwenden, wie es inzwischen häufig der Fall ist, ist die Gateway-Selection ohnehin relativ sinnbefreit, da das Routing den Traffic "verteilt". Im Rahmen meines oberflächlichen Verständnisses tendiere ich also dazu, deinem Patch zu folgen. Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. Wie verhält es sich zwecks Kompatibilität? Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? Grüße Adrian > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf > Of Fabian Bläse > Sent: Sonntag, 9. Dezember 2018 16:07 > To: franken-dev@freifunk.net > Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection > > For our centralized setup, batmans gateway selection makes way more > problems than it solves for various reasons. > > Mainly a broken DHCP server is not recognized by it, therefore nodes might > select a gateway with a broken dhcp server. > Routers have to run a cronjob every minute to reevaluate gateway metrics > because of weird refresh behaviour with specific client modes. > > Also, gateway selection violates the OSI model by tampering with protocols > on a different layer. > > When disabling it, every DHCP Server will reply to a clients request and the > client decides which offer it is going to use. Typically the first response is > used. > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- > .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - > 2 files changed, 3 deletions(-) > delete mode 100644 src/packages/fff/fff-batman- > adv/files/usr/lib/micron.d/fff-batman-adv > > diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv > index f312c49..ad522b5 100644 > --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- > adv > +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm > +++ an-adv > @@ -3,8 +3,6 @@ > uci batch <<EOF > delete batman-adv.bat0 > set batman-adv.bat0=mesh > - set batman-adv.bat0.gw_mode='client' > - set batman-adv.bat0.gw_sel_class='1' > set batman-adv.bat0.bridge_loop_avoidance='0' > set batman-adv.bat0.network_coding='0' > set batman-adv.bat0.aggregated_ogms='1' > diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- > batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- > batman-adv > deleted file mode 100644 > index 21c857b..0000000 > --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > +++ /dev/null > @@ -1 +0,0 @@ > -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client > -- > 2.19.2
Hallo grundsätzlich, wir hatten es ganz früher (zu ca. 0.5.0 Zeiten) schon das es aus war. Der Grund warum man es eingeschaltet hat es gab in Hoods 2-3 Server und einer in Nürnberg mit den langsamsten Uplink hat am schnellsten geantwortet und alles zu sich gezogen und die "schnelleren" Server bekamen nix ab. Am 09.12.18 um 16:15 schrieb mail@adrianschmutzler.de: > Hallo Fabian, > > wenn das funktioniert, klingt das für mich sinnvoll. Die Frage ist, wie sich hier ein "kaputter" DHCP auswirkt, aber ein fehlender sollte ja abgefangen werden. gar nicht, dann antwortet halt nur noch die funktionierenden. Erst wenn kein funktionierender mehr da ist, wirds doof. Schön ist auch, wenn leases voll offerd der DHCP Server einfach keine IP mehr und der/die andere(n) bekommen den Rest ab. > > In einem Setup, wo beide Gateways durch GRE den gleichen Exit verwenden, wie es inzwischen häufig der Fall ist, ist die Gateway-Selection ohnehin relativ sinnbefreit, da das Routing den Traffic "verteilt". ja > > Im Rahmen meines oberflächlichen Verständnisses tendiere ich also dazu, deinem Patch zu folgen. ich tendieren auch eher zu ja, will aber nochmal drüber nachdenken und weitere Meinungen abwarten > > Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das aber sowieso nicht mehr von daher kann man im Prinzip damit leben. Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP Antworten leicht zu verzögen beim überlasteten GW damit es "später" antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es garantiert) > > Wie verhält es sich zwecks Kompatibilität? > Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen Routern halt nix mehr kaputt. > > Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) mfg Christian > > Grüße > > Adrian > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >> Of Fabian Bläse >> Sent: Sonntag, 9. Dezember 2018 16:07 >> To: franken-dev@freifunk.net >> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >> >> For our centralized setup, batmans gateway selection makes way more >> problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore nodes might >> select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate gateway metrics >> because of weird refresh behaviour with specific client modes. >> >> Also, gateway selection violates the OSI model by tampering with protocols >> on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request and the >> client decides which offer it is going to use. Typically the first response is >> used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de> >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman- >> adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >> adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >> +++ an-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> -- >> 2.19.2
hi noch ein Zusatz Am 09.12.18 um 16:32 schrieb Christian Dresel: > Hallo > > grundsätzlich, wir hatten es ganz früher (zu ca. 0.5.0 Zeiten) schon das > es aus war. Der Grund warum man es eingeschaltet hat es gab in Hoods 2-3 > Server und einer in Nürnberg mit den langsamsten Uplink hat am > schnellsten geantwortet und alles zu sich gezogen und die "schnelleren" > Server bekamen nix ab. > > Am 09.12.18 um 16:15 schrieb mail@adrianschmutzler.de: >> Hallo Fabian, >> >> wenn das funktioniert, klingt das für mich sinnvoll. Die Frage ist, wie sich hier ein "kaputter" DHCP auswirkt, aber ein fehlender sollte ja abgefangen werden. > > gar nicht, dann antwortet halt nur noch die funktionierenden. Erst wenn > kein funktionierender mehr da ist, wirds doof. Schön ist auch, wenn > leases voll offerd der DHCP Server einfach keine IP mehr und der/die > andere(n) bekommen den Rest ab. > >> >> In einem Setup, wo beide Gateways durch GRE den gleichen Exit verwenden, wie es inzwischen häufig der Fall ist, ist die Gateway-Selection ohnehin relativ sinnbefreit, da das Routing den Traffic "verteilt". > > ja > >> >> Im Rahmen meines oberflächlichen Verständnisses tendiere ich also dazu, deinem Patch zu folgen. > > ich tendieren auch eher zu ja, will aber nochmal drüber nachdenken und > weitere Meinungen abwarten > >> >> Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. > > Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles > "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das > aber sowieso nicht mehr von daher kann man im Prinzip damit leben. > Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt > ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP > Antworten leicht zu verzögen beim überlasteten GW damit es "später" > antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es > garantiert) > >> >> Wie verhält es sich zwecks Kompatibilität? >> Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? > > japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter > DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen > Routern halt nix mehr kaputt. > >> >> Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? > > dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als > Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall > nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) wenn ich schon von Firewall rede, wir sollten DHCP offers von den Clients eingehend blocken (falls das nicht schon der Fall ist) sonst antworten u.U. auf DHCP Requests falsch angeschlossene Fritzboxen am Clientport. Bisher wurde das dadurch "blockiert" das der Router sich nicht als GW announced hat, wenn das weg fällt, fällt diese Sicherheit auch weg. mfg Christian > > mfg > > Christian > >> >> Grüße >> >> Adrian >> >>> -----Original Message----- >>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >>> Of Fabian Bläse >>> Sent: Sonntag, 9. Dezember 2018 16:07 >>> To: franken-dev@freifunk.net >>> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >>> >>> For our centralized setup, batmans gateway selection makes way more >>> problems than it solves for various reasons. >>> >>> Mainly a broken DHCP server is not recognized by it, therefore nodes might >>> select a gateway with a broken dhcp server. >>> Routers have to run a cronjob every minute to reevaluate gateway metrics >>> because of weird refresh behaviour with specific client modes. >>> >>> Also, gateway selection violates the OSI model by tampering with protocols >>> on a different layer. >>> >>> When disabling it, every DHCP Server will reply to a clients request and the >>> client decides which offer it is going to use. Typically the first response is >>> used. >>> >>> Signed-off-by: Fabian Bläse <fabian@blaese.de> >>> --- >>> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >>> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >>> 2 files changed, 3 deletions(-) >>> delete mode 100644 src/packages/fff/fff-batman- >>> adv/files/usr/lib/micron.d/fff-batman-adv >>> >>> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv >>> index f312c49..ad522b5 100644 >>> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >>> adv >>> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >>> +++ an-adv >>> @@ -3,8 +3,6 @@ >>> uci batch <<EOF >>> delete batman-adv.bat0 >>> set batman-adv.bat0=mesh >>> - set batman-adv.bat0.gw_mode='client' >>> - set batman-adv.bat0.gw_sel_class='1' >>> set batman-adv.bat0.bridge_loop_avoidance='0' >>> set batman-adv.bat0.network_coding='0' >>> set batman-adv.bat0.aggregated_ogms='1' >>> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv >>> deleted file mode 100644 >>> index 21c857b..0000000 >>> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >>> +++ /dev/null >>> @@ -1 +0,0 @@ >>> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >>> -- >>> 2.19.2 >
Hallo zusammen, On 09.12.18 16:32, Christian Dresel wrote: >> Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. > > Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles > "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das > aber sowieso nicht mehr von daher kann man im Prinzip damit leben. > Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt > ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP > Antworten leicht zu verzögen beim überlasteten GW damit es "später" > antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es > garantiert) Jo, sowas geht mit tc. Das ist aber immer recht fummelig. Bei IPv6 gibt es theoretisch eine "Preference" im RA, allerdings müssen die Clients dann natürlich auch die Source-IP richtig wählen, dass das klappt. >> Wie verhält es sich zwecks Kompatibilität? >> Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? > > japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter > DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen > Routern halt nix mehr kaputt. > >> >> Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? > > dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als > Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall > nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) Das kann eine Firewall gar nicht unterscheiden, die hat keine Kenntnis von der Gateway Selection vom Batman. Weiterhin blockieren wir bereits DHCP Replies von Client-Seite und DHCP Requests (Port 67) von Batman-Seite (vergleiche [1] und [2]). Ach ja, bei Legacy-IP DHCP ist das übrigens ein Anycast. ;-) Gruß Fabian [1] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/30-client-dhcp [2] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/31-node-dhcp
Hallo, kann ein Mesh-Router zwischen einem DHCP vom Gateway per BATMAN (Uplink per BATMAN-Kabel mit Mesh-Router verbunden) und einer fälschlicherweise am BATMAN-Port angeschlossenen FritzBox unterscheiden? Grüße Adrian From: Fabian Bläse [mailto:fabian@blaese.de] Sent: Sonntag, 9. Dezember 2018 22:33 To: Christian Dresel <fff@chrisi01.de>; mail@adrianschmutzler.de; franken-dev@freifunk.net Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Hallo zusammen, On 09.12.18 16:32, Christian Dresel wrote: >> Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. > > Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles > "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das > aber sowieso nicht mehr von daher kann man im Prinzip damit leben. > Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt > ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP > Antworten leicht zu verzögen beim überlasteten GW damit es "später" > antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es > garantiert) Jo, sowas geht mit tc. Das ist aber immer recht fummelig. Bei IPv6 gibt es theoretisch eine "Preference" im RA, allerdings müssen die Clients dann natürlich auch die Source-IP richtig wählen, dass das klappt. >> Wie verhält es sich zwecks Kompatibilität? >> Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? > > japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter > DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen > Routern halt nix mehr kaputt. > >> >> Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? > > dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als > Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall > nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) Das kann eine Firewall gar nicht unterscheiden, die hat keine Kenntnis von der Gateway Selection vom Batman. Weiterhin blockieren wir bereits DHCP Replies von Client-Seite und DHCP Requests (Port 67) von Batman-Seite (vergleiche [1] und [2]). Ach ja, bei Legacy-IP DHCP ist das übrigens ein Anycast. ;-) Gruß Fabian [1] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/30-client-dhcp [2] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/31-node-dhcp
Hi, ich lese als Huptproblem kaputte DHCP Server raus. Deswegen am BATMAN schrauben, ist doch der falsche Weg. Man sollte lieber mal schauen, warum der DHCP Server seinen Dienst einstellt. Solange man dem DHCP die Interfaces nicht weg zieht, geht der nicht kaputt. Um die Gatewayselektion muss man sich allerdings kümmern. Also runter drehen, wenn die Leases voll werden, oder Traffic droht überzulaufen, usw. Da kann das eine nützliche Sache sein. Es ist eine der wenigen Stellschrauben in unserem schrecklichen Layer2 Netz. Ich würde es drin lassen. Aber wie schon gesagt, man muss sich darum kümmern. Robert Am 09.12.2018 um 22:32 schrieb Fabian Bläse: > Hallo zusammen, > > On 09.12.18 16:32, Christian Dresel wrote: >>> Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. >> Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles >> "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das >> aber sowieso nicht mehr von daher kann man im Prinzip damit leben. >> Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt >> ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP >> Antworten leicht zu verzögen beim überlasteten GW damit es "später" >> antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es >> garantiert) > Jo, sowas geht mit tc. Das ist aber immer recht fummelig. > Bei IPv6 gibt es theoretisch eine "Preference" im RA, allerdings müssen die Clients dann natürlich auch die Source-IP richtig wählen, dass das klappt. > >>> Wie verhält es sich zwecks Kompatibilität? >>> Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? >> japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter >> DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen >> Routern halt nix mehr kaputt. >> >>> Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? >> dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als >> Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall >> nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) > Das kann eine Firewall gar nicht unterscheiden, die hat keine Kenntnis von der Gateway Selection vom Batman. > Weiterhin blockieren wir bereits DHCP Replies von Client-Seite und DHCP Requests (Port 67) von Batman-Seite (vergleiche [1] und [2]). > Ach ja, bei Legacy-IP DHCP ist das übrigens ein Anycast. ;-) > > Gruß > Fabian > > [1] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/30-client-dhcp > [2] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/31-node-dhcp >
Hallo, nicht bei einem kaputten, aber bei einem falsch konfigurierten DHCP kann die Gateway Selection wiederum helfen. Mir ist es im Rahmen von Serverumzügen gelegentlich passiert, dass beim jeweils anderen Gateway durch einen Tippfehler ein falsches Standardgateway oder ein komplett falsches Netz für den DHCP ausgestrahlt wurde. Wird dies nicht zeitnah behoben, kann ich durch die Gateway-Selection dann die Clients an mich ziehen und so den fehlerhaften DHCP isolieren, bis das Problem behoben ist. Grüße Adrian From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Robert Langhammer Sent: Montag, 10. Dezember 2018 12:22 To: franken-dev@freifunk.net Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Hi, ich lese als Huptproblem kaputte DHCP Server raus. Deswegen am BATMAN schrauben, ist doch der falsche Weg. Man sollte lieber mal schauen, warum der DHCP Server seinen Dienst einstellt. Solange man dem DHCP die Interfaces nicht weg zieht, geht der nicht kaputt. Um die Gatewayselektion muss man sich allerdings kümmern. Also runter drehen, wenn die Leases voll werden, oder Traffic droht überzulaufen, usw. Da kann das eine nützliche Sache sein. Es ist eine der wenigen Stellschrauben in unserem schrecklichen Layer2 Netz. Ich würde es drin lassen. Aber wie schon gesagt, man muss sich darum kümmern. Robert Am 09.12.2018 um 22:32 schrieb Fabian Bläse: > Hallo zusammen, > > On 09.12.18 16:32, Christian Dresel wrote: >>> Ggf. wäre hier die Meinung von jemandem interessant, der einen eigenen Exit nutzt. >> Macht im Prinzip keinen Unterschied, aber ich kann halt nicht mehr alles >> "zu mir ziehen" obwohl ich soviel Traffic übrig hab. Mit v6 kann ich das >> aber sowieso nicht mehr von daher kann man im Prinzip damit leben. >> Schlimmer ist es das vllt. das 2. Backupgateway halt Clients abbekommt >> ohne das es das will. Da gibts aber bestimmt möglichkeiten DHCP >> Antworten leicht zu verzögen beim überlasteten GW damit es "später" >> antwortet (könnte evtl. sogar mit iptables gehen, spätestens tc kann es >> garantiert) > Jo, sowas geht mit tc. Das ist aber immer recht fummelig. > Bei IPv6 gibt es theoretisch eine "Preference" im RA, allerdings müssen die Clients dann natürlich auch die Source-IP richtig wählen, dass das klappt. > >>> Wie verhält es sich zwecks Kompatibilität? >>> Ich würde erwarten, dass die alten Router ja weiterhin Gatewayselektion brauchen, d.h. man kann die Gatewayselektion an den GWs nicht abschalten (da ändert sich dann erstmal gar nichts)? >> japp wir werden das am Gateway weiterhin brauchen. Aber ein kaputter >> DHCP Server mit aktiver GW Selection am Gateway macht bei den neuen >> Routern halt nix mehr kaputt. >> >>> Was genau passiert, wenn man batman-adv.bat0.gw_mode überhaupt nicht setzt? >> dann ist es "aus" und Batman leitet DHCP Anfragen einfach weiter als >> Multicast ins Freifunknetz. Zur Sicherheit sollte man die Firewall >> nochmal prüfen nicht das die blockt (hab ich jetzt gerade noch nicht getan) > Das kann eine Firewall gar nicht unterscheiden, die hat keine Kenntnis von der Gateway Selection vom Batman. > Weiterhin blockieren wir bereits DHCP Replies von Client-Seite und DHCP Requests (Port 67) von Batman-Seite (vergleiche [1] und [2]). > Ach ja, bei Legacy-IP DHCP ist das übrigens ein Anycast. ;-) > > Gruß > Fabian > > [1] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/30-client-dhcp > [2] https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-firewall/files/usr/lib/firewall.d/31-node-dhcp >
hi Am 11.12.18 um 11:32 schrieb Adrian Schmutzler: > nicht bei einem kaputten, aber bei einem falsch konfigurierten DHCP kann > die Gateway Selection wiederum helfen. > > > > Mir ist es im Rahmen von Serverumzügen gelegentlich passiert, dass beim > jeweils anderen Gateway durch einen Tippfehler ein falsches > Standardgateway oder ein komplett falsches Netz für den DHCP > ausgestrahlt wurde. > > Wird dies nicht zeitnah behoben, kann ich durch die Gateway-Selection > dann die Clients an mich ziehen und so den fehlerhaften DHCP isolieren, > bis das Problem behoben ist. > > die andere Seite ist halt: Wir hatten es schon sehr oft, das Server sich als Gateway announced haben, aber DHCP nicht lief. Dieses Problem würde sich damit lösen und gefühlt ist das öfter aufgetreten als ein falsch konfigurierter DHCP Server. > > > > *From:*franken-dev [mailto:franken-dev-bounces@freifunk.net] *On Behalf > Of *Robert Langhammer > > ich lese als Huptproblem kaputte DHCP Server raus. Deswegen am BATMAN > schrauben, ist doch der falsche Weg. Man sollte lieber mal schauen, falsch herum gedacht: Aktuell schraubt Batman massiv am DHCP Protokoll herum und "zerstört" das eigentlich wie es gedacht ist. Man würde hier eher wieder zurück zum "Standart" gehen wie es jeder "normale" Netzwerker kennt und eine fehleranfällige "Zwichenschicht" entfernen. > warum der DHCP Server seinen Dienst einstellt. Solange man dem DHCP die > Interfaces nicht weg zieht, geht der nicht kaputt. oh es ist schon viel kaputt gegangen nicht nur wegen fehlenden Interfaces oder so aber ja, man sollte sein GW dahingehend schon überwachen immerhin würde es ohne GW Selection gar nicht mehr auffallen wenn der DHCP Server crasht (erst wenn alle in der Hood gecrasht sind wird jemand es bemerken ;)) > > Um die Gatewayselektion muss man sich allerdings kümmern. Also runter > drehen, wenn die Leases voll werden, oder Traffic droht überzulaufen, > usw. Da kann das eine nützliche Sache sein. bei kleinen Hoods eher nicht, ich finde eh, man sollte auf seinen Server nur soviele Hoods haben wie man alleine (wenn man alle alleine betreiben würde) vertragen kann. Alles andere ist halt "spiel mit dem Feuer" Mit v6 kannst du das dann eh nicht mehr richtig steuern. > > Es ist eine der wenigen Stellschrauben in unserem schrecklichen Layer2 > Netz. Ich würde es drin lassen. Aber wie schon gesagt, man muss sich > darum kümmern. ich bin mittlerweile deutlich für raus damit mit einer weiteren Begründung: Ich muss mich nicht mehr drum kümmern aufzupassen wann meine DHCP Leases überlaufen. Wenn keine mehr da sind, offerd mein Server nix mehr und der nächste bekommt sie ab. Das ist wunderbar, das ist toll, das ist geil ;) vom Mars gesendet Christian > > Robert >
Hallo Christian, > ich bin mittlerweile deutlich für raus damit mit einer weiteren Begründung: > Ich muss mich nicht mehr drum kümmern aufzupassen wann meine DHCP Leases > überlaufen. Wenn keine mehr da sind, offerd mein Server nix mehr und der > nächste bekommt sie ab. Das ist wunderbar, das ist toll, das ist geil ;) Macht das der DHCP-Server automatisch so? Grüße Adrian From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Christian Dresel Sent: Dienstag, 11. Dezember 2018 12:40 To: franken-dev@freifunk.net Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection hi Am 11.12.18 um 11:32 schrieb Adrian Schmutzler: > nicht bei einem kaputten, aber bei einem falsch konfigurierten DHCP kann > die Gateway Selection wiederum helfen. > > > > Mir ist es im Rahmen von Serverumzügen gelegentlich passiert, dass beim > jeweils anderen Gateway durch einen Tippfehler ein falsches > Standardgateway oder ein komplett falsches Netz für den DHCP > ausgestrahlt wurde. > > Wird dies nicht zeitnah behoben, kann ich durch die Gateway-Selection > dann die Clients an mich ziehen und so den fehlerhaften DHCP isolieren, > bis das Problem behoben ist. > > die andere Seite ist halt: Wir hatten es schon sehr oft, das Server sich als Gateway announced haben, aber DHCP nicht lief. Dieses Problem würde sich damit lösen und gefühlt ist das öfter aufgetreten als ein falsch konfigurierter DHCP Server. > > > > *From:*franken-dev [mailto:franken-dev-bounces@freifunk.net] *On Behalf > Of *Robert Langhammer > > ich lese als Huptproblem kaputte DHCP Server raus. Deswegen am BATMAN > schrauben, ist doch der falsche Weg. Man sollte lieber mal schauen, falsch herum gedacht: Aktuell schraubt Batman massiv am DHCP Protokoll herum und "zerstört" das eigentlich wie es gedacht ist. Man würde hier eher wieder zurück zum "Standart" gehen wie es jeder "normale" Netzwerker kennt und eine fehleranfällige "Zwichenschicht" entfernen. > warum der DHCP Server seinen Dienst einstellt. Solange man dem DHCP die > Interfaces nicht weg zieht, geht der nicht kaputt. oh es ist schon viel kaputt gegangen nicht nur wegen fehlenden Interfaces oder so aber ja, man sollte sein GW dahingehend schon überwachen immerhin würde es ohne GW Selection gar nicht mehr auffallen wenn der DHCP Server crasht (erst wenn alle in der Hood gecrasht sind wird jemand es bemerken ;)) > > Um die Gatewayselektion muss man sich allerdings kümmern. Also runter > drehen, wenn die Leases voll werden, oder Traffic droht überzulaufen, > usw. Da kann das eine nützliche Sache sein. bei kleinen Hoods eher nicht, ich finde eh, man sollte auf seinen Server nur soviele Hoods haben wie man alleine (wenn man alle alleine betreiben würde) vertragen kann. Alles andere ist halt "spiel mit dem Feuer" Mit v6 kannst du das dann eh nicht mehr richtig steuern. > > Es ist eine der wenigen Stellschrauben in unserem schrecklichen Layer2 > Netz. Ich würde es drin lassen. Aber wie schon gesagt, man muss sich > darum kümmern. ich bin mittlerweile deutlich für raus damit mit einer weiteren Begründung: Ich muss mich nicht mehr drum kümmern aufzupassen wann meine DHCP Leases überlaufen. Wenn keine mehr da sind, offerd mein Server nix mehr und der nächste bekommt sie ab. Das ist wunderbar, das ist toll, das ist geil ;) vom Mars gesendet Christian > > Robert >
Hallo Adrian, On 11.12.18 15:23, Adrian Schmutzler wrote: >> ich bin mittlerweile deutlich für raus damit mit einer weiteren Begründung: >> Ich muss mich nicht mehr drum kümmern aufzupassen wann meine DHCP Leases >> überlaufen. Wenn keine mehr da sind, offerd mein Server nix mehr und der >> nächste bekommt sie ab. Das ist wunderbar, das ist toll, das ist geil ;) > > Macht das der DHCP-Server automatisch so? Natürlich. Was bleibt ihm denn anderes übrig? Er hat ja nix mehr zum verteilen. Übrigens bei sehr überlaufenen Standard-WLANs (bei denen viele Meschen vorbei kommen) mit hoher Lease Time häufig der Grund, warum entweder nur IPv6, oder gar nichts geht. ;-) Gruß Fabian
Jein. Das Problem ergibt sich erst gar nicht, da am BATMAN-Port angeschlossene Geräte nur irgendwo anders hin kommen, wenn sie selbst BATMAN sprechen. Was anderes passiert auf dem Port nicht. Alles was vom Router in BATMAN-Frames verpackt und losgeschickt werden soll, muss ins bat0. bat0 ist also das Interface von allem am Router in die BATMAN-Blackbox. Daher ist beim Router auch immer eine "Richtung" (ins BATMAN, vom BATMAN) bekannt. Gruß Fabian On 10.12.18 11:49, Adrian Schmutzler wrote: > Hallo, > > kann ein Mesh-Router zwischen einem DHCP vom Gateway per BATMAN (Uplink per BATMAN-Kabel mit Mesh-Router verbunden) und einer fälschlicherweise am BATMAN-Port angeschlossenen FritzBox unterscheiden? > > Grüße > Adrian
hi Um zum technischen Teil zu kommen: Wenn man (wie im Patch) gar kein GW Mode setzt, wird automatisch Client mit selection class 20 gesetzt (default). So jetzt die Frage was ist das? Von der man-page: default: 20 -> late switch (TQ 20) XX -> late switch connection 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 cur- rently selected gateway (XX has to be a number between 3 and 256). Quelle: https://downloads.open-mesh.org/batman/manpages/batctl.8.html ich glaube das wollen wir aber auch nicht oder? Zumindest will ich es nicht, weil dann kann man es auch so lassen wie es ist ;) Ich wäre dafür wenn dann das Ding wirklich ganz aus zu machen (und ich denke das war auch dein Ziel): set batman-adv.bat0.gw_mode='off' vom Mars gesendet Christian Am 09.12.18 um 16:07 schrieb Fabian Bläse: > For our centralized setup, batmans gateway selection > makes way more problems than it solves for various reasons. > > Mainly a broken DHCP server is not recognized by it, therefore > nodes might select a gateway with a broken dhcp server. > Routers have to run a cronjob every minute to reevaluate > gateway metrics because of weird refresh behaviour with specific > client modes. > > Also, gateway selection violates the OSI model by > tampering with protocols on a different layer. > > When disabling it, every DHCP Server will reply to a clients request > and the client decides which offer it is going to use. Typically the > first response is used. > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- > .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - > 2 files changed, 3 deletions(-) > delete mode 100644 src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > > diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > index f312c49..ad522b5 100644 > --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > @@ -3,8 +3,6 @@ > uci batch <<EOF > delete batman-adv.bat0 > set batman-adv.bat0=mesh > - set batman-adv.bat0.gw_mode='client' > - set batman-adv.bat0.gw_sel_class='1' > set batman-adv.bat0.bridge_loop_avoidance='0' > set batman-adv.bat0.network_coding='0' > set batman-adv.bat0.aggregated_ogms='1' > diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > deleted file mode 100644 > index 21c857b..0000000 > --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > +++ /dev/null > @@ -1 +0,0 @@ > -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >
Hallo Christian, da hast du vollkommen Recht. Ich hab diesen RFC kein einziges mal getestet, ich wollte eigentlich hauptsächlich zu einer Diskussion anregen. Ich mache dann wenn wir uns einig sind eine funktionierende Version. Gruß Fabian On 13.12.18 12:41, Christian Dresel wrote: > hi > > Um zum technischen Teil zu kommen: > > Wenn man (wie im Patch) gar kein GW Mode setzt, wird automatisch Client > mit selection class 20 gesetzt (default). > > So jetzt die Frage was ist das? Von der man-page: > default: 20 -> late switch (TQ 20) > XX -> late switch connection > 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 cur- > rently selected gateway (XX has to be a > number between 3 and 256). > Quelle: https://downloads.open-mesh.org/batman/manpages/batctl.8.html > > ich glaube das wollen wir aber auch nicht oder? Zumindest will ich es > nicht, weil dann kann man es auch so lassen wie es ist ;) > > Ich wäre dafür wenn dann das Ding wirklich ganz aus zu machen (und ich > denke das war auch dein Ziel): > > set batman-adv.bat0.gw_mode='off' > > vom Mars gesendet > Christian > > Am 09.12.18 um 16:07 schrieb Fabian Bläse: >> For our centralized setup, batmans gateway selection >> makes way more problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore >> nodes might select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate >> gateway metrics because of weird refresh behaviour with specific >> client modes. >> >> Also, gateway selection violates the OSI model by >> tampering with protocols on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request >> and the client decides which offer it is going to use. Typically the >> first response is used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de> >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> >
Hallo, 20 ist default, wenn man client setzt. Setzt man gar nichts, passiert auch gar nichts. Gegen das explizite off habe ich aber nichts. https://www.open-mesh.org/projects/batman-adv/wiki/Gateways „To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below).” Grüße Adrian From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Fabian Bläse Sent: Donnerstag, 13. Dezember 2018 12:48 To: Christian Dresel <fff@chrisi01.de>; franken-dev@freifunk.net Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Hallo Christian, da hast du vollkommen Recht. Ich hab diesen RFC kein einziges mal getestet, ich wollte eigentlich hauptsächlich zu einer Diskussion anregen. Ich mache dann wenn wir uns einig sind eine funktionierende Version. Gruß Fabian On 13.12.18 12:41, Christian Dresel wrote: > hi > > Um zum technischen Teil zu kommen: > > Wenn man (wie im Patch) gar kein GW Mode setzt, wird automatisch Client > mit selection class 20 gesetzt (default). > > So jetzt die Frage was ist das? Von der man-page: > default: 20 -> late switch (TQ 20) > XX -> late switch connection > 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 cur- > rently selected gateway (XX has to be a > number between 3 and 256). > Quelle: https://downloads.open-mesh.org/batman/manpages/batctl.8.html > > ich glaube das wollen wir aber auch nicht oder? Zumindest will ich es > nicht, weil dann kann man es auch so lassen wie es ist ;) > > Ich wäre dafür wenn dann das Ding wirklich ganz aus zu machen (und ich > denke das war auch dein Ziel): > > set batman-adv.bat0.gw_mode='off' > > vom Mars gesendet > Christian > > Am 09.12.18 um 16:07 schrieb Fabian Bläse: >> For our centralized setup, batmans gateway selection >> makes way more problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore >> nodes might select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate >> gateway metrics because of weird refresh behaviour with specific >> client modes. >> >> Also, gateway selection violates the OSI model by >> tampering with protocols on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request >> and the client decides which offer it is going to use. Typically the >> first response is used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@blaese.de> > >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> >
Hi Adrian Hast du es getestet? Als ich bei einem Testgerät unter /etc/config/batman-adv die 2 Zeilen raus geworden habe, war dennoch Client und Mode 20 gesetzt nach reboot. Erst als ich die gw_mode explizit auf off gesetzt habe war es auch wirklich aus. vom Mars gesendet Christian Am 13. Dezember 2018 13:31:04 MEZ schrieb mail@adrianschmutzler.de: >Hallo, > > > >20 ist default, wenn man client setzt. > > > >Setzt man gar nichts, passiert auch gar nichts. Gegen das explizite off >habe ich aber nichts. > > > >https://www.open-mesh.org/projects/batman-adv/wiki/Gateways > > > >„To achieve a compromise the gateway mechanism is disabled per default >and only operates on top of DHCP (details below).” > > > >Grüße > > > >Adrian > > > >From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >Of Fabian Bläse >Sent: Donnerstag, 13. Dezember 2018 12:48 >To: Christian Dresel <fff@chrisi01.de>; franken-dev@freifunk.net >Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection > > > >Hallo Christian, > >da hast du vollkommen Recht. Ich hab diesen RFC kein einziges mal >getestet, ich wollte eigentlich hauptsächlich zu einer Diskussion >anregen. > >Ich mache dann wenn wir uns einig sind eine funktionierende Version. > >Gruß >Fabian > >On 13.12.18 12:41, Christian Dresel wrote: >> hi >> >> Um zum technischen Teil zu kommen: >> >> Wenn man (wie im Patch) gar kein GW Mode setzt, wird automatisch >Client >> mit selection class 20 gesetzt (default). >> >> So jetzt die Frage was ist das? Von der man-page: >> default: 20 -> late switch (TQ 20) >> XX -> late switch connection >> 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 cur- >> rently selected gateway (XX has to be a >> number between 3 and 256). >> Quelle: https://downloads.open-mesh.org/batman/manpages/batctl.8.html > >> >> ich glaube das wollen wir aber auch nicht oder? Zumindest will ich es > >> nicht, weil dann kann man es auch so lassen wie es ist ;) >> >> Ich wäre dafür wenn dann das Ding wirklich ganz aus zu machen (und >ich >> denke das war auch dein Ziel): >> >> set batman-adv.bat0.gw_mode='off' >> >> vom Mars gesendet >> Christian >> >> Am 09.12.18 um 16:07 schrieb Fabian Bläse: >>> For our centralized setup, batmans gateway selection >>> makes way more problems than it solves for various reasons. >>> >>> Mainly a broken DHCP server is not recognized by it, therefore >>> nodes might select a gateway with a broken dhcp server. >>> Routers have to run a cronjob every minute to reevaluate >>> gateway metrics because of weird refresh behaviour with specific >>> client modes. >>> >>> Also, gateway selection violates the OSI model by >>> tampering with protocols on a different layer. >>> >>> When disabling it, every DHCP Server will reply to a clients request > >>> and the client decides which offer it is going to use. Typically the > >>> first response is used. >>> >>> Signed-off-by: Fabian Bläse <fabian@blaese.de ><mailto:fabian@blaese.de> > >>> --- >>> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 >-- >>> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 >- >>> 2 files changed, 3 deletions(-) >>> delete mode 100644 >src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >>> >>> diff --git >a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > >>> index f312c49..ad522b5 100644 >>> --- >a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > >>> +++ >b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv > >>> @@ -3,8 +3,6 @@ >>> uci batch <<EOF >>> delete batman-adv.bat0 >>> set batman-adv.bat0=mesh >>> - set batman-adv.bat0.gw_mode='client' >>> - set batman-adv.bat0.gw_sel_class='1' >>> set batman-adv.bat0.bridge_loop_avoidance='0' >>> set batman-adv.bat0.network_coding='0' >>> set batman-adv.bat0.aggregated_ogms='1' >>> diff --git >a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > >>> deleted file mode 100644 >>> index 21c857b..0000000 >>> --- >a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > >>> +++ /dev/null >>> @@ -1 +0,0 @@ >>> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw >client >>> >> > >
Hallo Christian, nein, ich habe es nicht getestet. Ich wäre so oder so auch dafür, das off explizit zu setzen. Wollen wir dann Fabians batman-Patch zum Unterdrücken der Statusmeldungen wieder mit entfernen oder vorsichtshalber drin lassen? Grüße ADrian From: Christian Dresel [mailto:fff@chrisi01.de] Sent: Donnerstag, 13. Dezember 2018 14:23 To: mail@adrianschmutzler.de; franken-dev@freifunk.net; 'Fabian Bläse' <fabian@blaese.de> Subject: RE: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Hi Adrian Hast du es getestet? Als ich bei einem Testgerät unter /etc/config/batman-adv die 2 Zeilen raus geworden habe, war dennoch Client und Mode 20 gesetzt nach reboot. Erst als ich die gw_mode explizit auf off gesetzt habe war es auch wirklich aus. vom Mars gesendet Christian Am 13. Dezember 2018 13:31:04 MEZ schrieb mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> : Hallo, 20 ist default, wenn man client setzt. Setzt man gar nichts, passiert auch gar nichts. Gegen das explizite off habe ich aber nichts. https://www.open-mesh.org/projects/batman-adv/wiki/Gateways „To achieve a compromise the gateway mechanism is disabled per default and only operates on top of DHCP (details below).” Grüße Adrian From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Fabian Bläse Sent: Donnerstag, 13. Dezember 2018 12:48 To: Christian Dresel <fff@chrisi01.de <mailto:fff@chrisi01.de> >; franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Hallo Christian, da hast du vollkommen Recht. Ich hab diesen RFC kein einziges mal getestet, ich wollte eigentlich hauptsächlich zu einer Diskussion anregen. Ich mache dann wenn wir uns einig sind eine funktionierende Version. Gruß Fabian On 13.12.18 12:41, Christian Dresel wrote: > hi > > Um zum technischen Teil zu kommen: > > Wenn man (wie im Patch) gar kein GW Mode setzt, wird automatisch Client > mit selection class 20 gesetzt (default). > > So jetzt die Frage was ist das? Von der man-page: > default: 20 -> late switch (TQ 20) > XX -> late switch connection > 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 cur- > rently selected gateway (XX has to be a > number between 3 and 256). > Quelle: https://downloads.open-mesh.org/batman/manpages/batctl.8.html > > ich glaube das wollen wir aber auch nicht oder? Zumindest will ich es > nicht, weil dann kann man es auch so lassen wie es ist ;) > > Ich wäre dafür wenn dann das Ding wirklich ganz aus zu machen (und ich > denke das war auch dein Ziel): > > set batman-adv.bat0.gw_mode='off' > > vom Mars gesendet > Christian > > Am 09.12.18 um 16:07 schrieb Fabian Bläse: >> For our centralized setup, batmans gateway selection >> makes way more problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore >> nodes might select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate >> gateway metrics because of weird refresh behaviour with specific >> client modes. >> >> Also, gateway selection violates the OSI model by >> tampering with protocols on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request >> and the client decides which offer it is going to use. Typically the >> first response is used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@blaese.de> > >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> >
Moin Fabian Am Sonntag, den 09.12.2018, 16:07 +0100 schrieb Fabian Bläse: > For our centralized setup, batmans gateway selection > makes way more problems than it solves for various reasons. Ne, das stimmt so nicht. Die Probleme kommen von wo anders und es löst ein erhebliches Problem, wozu es zur Zeit keine andere erprobte Lösung gibt. > Mainly a broken DHCP server is not recognized by it, therefore > nodes might select a gateway with a broken dhcp server. Das von dir hier angesprochene Netz ist ein zentral verwaltetes, welches von eben ganz wenigen Menschen betreut wird. Wenn diese super kleine Gruppe sowas einfaches nicht im Griff hat, dann sollte man da an anderer Stelle ansetzen oder eben die Kompetenzen dezentralisieren. > Routers have to run a cronjob every minute to reevaluate > gateway metrics because of weird refresh behaviour with specific > client modes. Jo, das war schon immer eckelig, aber es ist kein wirkliches Problem. Wenn du das System verbessern willst, dann könntest du das im batman- adv fixen. > Also, gateway selection violates the OSI model by > tampering with protocols on a different layer. Na und? Das ist doch nun wirklich kein Problem. Wo passiert das denn heute nicht? Ja, es ist eckelig, da stimme ich dir zu. Aber wer im Internet-Surfen möchte, dem ist das egal. Und mehr als das kann man mit dem zentral verwalteten Netz ja eh nicht machen. Wenn durch dieses System jetzt wirklich ernsthaft Transit laufen würde, dann könnte man sich unterhalten ob das "sauber" bleiben soll. Aber ein reines Zugangsnetz, so wie es jetzt ist, da spielt das keine Rolle. Beispiel aus der Realität: Glaubst du wirklich das Kabel oder DSL nix auf den unteren Ebene rumfrickelt? Hahaha... Ganz abgesehen davon handelt es sich beim DHCP ja nicht um Nutzdaten sondern es ist lediglich ein Werkzeug zur Verwaltung zwischen Endgerät und Zugangspunkt. Welches Protokoll dort letztlich verwendet wird und ob dieses jenige aufs brutalste verstümmelt wird oder nicht spielt für den Zweck der Verbindung keine Rolle. Das Argument lasse ich erst gelten, wenn du ein RFC schickst um batman- adv ganz raus zu kicken!! ;) > When disabling it, every DHCP Server will reply to a clients request > and the client decides which offer it is going to use. Typically the > first response is used. Ohne GW-Selection ist es mehr oder weniger unkontrollierbar, woher der erste Lease kommt. Aus der Vergangenheit ist festzuhalten: Das macht kein Spaß! Beispiel: Du hast ne mega gut angebundene Maschine, die dummerweise aber nicht ganz soooo geile Latenzen hat (was weiß ich, doofe LAN Karte oder so). Oder aber du hast ne schöne und richtig schnelle Backup- Kiste, die aber dummerweise nicht so viel Gratis-Traffic hat. Wenn man die GW-Selection von batman-adv raus nimmt, dann braucht man eine Alternative! So lange die nicht existiert und erprobt ist sollte man das Vorgehen nicht ändern. Letztlich ist es doch so, dass ihr als kleine Admin-Gruppe das Accesspoint Netzwerk für die Router-Aufsteller verwaltet. Wollt ihr euch wirklich diese Verwaltungsschraube selber weg nehmen? Das zu deaktivieren ist ja nicht mal ein Weg raus aus der zentralität. Tim > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 > -- > .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 > - > 2 files changed, 3 deletions(-) > delete mode 100644 src/packages/fff/fff-batman- > adv/files/usr/lib/micron.d/fff-batman-adv > > diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci- > defaults/93-fff-batman-adv b/src/packages/fff/fff-batman- > adv/files/etc/uci-defaults/93-fff-batman-adv > index f312c49..ad522b5 100644 > --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv > +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv > @@ -3,8 +3,6 @@ > uci batch <<EOF > delete batman-adv.bat0 > set batman-adv.bat0=mesh > - set batman-adv.bat0.gw_mode='client' > - set batman-adv.bat0.gw_sel_class='1' > set batman-adv.bat0.bridge_loop_avoidance='0' > set batman-adv.bat0.network_coding='0' > set batman-adv.bat0.aggregated_ogms='1' > diff --git a/src/packages/fff/fff-batman- > adv/files/usr/lib/micron.d/fff-batman-adv b/src/packages/fff/fff- > batman-adv/files/usr/lib/micron.d/fff-batman-adv > deleted file mode 100644 > index 21c857b..0000000 > --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- > batman-adv > +++ /dev/null > @@ -1 +0,0 @@ > -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw > client
Hallo zusammen, die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. Grüße Adrian > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf > Of Fabian Bläse > Sent: Sonntag, 9. Dezember 2018 16:07 > To: franken-dev@freifunk.net > Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection > > For our centralized setup, batmans gateway selection makes way more > problems than it solves for various reasons. > > Mainly a broken DHCP server is not recognized by it, therefore nodes might > select a gateway with a broken dhcp server. > Routers have to run a cronjob every minute to reevaluate gateway metrics > because of weird refresh behaviour with specific client modes. > > Also, gateway selection violates the OSI model by tampering with protocols > on a different layer. > > When disabling it, every DHCP Server will reply to a clients request and the > client decides which offer it is going to use. Typically the first response is > used. > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- > .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - > 2 files changed, 3 deletions(-) > delete mode 100644 src/packages/fff/fff-batman- > adv/files/usr/lib/micron.d/fff-batman-adv > > diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- > batman-adv > index f312c49..ad522b5 100644 > --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- > adv > +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm > +++ an-adv > @@ -3,8 +3,6 @@ > uci batch <<EOF > delete batman-adv.bat0 > set batman-adv.bat0=mesh > - set batman-adv.bat0.gw_mode='client' > - set batman-adv.bat0.gw_sel_class='1' > set batman-adv.bat0.bridge_loop_avoidance='0' > set batman-adv.bat0.network_coding='0' > set batman-adv.bat0.aggregated_ogms='1' > diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- > batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- > batman-adv > deleted file mode 100644 > index 21c857b..0000000 > --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv > +++ /dev/null > @@ -1 +0,0 @@ > -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client > -- > 2.19.2
Hi, drin lassen! Robert Am 29.12.2018 um 15:23 schrieb mail@adrianschmutzler.de: > Hallo zusammen, > > die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. > > Grüße > > Adrian > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >> Of Fabian Bläse >> Sent: Sonntag, 9. Dezember 2018 16:07 >> To: franken-dev@freifunk.net >> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >> >> For our centralized setup, batmans gateway selection makes way more >> problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore nodes might >> select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate gateway metrics >> because of weird refresh behaviour with specific client modes. >> >> Also, gateway selection violates the OSI model by tampering with protocols >> on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request and the >> client decides which offer it is going to use. Typically the first response is >> used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de> >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman- >> adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >> adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >> +++ an-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> -- >> 2.19.2
hi raus nehmen (Patch weiter verfolgen) Grüße vom roten Planeten Christian Am 29.12.18 um 16:29 schrieb Robert Langhammer: > Hi, > > drin lassen! > > Robert > > Am 29.12.2018 um 15:23 schrieb mail@adrianschmutzler.de: >> Hallo zusammen, >> >> die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. >> >> Grüße >> >> Adrian >> >>> -----Original Message----- >>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >>> Of Fabian Bläse >>> Sent: Sonntag, 9. Dezember 2018 16:07 >>> To: franken-dev@freifunk.net >>> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >>> >>> For our centralized setup, batmans gateway selection makes way more >>> problems than it solves for various reasons. >>> >>> Mainly a broken DHCP server is not recognized by it, therefore nodes might >>> select a gateway with a broken dhcp server. >>> Routers have to run a cronjob every minute to reevaluate gateway metrics >>> because of weird refresh behaviour with specific client modes. >>> >>> Also, gateway selection violates the OSI model by tampering with protocols >>> on a different layer. >>> >>> When disabling it, every DHCP Server will reply to a clients request and the >>> client decides which offer it is going to use. Typically the first response is >>> used. >>> >>> Signed-off-by: Fabian Bläse <fabian@blaese.de> >>> --- >>> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >>> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >>> 2 files changed, 3 deletions(-) >>> delete mode 100644 src/packages/fff/fff-batman- >>> adv/files/usr/lib/micron.d/fff-batman-adv >>> >>> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv >>> index f312c49..ad522b5 100644 >>> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >>> adv >>> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >>> +++ an-adv >>> @@ -3,8 +3,6 @@ >>> uci batch <<EOF >>> delete batman-adv.bat0 >>> set batman-adv.bat0=mesh >>> - set batman-adv.bat0.gw_mode='client' >>> - set batman-adv.bat0.gw_sel_class='1' >>> set batman-adv.bat0.bridge_loop_avoidance='0' >>> set batman-adv.bat0.network_coding='0' >>> set batman-adv.bat0.aggregated_ogms='1' >>> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv >>> deleted file mode 100644 >>> index 21c857b..0000000 >>> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >>> +++ /dev/null >>> @@ -1 +0,0 @@ >>> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >>> -- >>> 2.19.2 >
Ich bin dafür es rauszunehmen. Wenn man wirklich einen DHCP über den anderen priorisieren möchte, könnte man das mit vermutlich weniger fehleranfälligen tc Regeln machen. Manche DHCP Server können die Offers glaube ich auch von sich aus verzögern. Dann spart man sich sowohl das regelmäßig auf den Routern laufende Skript, als auch das geskripte, ob noch Leases frei sind und entsprechendes Deaktivieren des gateway-announcements, falls nicht. Dann müsste man die IP-Netze auch nicht mehr zwingend doppelt so groß machen, wie maximal Clients zu erwarten sind. Gruß Fabian On 29.12.18 15:23, mail@adrianschmutzler.de wrote: > Hallo zusammen, > > die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. > > Grüße > > Adrian > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >> Of Fabian Bläse >> Sent: Sonntag, 9. Dezember 2018 16:07 >> To: franken-dev@freifunk.net >> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >> >> For our centralized setup, batmans gateway selection makes way more >> problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore nodes might >> select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate gateway metrics >> because of weird refresh behaviour with specific client modes. >> >> Also, gateway selection violates the OSI model by tampering with protocols >> on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request and the >> client decides which offer it is going to use. Typically the first response is >> used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de> >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman- >> adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >> adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >> +++ an-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> -- >> 2.19.2
Hallo, sieht so aus, als hätten wir 2 zu 1 für den Patch. Dazu kommt Tims Kommentar, der eher gegen den Patch war sowie meine Tendenz den Patch zu verfolgen. Entsprechend ist die (knappe) Mehrheit dafür und Fabian kann eine „richtige“ Version schicken. Dann bleibt auch noch ein bisschen Zeit für Vetos. Beste Grüße Adrian From: Fabian Bläse [mailto:fabian@blaese.de] Sent: Sonntag, 30. Dezember 2018 17:55 To: mail@adrianschmutzler.de; franken-dev@freifunk.net Subject: Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection Ich bin dafür es rauszunehmen. Wenn man wirklich einen DHCP über den anderen priorisieren möchte, könnte man das mit vermutlich weniger fehleranfälligen tc Regeln machen. Manche DHCP Server können die Offers glaube ich auch von sich aus verzögern. Dann spart man sich sowohl das regelmäßig auf den Routern laufende Skript, als auch das geskripte, ob noch Leases frei sind und entsprechendes Deaktivieren des gateway-announcements, falls nicht. Dann müsste man die IP-Netze auch nicht mehr zwingend doppelt so groß machen, wie maximal Clients zu erwarten sind. Gruß Fabian On 29.12.18 15:23, mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> wrote: > Hallo zusammen, > > die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. > > Grüße > > Adrian > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >> Of Fabian Bläse >> Sent: Sonntag, 9. Dezember 2018 16:07 >> To: franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> >> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >> >> For our centralized setup, batmans gateway selection makes way more >> problems than it solves for various reasons. >> >> Mainly a broken DHCP server is not recognized by it, therefore nodes might >> select a gateway with a broken dhcp server. >> Routers have to run a cronjob every minute to reevaluate gateway metrics >> because of weird refresh behaviour with specific client modes. >> >> Also, gateway selection violates the OSI model by tampering with protocols >> on a different layer. >> >> When disabling it, every DHCP Server will reply to a clients request and the >> client decides which offer it is going to use. Typically the first response is >> used. >> >> Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@blaese.de> > >> --- >> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >> 2 files changed, 3 deletions(-) >> delete mode 100644 src/packages/fff/fff-batman- >> adv/files/usr/lib/micron.d/fff-batman-adv >> >> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >> batman-adv >> index f312c49..ad522b5 100644 >> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >> adv >> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >> +++ an-adv >> @@ -3,8 +3,6 @@ >> uci batch <<EOF >> delete batman-adv.bat0 >> set batman-adv.bat0=mesh >> - set batman-adv.bat0.gw_mode='client' >> - set batman-adv.bat0.gw_sel_class='1' >> set batman-adv.bat0.bridge_loop_avoidance='0' >> set batman-adv.bat0.network_coding='0' >> set batman-adv.bat0.aggregated_ogms='1' >> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >> batman-adv >> deleted file mode 100644 >> index 21c857b..0000000 >> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >> +++ /dev/null >> @@ -1 +0,0 @@ >> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >> -- >> 2.19.2
Hallo Adrian, eine knappe Mehrheit finde ich bei so einer grundlegenden Änderung für etwas dürftig, da würde ich mal nichts überstürzen. Hat sich der Rest, der sich negativ zu diesem Patch geäußert hat, mal überlegt, ob das verzögern von DHCP Offers auch eine denkbare Alternative wäre? Siehe letzte Mail von mir. Gruß Fabian On 02.01.19 10:07, mail@adrianschmutzler.de wrote: > Hallo, > > > > sieht so aus, als hätten wir 2 zu 1 für den Patch. > > > > Dazu kommt Tims Kommentar, der eher gegen den Patch war sowie meine Tendenz den Patch zu verfolgen. > > > > Entsprechend ist die (knappe) Mehrheit dafür und Fabian kann eine „richtige“ Version schicken. > > > > Dann bleibt auch noch ein bisschen Zeit für Vetos. > > > > Beste Grüße > > > > Adrian > > > > *From:*Fabian Bläse [mailto:fabian@blaese.de] > *Sent:* Sonntag, 30. Dezember 2018 17:55 > *To:* mail@adrianschmutzler.de; franken-dev@freifunk.net > *Subject:* Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection > > > > Ich bin dafür es rauszunehmen. Wenn man wirklich einen DHCP über den anderen priorisieren möchte, könnte man das mit vermutlich weniger fehleranfälligen tc Regeln machen. Manche DHCP Server können die Offers glaube ich auch von sich aus verzögern. > > Dann spart man sich sowohl das regelmäßig auf den Routern laufende Skript, als auch das geskripte, ob noch Leases frei sind und entsprechendes Deaktivieren des gateway-announcements, falls nicht. > > Dann müsste man die IP-Netze auch nicht mehr zwingend doppelt so groß machen, wie maximal Clients zu erwarten sind. > > Gruß > Fabian > > On 29.12.18 15:23, mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> wrote: >> Hallo zusammen, >> >> die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. > >> >> Grüße >> >> Adrian >> >>> -----Original Message----- >>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >>> Of Fabian Bläse >>> Sent: Sonntag, 9. Dezember 2018 16:07 >>> To: franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> >>> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >>> >>> For our centralized setup, batmans gateway selection makes way more >>> problems than it solves for various reasons. >>> >>> Mainly a broken DHCP server is not recognized by it, therefore nodes might >>> select a gateway with a broken dhcp server. >>> Routers have to run a cronjob every minute to reevaluate gateway metrics >>> because of weird refresh behaviour with specific client modes. >>> >>> Also, gateway selection violates the OSI model by tampering with protocols >>> on a different layer. >>> >>> When disabling it, every DHCP Server will reply to a clients request and the >>> client decides which offer it is going to use. Typically the first response is >>> used. >>> >>> Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@blaese.de>> >>> --- >>> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >>> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >>> 2 files changed, 3 deletions(-) >>> delete mode 100644 src/packages/fff/fff-batman- >>> adv/files/usr/lib/micron.d/fff-batman-adv >>> >>> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>> batman-adv >>> index f312c49..ad522b5 100644 >>> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >>> adv >>> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >>> +++ an-adv >>> @@ -3,8 +3,6 @@ >>> uci batch <<EOF >>> delete batman-adv.bat0 >>> set batman-adv.bat0=mesh >>> - set batman-adv.bat0.gw_mode='client' >>> - set batman-adv.bat0.gw_sel_class='1' >>> set batman-adv.bat0.bridge_loop_avoidance='0' >>> set batman-adv.bat0.network_coding='0' >>> set batman-adv.bat0.aggregated_ogms='1' >>> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>> batman-adv >>> deleted file mode 100644 >>> index 21c857b..0000000 >>> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >>> +++ /dev/null >>> @@ -1 +0,0 @@ >>> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >>> -- >>> 2.19.2 > > >
Hallo Fabian, ich werde auf keinen Fall für die gw-selection kämpfen. Wenn ihr die raus kickt, ist das ok. Die gw-sel. zu ändern ist meines Erachtens simpler als die dhcpd.conf zu ändern und dann den Dienst neu zu starten. Robert Am 09.01.19 um 23:41 schrieb Fabian Bläse: > Hallo Adrian, > > eine knappe Mehrheit finde ich bei so einer grundlegenden Änderung für etwas dürftig, da würde ich mal nichts überstürzen. > > Hat sich der Rest, der sich negativ zu diesem Patch geäußert hat, mal überlegt, ob das verzögern von DHCP Offers auch eine denkbare Alternative wäre? Siehe letzte Mail von mir. > > Gruß > Fabian > > On 02.01.19 10:07, mail@adrianschmutzler.de wrote: >> Hallo, >> >> >> >> sieht so aus, als hätten wir 2 zu 1 für den Patch. >> >> >> >> Dazu kommt Tims Kommentar, der eher gegen den Patch war sowie meine Tendenz den Patch zu verfolgen. >> >> >> >> Entsprechend ist die (knappe) Mehrheit dafür und Fabian kann eine „richtige“ Version schicken. >> >> >> >> Dann bleibt auch noch ein bisschen Zeit für Vetos. >> >> >> >> Beste Grüße >> >> >> >> Adrian >> >> >> >> *From:*Fabian Bläse [mailto:fabian@blaese.de] >> *Sent:* Sonntag, 30. Dezember 2018 17:55 >> *To:* mail@adrianschmutzler.de; franken-dev@freifunk.net >> *Subject:* Re: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >> >> >> >> Ich bin dafür es rauszunehmen. Wenn man wirklich einen DHCP über den anderen priorisieren möchte, könnte man das mit vermutlich weniger fehleranfälligen tc Regeln machen. Manche DHCP Server können die Offers glaube ich auch von sich aus verzögern. >> >> Dann spart man sich sowohl das regelmäßig auf den Routern laufende Skript, als auch das geskripte, ob noch Leases frei sind und entsprechendes Deaktivieren des gateway-announcements, falls nicht. >> >> Dann müsste man die IP-Netze auch nicht mehr zwingend doppelt so groß machen, wie maximal Clients zu erwarten sind. >> >> Gruß >> Fabian >> >> On 29.12.18 15:23, mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> wrote: >>> Hallo zusammen, >>> >>> die Diskussion zu diesem Patch ist glaube ich soweit durch, ich würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim bestehenden System bleibt. >>> Grüße >>> >>> Adrian >>> >>>> -----Original Message----- >>>> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >>>> Of Fabian Bläse >>>> Sent: Sonntag, 9. Dezember 2018 16:07 >>>> To: franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> >>>> Subject: [RFC PATCH] fff-batman-adv: Disable batman gw-selection >>>> >>>> For our centralized setup, batmans gateway selection makes way more >>>> problems than it solves for various reasons. >>>> >>>> Mainly a broken DHCP server is not recognized by it, therefore nodes might >>>> select a gateway with a broken dhcp server. >>>> Routers have to run a cronjob every minute to reevaluate gateway metrics >>>> because of weird refresh behaviour with specific client modes. >>>> >>>> Also, gateway selection violates the OSI model by tampering with protocols >>>> on a different layer. >>>> >>>> When disabling it, every DHCP Server will reply to a clients request and the >>>> client decides which offer it is going to use. Typically the first response is >>>> used. >>>> >>>> Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@blaese.de>> >>>> --- >>>> .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- >>>> .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - >>>> 2 files changed, 3 deletions(-) >>>> delete mode 100644 src/packages/fff/fff-batman- >>>> adv/files/usr/lib/micron.d/fff-batman-adv >>>> >>>> diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>>> batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff- >>>> batman-adv >>>> index f312c49..ad522b5 100644 >>>> --- a/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- >>>> adv >>>> +++ b/src/packages/fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batm >>>> +++ an-adv >>>> @@ -3,8 +3,6 @@ >>>> uci batch <<EOF >>>> delete batman-adv.bat0 >>>> set batman-adv.bat0=mesh >>>> - set batman-adv.bat0.gw_mode='client' >>>> - set batman-adv.bat0.gw_sel_class='1' >>>> set batman-adv.bat0.bridge_loop_avoidance='0' >>>> set batman-adv.bat0.network_coding='0' >>>> set batman-adv.bat0.aggregated_ogms='1' >>>> diff --git a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>>> batman-adv b/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff- >>>> batman-adv >>>> deleted file mode 100644 >>>> index 21c857b..0000000 >>>> --- a/src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv >>>> +++ /dev/null >>>> @@ -1 +0,0 @@ >>>> -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl gw client >>>> -- >>>> 2.19.2 >> >>
Moin Fabian Am Dienstag, den 11.12.2018, 15:31 +0100 schrieb Fabian Bläse: > Hat sich der Rest, der sich negativ zu diesem Patch geäußert hat, mal > überlegt, ob das verzögern von DHCP Offers auch eine denkbare > Alternative wäre? Siehe letzte Mail von mir. Ich hatte mich negativ geäußert, weil ich das System noch ohne GW- Selection kenne und das war alles andere als toll. Deine Argumente habe ich mMn alle ausser Kraft gesetzt. Mein Vorschlag, das Thema mit der Refresh rate auf andere Weise zu verbessern wurde nicht weiter verfolgt, geschweige denn kommentiert. Du hast noch keine Alternative gezeigt. Der Vorschlag es _irgendwie_ mit TC zu machen klingt erstmal unausgegohren und letztlich riecht das auch total nach pfusch. Wer weiß, welche Probleme dabei auftreten. So lange es keine bessere Alternative gibt würde ich das auf keinen Fall einfach weg nehmen. Wenn es eine gibt, dann kann man überlegen ob man umsteigt. Letztlich ist mir das aber total egal, ob das in den zentral verwalteten Hoods drin ist oder nicht. Tim > Gruß > Fabian > > On 02.01.19 10:07, mail@adrianschmutzler.de wrote: > > Hallo, > > > > > > > > sieht so aus, als hätten wir 2 zu 1 für den Patch. > > > > > > > > Dazu kommt Tims Kommentar, der eher gegen den Patch war sowie meine > > Tendenz den Patch zu verfolgen. > > > > > > > > Entsprechend ist die (knappe) Mehrheit dafür und Fabian kann eine > > „richtige“ Version schicken. > > > > > > > > Dann bleibt auch noch ein bisschen Zeit für Vetos. > > > > > > > > Beste Grüße > > > > > > > > Adrian > > > > > > > > *From:*Fabian Bläse [mailto:fabian@blaese.de] > > *Sent:* Sonntag, 30. Dezember 2018 17:55 > > *To:* mail@adrianschmutzler.de; franken-dev@freifunk.net > > *Subject:* Re: [RFC PATCH] fff-batman-adv: Disable batman gw- > > selection > > > > > > > > Ich bin dafür es rauszunehmen. Wenn man wirklich einen DHCP über > > den anderen priorisieren möchte, könnte man das mit vermutlich > > weniger fehleranfälligen tc Regeln machen. Manche DHCP Server > > können die Offers glaube ich auch von sich aus verzögern. > > > > Dann spart man sich sowohl das regelmäßig auf den Routern laufende > > Skript, als auch das geskripte, ob noch Leases frei sind und > > entsprechendes Deaktivieren des gateway-announcements, falls nicht. > > > > Dann müsste man die IP-Netze auch nicht mehr zwingend doppelt so > > groß machen, wie maximal Clients zu erwarten sind. > > > > Gruß > > Fabian > > > > On 29.12.18 15:23, mail@adrianschmutzler.de <mailto:mail@adrianschm > > utzler.de> wrote: > > > Hallo zusammen, > > > > > > die Diskussion zu diesem Patch ist glaube ich soweit durch, ich > > > würde es für sinnvoll erachten, wenn nun jeder kurz mitteilt, ob > > > er dafür ist, diesen Patch weiter zu verfolgen oder lieber beim > > > bestehenden System bleibt. > > > > > > Grüße > > > > > > Adrian > > > > > > > -----Original Message----- > > > > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On > > > > Behalf > > > > Of Fabian Bläse > > > > Sent: Sonntag, 9. Dezember 2018 16:07 > > > > To: franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> > > > > Subject: [RFC PATCH] fff-batman-adv: Disable batman gw- > > > > selection > > > > > > > > For our centralized setup, batmans gateway selection makes way > > > > more > > > > problems than it solves for various reasons. > > > > > > > > Mainly a broken DHCP server is not recognized by it, therefore > > > > nodes might > > > > select a gateway with a broken dhcp server. > > > > Routers have to run a cronjob every minute to reevaluate > > > > gateway metrics > > > > because of weird refresh behaviour with specific client modes. > > > > > > > > Also, gateway selection violates the OSI model by tampering > > > > with protocols > > > > on a different layer. > > > > > > > > When disabling it, every DHCP Server will reply to a clients > > > > request and the > > > > client decides which offer it is going to use. Typically the > > > > first response is > > > > used. > > > > > > > > Signed-off-by: Fabian Bläse <fabian@blaese.de <mailto:fabian@bl > > > > aese.de>> > > > > --- > > > > .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman- > > > > adv | 2 -- > > > > .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman- > > > > adv | 1 - > > > > 2 files changed, 3 deletions(-) > > > > delete mode 100644 src/packages/fff/fff-batman- > > > > adv/files/usr/lib/micron.d/fff-batman-adv > > > > > > > > diff --git a/src/packages/fff/fff-batman-adv/files/etc/uci- > > > > defaults/93-fff- > > > > batman-adv b/src/packages/fff/fff-batman-adv/files/etc/uci- > > > > defaults/93-fff- > > > > batman-adv > > > > index f312c49..ad522b5 100644 > > > > --- a/src/packages/fff/fff-batman-adv/files/etc/uci- > > > > defaults/93-fff-batman- > > > > adv > > > > +++ b/src/packages/fff/fff-batman-adv/files/etc/uci- > > > > defaults/93-fff-batm > > > > +++ an-adv > > > > @@ -3,8 +3,6 @@ > > > > uci batch <<EOF > > > > delete batman-adv.bat0 > > > > set batman-adv.bat0=mesh > > > > - set batman-adv.bat0.gw_mode='client' > > > > - set batman-adv.bat0.gw_sel_class='1' > > > > set batman-adv.bat0.bridge_loop_avoidance='0' > > > > set batman-adv.bat0.network_coding='0' > > > > set batman-adv.bat0.aggregated_ogms='1' > > > > diff --git a/src/packages/fff/fff-batman- > > > > adv/files/usr/lib/micron.d/fff- > > > > batman-adv b/src/packages/fff/fff-batman- > > > > adv/files/usr/lib/micron.d/fff- > > > > batman-adv > > > > deleted file mode 100644 > > > > index 21c857b..0000000 > > > > --- a/src/packages/fff/fff-batman- > > > > adv/files/usr/lib/micron.d/fff-batman-adv > > > > +++ /dev/null > > > > @@ -1 +0,0 @@ > > > > -*/1 * * * * /usr/sbin/batctl gw off; sleep 1; /usr/sbin/batctl > > > > gw client > > > > -- > > > > 2.19.2 > > > > > > > >
For our centralized setup, batmans gateway selection makes way more problems than it solves for various reasons. Mainly a broken DHCP server is not recognized by it, therefore nodes might select a gateway with a broken dhcp server. Routers have to run a cronjob every minute to reevaluate gateway metrics because of weird refresh behaviour with specific client modes. Also, gateway selection violates the OSI model by tampering with protocols on a different layer. When disabling it, every DHCP Server will reply to a clients request and the client decides which offer it is going to use. Typically the first response is used. Signed-off-by: Fabian Bläse <fabian@blaese.de> --- .../fff/fff-batman-adv/files/etc/uci-defaults/93-fff-batman-adv | 2 -- .../fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv | 1 - 2 files changed, 3 deletions(-) delete mode 100644 src/packages/fff/fff-batman-adv/files/usr/lib/micron.d/fff-batman-adv