<br><div class="gmail_quote">2012/6/20 Erich N. Pekarek <span dir="ltr"><<a href="mailto:erich@pekarek.at" target="_blank">erich@pekarek.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hallo Markus!<br>
<br>
Am 2012-06-20 08:47, schrieb Markus Kittenberger:<br>
...<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
sry joe, aber imho das einzig "stabile" fuer linksys/buffalo ist leider immer noch "meine" firmware.<br>
<br>
</blockquote></div>
Apropos "stabil":</blockquote><div>also ich wollte echt keine was ist stabil diskussion lostreten (und btw. ich würde sie definitv gewinnen *GGG)</div><div>(somit kommen nun sicher keine öffentlichen aufzählungen von mir was alles in backfire fehlt/falsch/diskussionswürdig ist)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Gibt es das, dass ein Buffalo mit 1.7.4-11-Markit Firmware sich komplett verabschiedet, wenn man eine LQ zu einem Nachbarn auf - 2.0 setzt (nach Anweisung der Mouse-over-Hilfe)? </blockquote>
<div>hmm OMG wohl tatsächlich ein bug in der mouse-over hilfe,.. (-; <br>(ist nun ausgebessert, aber kein neues image deswegen gemacht)<br><br></div><div>früher mal ging es solche werte zu setzen, darum wohl auch dieser schwachsinnige hilfetext, (der mir nie untergekommen ist,..)</div>
<div>allerdings solche lqmults waren ansich schon immer falsch, auch wenn früher die konsequenzen von werten > 1.0 nur defiziler zu bemerken waren.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Auch mittels händischer Routen am Nachbar-Gerät via Kabel (via WAN) nicht mehr ansprechbar).<br></blockquote><div>also das liegt dann wohl eher an den "händischen" routen, (oder dem verständnis ihres wirken)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    1. Wieso geht das überhaupt, wenn die Werte 0-1 betragen sollten?<br></blockquote><div>(weil das gui sich auf untriges prozedere verlässt, und die werte kaum direkt prüft,..) <br><br></div><div>auch werte kleiner 0.1 (oder je nach link auch schon bei höheren werten) sind kritisch, <br>
aber ein gui könnte ohne gegenfragen (und analyse der aktuellen lq, und deren schwankungsbreite) in dem fall nit wissen ob der user das wirklich will.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

    2. Löscht OLSR den gesamten Routingtable, auch, wenn es selbst gar nicht starten kann?</blockquote><div>jein,<br>der olsrd löscht alle seine eigenen routen wenn er sich beendet,.. (was er bei solchen aenderungen wird)</div>
<div>weil er mit neuen configfile wieder gestartet wird,..</div><div><br></div><div>und würde er, mit diesen Änderungen dann nicht mehr starten, würden die änderungen automatisch zurueckgenommen, und die alten wieder gesetzt.</div>
<div><br></div><div>allerdings fürchte ich das sich der oslrd wohl mit ungültigen lqmults starten lässt,<br>aber dann eben trotzdem keine nachbarn mehr hat,..<br><br>womit die failsafe logik der olsrd settings dieser firmware zwar gut, aber klarerweise nit 100% fool-proof ist.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Wenn ja, warum repariert es die Standardrouten dann nicht vor dem Beenden des Start-Skripterls?<br></blockquote>
<div>welche standardrouten? welches startscript?</div><div><br></div><div>und ne antwort auf verdacht (falls oslrd startscript):</div><div>also der olsrd löscht "niemals" fremde routen, nur die eigenen, insofern gibt es nichts zu reparieren.</div>
<div><br></div><div>lg Markus </div></div>