<div dir='auto'><div dir="auto"><div dir="auto"><div dir="auto">Hi Sven und alle -<div dir="auto"><br></div><div dir="auto">das stimmt alles. Die Metrik ist an sich nicht der Hop-Count, sondern der ETX-Gesamtwert. Klar, bei einem ETX-Wert von ~1 pro dezidiertem Backbone-Link kommt am Ende doch wieder Hop-Count heraus.</div><div dir="auto"><br></div><div dir="auto">Was kein allzu großes Problem wäre, wenn Smartgateway denn funktionieren würde.</div><div dir="auto"><br></div><div dir="auto">Gateway-Flapping und die fehlende Option Gateways zu wählen sind zwei Gründe, warum wir u.a. auf der Zwingli mit LQ-Mult die ETX-Werte zu bestimmten Gateways verbiegen. Eigentlich ein dreckiger Workaround. Wie leidlich bekannt kann es aber auch passieren, dass der bevorzugte Gateway zum Blackhole wird - dafür gibt es das dynamische Gateway-Plugin.</div><div dir="auto"><br></div><div dir="auto">Mit dem Gespann aus LQ-Mult und dynGW haben wir seit etwa 17 Jahren (?) eine Lösung, die sich produktiv einsetzen lässt.</div><div dir="auto"><br></div><div dir="auto">So richtig toll ist es aber nicht. Mit LQ-Mult verbiegen wir das Routing, um Gateway-Probleme zu lösen. Damit behindern wir potenziell den Mesh-internen Traffic, vor allem über die Super-Nodes. Auch DynGW kann ein Internet-Blackhole nicht immer zuverlässig detektieren.</div><div dir="auto"><br></div><div dir="auto">Wie schon mal hier erwähnt, hatte ich Henning Rogge vor einem Jahrzehnt gebeten, die Option der Gateway-Auswahl von B.A.T.M.A.N in olsrd als Plug-In nachzubauen. Es hätte völlig gereicht, wenn lediglich die Funktion von </div><div dir="auto"><br></div><div dir="auto">batmand -p <preferred gw-ip> interface(s)</div><div dir="auto"><br></div><div dir="auto">mit Routing-Class 1 als Fallback richtig funktionieren würde. Der aktuelle Stand ist, dass der bevorzugte Gateway nach wie vor nicht gewählt werden kann. Auch die automatische GW-Selektion nach Routing Class 1 scheint fehlerhaft zu sein.</div><div dir="auto"><br></div><div dir="auto">Dass das nach einem Jahrzehnt immer noch so ist, ist einigermaßen erstaunlich.</div><div dir="auto"><br></div><div dir="auto">Gateway-Auswahl-Optionen aus der batmand manpage:</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">-p preferred gateway</div><div dir="auto"><br></div><div dir="auto">Set the internet gateway by yourself. Note: This automatically switches your daemon to "internet search modus" with "-r 1" unless "-r" is given. If the prefered gateway is not found the gateway selection will use the current routing class to choose a gateway.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"> -r routing class<br></div><div dir="auto"><br></div><div dir="auto">The routing class can be set to four values ‐ it enables "internet search modus". The daemon will choose an internet gateway based on certain criteria (unless "-p" is specified):</div><div dir="auto"><br></div><div dir="auto">default: 0 -> set no default route</div><div dir="auto"><br></div><div dir="auto">allowed values:</div><div dir="auto"><br></div><div dir="auto">1 -> use fast connection</div><div dir="auto">2 -> use stable connection</div><div dir="auto">3 -> use fast‐switch connection</div><div dir="auto">XX -> use late‐switch connection</div><div dir="auto"><br></div><div dir="auto">In level 1, B.A.T.M.A.N tries to find the best available connection by watching the uplinks throughput and the link quality. </div><div dir="auto"><br></div><div dir="auto">In level 2, B.A.T.M.A.N compares the link quality of the internet node and chooses the one with the best link quality. </div><div dir="auto"><br></div><div dir="auto">In level 3, B.A.T.M.A.N compares the link quality of the internet node and chooses the one with the best link quality but switches to another gateway as soon as a better connection is found. </div><div dir="auto"><br></div><div dir="auto">In level XX (number between 3 and 256) B.A.T.M.A.N compares the link quality of the internet node and chooses the one with the best link</div><div dir="auto">quality but switches to another gateway as soon as this gateway has a TQ value which is XX better than the currently selected gateway.</div><div dir="auto"><br></div><div dir="auto"></Zitat></div><div dir="auto"><br></div><div dir="auto">Es wäre naheliegend, wie hier schon mehrere Leute vorgeschlagen haben:</div><div dir="auto"><br></div><div dir="auto">Smartgateway in der Firmware abschaltbar zu machen.</div><div dir="auto"><br></div><div dir="auto">Die Funktion der Gateway-Selektion in Smart-Gateway einzubauen.</div><div dir="auto"><br></div><div dir="auto">SmartGateway Routing Class 1 zu debuggen.</div><div dir="auto"><br></div><div dir="auto">Es ist erstaunlich, dass das alles immer noch Baustelle ist.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Disclaimer/Nachtrag:</div><div dir="auto"><br></div><div dir="auto">Gut, ich habe mich selbst auch nicht darum gekümmert.</div><div dir="auto"><br></div><div dir="auto">OLSR ist irgendwie nicht mehr “my department“. Ich benutze es noch, weil die Welt um mich herum es immer noch benutzt. ;)</div><div dir="auto"><br></div><div dir="auto">Ich hatte angenommen, dass das SGW-Plug-In von der OLSR-Community längst gefixt ist. Es ist doch ganz wesentlich, wenn man über das Mesh ins Internet will und mehrere Gateways hat.</div><div dir="auto"><br></div><div dir="auto">Vor 16 Jahren haben Thomas Lopatic und ich mit dem B.A.T.M.A.N. Projekt angefangen, mit dem Ziel, olsrd in Freifunk zu ersetzen. <br></div><div dir="auto"><br></div><div dir="auto">Die Motivation zum Ersetzen von OLSR ist hier erklärt: https://www.open-mesh.org/projects/open-mesh/wiki/The-olsr-story</div><div dir="auto"><br></div><div dir="auto">Wir hatten davor zusammen u.a. ETX und Fisheye in olsrd 'verbrochen'. Zumindest in Berlin hat es ja nicht geklappt, olsrd durch B.A.T.M.A.N. zu ersetzen. Was anfangs etwas enttäuschend für mich war, aber das Beharrungsvermögen ist legitim und nachvollziehbar. OLSR funktioniert und skaliert durch beharrliches Optimieren ganz gut, bis auf die ewige Gateway-Problematik durch das defekte Plug-In. Ausserdem ist es schön in Luci integriert.</div><div dir="auto"><br></div><div dir="auto">Also müssten die Berliner Freifunkas wohl das Plug-In fixen. [Hint, hint]</div><div dir="auto"><br></div><div dir="auto">LG Elektra </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div><br><div class="elided-text">Am 21.01.2021 21:08 schrieb Sven Roederer <freifunk@it-solutions.geroedel.de>:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hallo,</p>
<p dir="ltr">Diesen "Problemball" hast du ja schon öfter Richtung Firmwareentwickler geworfen. Aber bisher hat ihn niemand so Recht fangen wollen...</p>
<p dir="ltr">Aber grundsätzlich hab ich aus Elektra's Kommentar vor ein paar Tagen, den Punkt mitgenommen, dass durch samrtgateway stabile TCP-Verbindungen möglich wären. Was durch den Einsatz des IPIP-Tunnels passiert. Bei nur Routing basierter Gatewayauswahl gibt es die Möglichkeit ja nicht und nur die Metrik am jeweiligen Hop entscheidet über den weiteren Weg. <br>
Ist es dann nicht so, dass ein Hop auf dem Weg, wenn 2 Exit-Gateway s die gleiche hopCount haben, durchaus ein Paket zum Gateway 1 und das nächste u.U. zum Gateway2 schickt. Sowas macht natürlich dann TCP kaputt.<br>
Hab ich mir das richtig zusammengereimt?</p>
<p dir="ltr">Sven</p>
<p dir="ltr">Am 19. Januar 2021 10:11:14 MEZ schrieb ff@xayax.de:<br>
>Guten Tag,<br>
><br>
>es arbeiten ja gerade wieder einige engagierte Leute an der Firmware.<br>
>Vielleicht könnten wir dann mal ein „altes“ Problem angehen?<br>
>Ich fände es gut, wenn wir das Smartgateway entfernen würden. Es hat<br>
>m.E. keine Vorteile, dafür aber ein paar Nachteile. <br>
>Da nicht alle Exit-Gateways das Plugin aktiviert haben, wird teilweise<br>
>durch die ganze Stadt geroutet (siehe aktuell Sven Adlershof -><br>
>Friedrichshain) statt die nähere und stabilere Route (Adlershof -><br>
>Baume) zu nehmen. <br>
>Es gibt zwar eine Anleitung, wie das Smartgateway deaktiviert werden<br>
>kann:<br>
>https://wiki.freifunk-potsdam.de/KathleenZusatz#Smart_Gateway_abschalten<br>
><br>
>Aber ich habe irgendwie in Erinnerung, dass das auch nicht bei allen<br>
>funktioniert hat. <br>
><br>
>Also. Spricht irgend etwas dagegen, diese Funktionalität komplett (z.B.<br>
>im nächsten Release) zu enfternen? <br>
><br>
>lg<br>
>kaya<br>
>_______________________________________________<br>
>Berlin mailing list<br>
>Berlin@berlin.freifunk.net<br>
>http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
>Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
<p dir="ltr">_______________________________________________<br>
Berlin mailing list<br>
Berlin@berlin.freifunk.net<br>
http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
</blockquote></div><br></div></div><div><br><div class="elided-text">Am 21.01.2021 21:08 schrieb Sven Roederer <freifunk@it-solutions.geroedel.de>:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hallo,</p>
<p dir="ltr">Diesen "Problemball" hast du ja schon öfter Richtung Firmwareentwickler geworfen. Aber bisher hat ihn niemand so Recht fangen wollen...</p>
<p dir="ltr">Aber grundsätzlich hab ich aus Elektra's Kommentar vor ein paar Tagen, den Punkt mitgenommen, dass durch samrtgateway stabile TCP-Verbindungen möglich wären. Was durch den Einsatz des IPIP-Tunnels passiert. Bei nur Routing basierter Gatewayauswahl gibt es die Möglichkeit ja nicht und nur die Metrik am jeweiligen Hop entscheidet über den weiteren Weg. <br>
Ist es dann nicht so, dass ein Hop auf dem Weg, wenn 2 Exit-Gateway s die gleiche hopCount haben, durchaus ein Paket zum Gateway 1 und das nächste u.U. zum Gateway2 schickt. Sowas macht natürlich dann TCP kaputt.<br>
Hab ich mir das richtig zusammengereimt?</p>
<p dir="ltr">Sven</p>
<p dir="ltr">Am 19. Januar 2021 10:11:14 MEZ schrieb ff@xayax.de:<br>
>Guten Tag,<br>
><br>
>es arbeiten ja gerade wieder einige engagierte Leute an der Firmware.<br>
>Vielleicht könnten wir dann mal ein „altes“ Problem angehen?<br>
>Ich fände es gut, wenn wir das Smartgateway entfernen würden. Es hat<br>
>m.E. keine Vorteile, dafür aber ein paar Nachteile. <br>
>Da nicht alle Exit-Gateways das Plugin aktiviert haben, wird teilweise<br>
>durch die ganze Stadt geroutet (siehe aktuell Sven Adlershof -><br>
>Friedrichshain) statt die nähere und stabilere Route (Adlershof -><br>
>Baume) zu nehmen. <br>
>Es gibt zwar eine Anleitung, wie das Smartgateway deaktiviert werden<br>
>kann:<br>
>https://wiki.freifunk-potsdam.de/KathleenZusatz#Smart_Gateway_abschalten<br>
><br>
>Aber ich habe irgendwie in Erinnerung, dass das auch nicht bei allen<br>
>funktioniert hat. <br>
><br>
>Also. Spricht irgend etwas dagegen, diese Funktionalität komplett (z.B.<br>
>im nächsten Release) zu enfternen? <br>
><br>
>lg<br>
>kaya<br>
>_______________________________________________<br>
>Berlin mailing list<br>
>Berlin@berlin.freifunk.net<br>
>http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
>Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
<p dir="ltr">_______________________________________________<br>
Berlin mailing list<br>
Berlin@berlin.freifunk.net<br>
http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
</blockquote></div><br></div></div><div><br><div class="elided-text">Am 21.01.2021 21:08 schrieb Sven Roederer <freifunk@it-solutions.geroedel.de>:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hallo,</p>
<p dir="ltr">Diesen "Problemball" hast du ja schon öfter Richtung Firmwareentwickler geworfen. Aber bisher hat ihn niemand so Recht fangen wollen...</p>
<p dir="ltr">Aber grundsätzlich hab ich aus Elektra's Kommentar vor ein paar Tagen, den Punkt mitgenommen, dass durch samrtgateway stabile TCP-Verbindungen möglich wären. Was durch den Einsatz des IPIP-Tunnels passiert. Bei nur Routing basierter Gatewayauswahl gibt es die Möglichkeit ja nicht und nur die Metrik am jeweiligen Hop entscheidet über den weiteren Weg. <br>
Ist es dann nicht so, dass ein Hop auf dem Weg, wenn 2 Exit-Gateway s die gleiche hopCount haben, durchaus ein Paket zum Gateway 1 und das nächste u.U. zum Gateway2 schickt. Sowas macht natürlich dann TCP kaputt.<br>
Hab ich mir das richtig zusammengereimt?</p>
<p dir="ltr">Sven</p>
<p dir="ltr">Am 19. Januar 2021 10:11:14 MEZ schrieb ff@xayax.de:<br>
>Guten Tag,<br>
><br>
>es arbeiten ja gerade wieder einige engagierte Leute an der Firmware.<br>
>Vielleicht könnten wir dann mal ein „altes“ Problem angehen?<br>
>Ich fände es gut, wenn wir das Smartgateway entfernen würden. Es hat<br>
>m.E. keine Vorteile, dafür aber ein paar Nachteile. <br>
>Da nicht alle Exit-Gateways das Plugin aktiviert haben, wird teilweise<br>
>durch die ganze Stadt geroutet (siehe aktuell Sven Adlershof -><br>
>Friedrichshain) statt die nähere und stabilere Route (Adlershof -><br>
>Baume) zu nehmen. <br>
>Es gibt zwar eine Anleitung, wie das Smartgateway deaktiviert werden<br>
>kann:<br>
>https://wiki.freifunk-potsdam.de/KathleenZusatz#Smart_Gateway_abschalten<br>
><br>
>Aber ich habe irgendwie in Erinnerung, dass das auch nicht bei allen<br>
>funktioniert hat. <br>
><br>
>Also. Spricht irgend etwas dagegen, diese Funktionalität komplett (z.B.<br>
>im nächsten Release) zu enfternen? <br>
><br>
>lg<br>
>kaya<br>
>_______________________________________________<br>
>Berlin mailing list<br>
>Berlin@berlin.freifunk.net<br>
>http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
>Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
<p dir="ltr">_______________________________________________<br>
Berlin mailing list<br>
Berlin@berlin.freifunk.net<br>
http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin<br>
Diese Mailingliste besitzt ein ffentlich einsehbares Archiv</p>
</blockquote></div><br></div></div>