<div><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
<br><br>Maybe we can teach olsrd to send a "I'm switching off" packet before<br> it shuts down. This way the neighborhood has a chance to see the route<br> loss coming.</blockquote><div><br>a real packet special packet type, or just an hello with damn bad lq values ,..</div>
<blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
<br><br> > yes, but i thin i want two timeouts, one to drop any routes over this link,<br> > and one to clear all information about this link<br><br>As long as the "clear information" timer is shorter than the "drop<br>
 route" timer this should be no problem.</blockquote><div><br>i wanted it the other way round,..<br>do not use for routing fires earlier  (30 seconds after the last packet or earlier (4x hello interval)) (it may also stop hello timeouts, and further changes to the lq istory) <br>
much later (5 minutes or later) the history is deleted<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > because a 30 second dead link, shouldn`t be used for routing, but if it<br> > comes up after 35 seconds, the link sensing should still have<br> > enough information to be at least as skeptic as if the link was down for 20<br>
 > seconds,..<br><br>Which would be a problem for reboots.</blockquote><div><br>would be  no problem if the device announces its reboot,.. (stopping all neighbours from doing any further hello timeouts, modifing the history without receiving packets)<br>
<br>how long does an started olsr needs currently before he has routes, 30 seconds?<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
 > unidriectinoal or not was not my point, but a dead link`s etx drops slower<br> > than an 95% loss link, because its nlq is freezed, and i dislike this,..<br> > maybe it would be a good idea to lower the nlq with every hello timeout<br>
 > (only if no olsr packets from this node are received)<br> > the problem with this feature is, it just breaks anything, and creates loops<br> > for sure..<br> > (i will have to investigate a bit before writing any further on this point<br>
 > (-;)<br><br>At the moment we don't use any link for routing which LQ or NLQ<br> (neighbor linkquality) is below 0.1.</blockquote><div><br>ok fine (i did forget this), replace 95% with 80% and think over it again,.. <br>
but in fact its irrelevant that with 95% loss this link wouldn`t be used sometimes (when its lq is low enough)<br></div><br></div>what disturbs me ist that it will take substantially  more time for an dead link to drop from ETX 1.0 to an e.g  4.0 (LQ 0.25 NLQ 1.0) (at >= 4 for example  an alternative route would be used)<br>
than for an link with suddenly 85% loss, which can be nearly twice as fast (#), because NLQ will drop too, so with an LQ of 0.5 and nlq of 0.5 ETX 4.0 is reached<br><br># and maybe in relity more than twice as fast as it doesn`t have to wait on hello timeouts<br>