<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 11:46 AM, Sven-Ola Tuecke <span dir="ltr"><<a href="mailto:sven-ola@gmx.de">sven-ola@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey,<br>
<br>
the (new) rttable_tunnel parameter as well as the following defaults will<br>
break some features:<br>
<br>
#define DEF_RTTABLE_DEFAULT  112<br>
#define DEF_RTTABLE_TUNNEL   113<br>
<br>
Obviously, the tunnel-default-route should not be executed if olsrd sets a<br>
standard default route. I presume, the author has some "ip rules add" in mind<br>
otherwise it's useless...?<br></blockquote><div>olsrd can create a basic set of policy rules on its own,  but more complex will require manual configuration f the rules</div><div><br></div><div>maybe rules and tables dyn_gw needs can also be easily integrated in the "default" rules olsrd generates (when smartgateway is used)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Where I expect conflicts: at a given time only ONE default route will be used<br>
by a particular station/user. I use that rttable_default setting for users<br>
which will join the mesh but do not want to share their inet connection (aka.<br></blockquote><div>just put the default route for the user in a table at which a rule with prio < olsrd tables rule priorities that matches only "lan" interface (and in this case you could additianlly turn off smartgateway anyway as the users doesn need/want it)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
my-Internet-for-me-alone). He/she will (of course) not block inet traffic<br>
generated by others. As a second use case, there is the "dyn_gw_plain" stuff.<br>
Which (if the gateway is unusable) shifts the 254-default route in a<br>
background table only valid for the current device. </blockquote><div>which one? does it create/configure this table alone? (or does it require external configuration)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is necessary,<br>
otherwise you cannot determine if that gateway will come up again.<br></blockquote><div>in theory there are not much problems,..</div><div><br></div><div>it a default route is in maintable it will be found first (and if dyn_gw moves this route into some other table to make it used only locally it will work (as long as an mathing policy rule makes sure this other table is for local traffic only and inspected before the other olsrd tables))</div>
<div><br></div><div>imho the rtTable_default table ist used very exactly as the old one, and it has precedence to the smartgateway table for all traffic coming from olsr neighbours</div><div><br></div><div>only the local nodes traffic is put into its own tunnel</div>
<div><br></div><div>(above is only the case in the policyrouting mode of smartgateway, it can also put everthing into one table (which is not recommended (but there are some exceptions)))</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Can someone shed some light on this setting? (BTW: there will be no<br>
IPv6-ipip-tunnel without backporting some 2.6.x code to linux-2.4)<br></blockquote><div>the real problem of 2.4 + ipv6 is its lack of policy routing (and routing tables) (there's at least one insane workaround i know)</div>
<div><br></div><div>but in genreal on 2.4 kernels only ipv4 tunnels are reasonable/available (at the moment)</div><div><br></div><div>Markus</div><div><br></div><div>p.s. i think there will be some readme about this, (which henning wanted to write (maybe its already done?), but i found non in the repo) </div>
<div>at least there is a google wave document describing operation/specification of smartgateway </div><div><br></div><div>ask henning or me if u want to read this wave (as it might need changes for your use-cases)</div></div>