<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-27 11:39 GMT+02:00 Josef Semler <span dir="ltr"><<a href="mailto:josef.semler@gmail.com" target="_blank">josef.semler@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Liebe Community,<div lang="de-DE">in den aktuellen Backfire Vienna und 0xFF-Bubbles 2014 Versionen befindet sich ein kleiner Konfigurationsfehler, der <b>bei asymmetrischen Routen zu einem Verbindungsabbruch</b> führt!</div>
<div lang="de-DE"><br></div><div lang="de-DE">Ich bitte euch daher, eure Konfiguration zu kontrollieren und gegebenenfalls zu korrigieren.</div></div></blockquote><div><br></div>Weiters bitte ich Alle die bis jetzt in gewisserweise versuchten mit lqmults dem olsrd assymetrisches Routen abzugewöhnen, die Verwendung der lqmults mittelfristig wieder auf ein Minimum zu beschränken. #1<div>
<br></div><div><div>Also eben lqmults nur zum korrigieren von Funklinks welche wirklich falsch bewertet werden #5, und nicht um permanent Routen bzw. Nodes "loszuwerden" welche eben fehlerhaft konfiguriert waren/sind. #7 (#6)</div>
<div><br></div><div>Aja den an mehr Details (zu dem Konfigurationsfehler und dessen Auswirkungen) Intressierten viel spass mit folgenden dem Fussnotenlabyrinth (-;<br></div><div><br></div><div>lg Markus</div><div><br></div>
<div>#1 Denn vermutlich wird wohl in den letzen Monaten/Jahren ein grosser Anteil der Strecken/Nachbarn welche "scheinbar" nie verlässlich funktionierten eigentlich "nur" an der Firewall #8 eines oder mehrer involvierter Router gescheitert sein.</div>
<div>Auch die oft beschriebenen Probleme bei mehreren gleich guten Routen #4, also die teils schon ziemlich verschriehenen flappenden Routen, lagen wohl hauptsächlich daran dass in solchen Fällen olsrd eben immerwiedermal sekundenweise assymetreisch routet, oder aber auch permanent #2</div>
<div><br></div><div>siehe auch #7</div><div><br></div><div>#2 z.b. Falls die beiden Alternativrouten zu unterschiedlichen Roofnodes (krypta,nix,tunnelserver) führen.<br></div></div><div>Oder auch da ja auf manchen Routern bei noch das bei uns unnötige/kontraproduktive nat-treshold konfiguriert ist.<br>
</div><div><br></div><div>#3 siehe: #1 (-;</div><div><br></div><div>#4 also bzgl. der Summe aller ETX Werte</div><div><br></div><div><div>#5 Und davon gibts bei ETX metrik leider eh genug</div><div><br></div></div><div>#6 <obergscheit>Denn bei fast allen lqmults gehört der nicht funktionierende Link/Node zumindest mittelfristig debugged und repariert, oder zumindest der besitzer/techC (und falls die unintressiert/"überfordert" eben andere) darauf aufmerksam gemacht</obergescheit></div>
<div><br></div><div><div>#7 Aja ein einziger Router mit drop_invalid=1 auf dem assymterischen Teil seiner Route nach X reicht das auf der Route für seine eigene IP "nichts mehr nach/von X geht", während aber der traffic von/zu IPs (sofern symmetrisch) problemlos auf diesen Routen geroutet wird/wurde.</div>
<div><br></div><div>U.a. darum sind lqmults als "Lösung" für dieses Problem ja noch unpassender als sonst *G #6<br></div></div><div><br></div><div>#8 im konkreten geht es um ca. derartig gelagerte firewall rules #9 in der FORWARD chain, in der die dritte rule jeglichen traffic den das connection tracking nicht versteht #10 dropped (cstate INVALID), bevor überhaupt die Ausnahmen für 0xff interfaces (in dem Beispiel eth0 und wlan0) geifen konnten.</div>
<div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">iptables -nvL delegate_forward</div><div style="font-family:arial,sans-serif;font-size:13px">Chain delegate_forward (1 references)</div><div style="font-family:arial,sans-serif;font-size:13px">
pkts bytes target prot opt in out source destination </div><div style="font-family:arial,sans-serif;font-size:13px"> 4704 1202K forwarding_rule all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> /* user chain for forwarding */ # -> allerdings ist die chain idr leer.</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 3392 1049K ACCEPT all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> ctstate RELATED,ESTABLISHED</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 78 6176 DROP all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> ctstate INVALID # -> verwirft eben auch assymetrischen 0xff-transit-traffic ! *G</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 209 18990 zone_0xFF_forward all -- eth0 * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> # -> hier ist nun schon zu spät für 0xff-transit spezifische Ausnahmen!</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 1025 128K zone_0xFF_forward all -- wlan0 * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> # --,,--</div>
<div style="font-family:arial,sans-serif;font-size:13px"> 0 0 reject all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> </div>
</div><div><br></div><div>#9 Der auszug ist aus ner neueren naked.bubble, aber auch viele backfire-vienna Versionen #11 sind betroffen, auch wenn die chains dort eben noch anders heissen.</div><div><br></div><div>#10 bzw eben nicht verstehen konnte weil es aufgrund von assymetrischen routing nur eine richtung zu sehen bekommt</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">#11 d.h. vmtl. alle die eben eine drop_invalid firewall option haben (die nun also auf 0 gestellt gehört!)</div><div class="gmail_extra"><snip file=/etc/config/firewall></div>
<div class="gmail_extra"><div class="gmail_extra">config defaults </div><div class="gmail_extra"> option syn_flood '1'</div><div class="gmail_extra"> option output 'ACCEPT'</div><div class="gmail_extra">
option drop_invalid '1' </div><div class="gmail_extra"> option input 'ACCEPT'</div><div class="gmail_extra"> option forward 'REJECT'</div></div><div class="gmail_extra"></snip></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">p.s. Ein Danke auch noch an Erich Pekarek sowie eben Akku und Franz Lax die eben unlängst gleichzeitig genug Probleme (an komplett anderen Stellen im Netz) hatten, so dass nun mal endlich der Zusammenhang auffiel.</div>
</div></div></div>