
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">OK: if we patch, there must be a fall-back.<div>I opt for default TTL=1, and per interface configuration.</div><div><br></div><div>Teco</div><div><br><div><div>Op 19 jan 2011, om 22:01 heeft Markus Kittenberger het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Jan 19, 2011 at 3:21 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl">teco@inf-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>

Op 19 jan 2011, om 14:56 heeft Henning Rogge het volgende geschreven:<br>

<div class="im">>> The IP TTL value of OLSR packets is 64, a OS default value.<br>

>> Mostly, this is OK. But IMHO it should be set to 1.<br>

>> OK to patch it?<br>

>> Need for a config parameter?<br>

> I don't see a reason for this, it just might make trouble with tunneling OLSR<br>

> links.<br>

</div>TTL=1 should work on tunnels.<br></blockquote><div> </div><div>only if the tunneled packets do not inherit ttl from their payload,..</div><div><br></div><div>which as example is the default behaviour for ipip tunnels on 2.4 kernels,..</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

All IGPs I am aware of work on tunnels, or use some kind of multi-hop unicast signaling channel.<br>

<div class="im"><br>

><br>

> OLSR packets are broadcast/multicast, so they are not forwarded anyways.<br>

</div>Not true if one sets the address with strange value.<br>

Redirected broadcasts could have bad effects (e.g. 172.16.10.255).<br></blockquote><div><br></div><div>hmm, what about having an optional ttl configuration option?</div><div><br></div><div>Markus</div></div>

</blockquote></div><br></div></body></html>