Hi,<br>
<br>
Here are some more observations. <br>
<br>
In the network, the OLSR (on Node1) seems to behave correctly by
advertising to Node2 that you cannot reach the internet via Node1
anymore. Doing a 'route -n' on Node2 shows that it Node1's IP addres
HAS been removed.<br>
<br>
Now the confusion is, if Node1 informs Node2 of it (Node1) not being a
route to internet anymore, why does it not remove its own default
internet route???? Pings, traceroutes, linkstates, interface-states,
seriously I dont think really matters. One can use whatever parameter
they want. Just make sure the damn route does not exist in Node1 when
it finds out that its own WAN interface cannot be used to reach the
internet.<br>
<br>
Some suggestions:<br>
1. If using pings/traceroutes ensure that the packets are sent over the
WAN interface of that node and if it fails then take appropriate action
(delete it as the route in case pings or traceroute fails, keep it or
add it if it succeeds)<br>
2. Link/Interface state (probably means the same thing) should also be
used, as its an internally generated event and OLSR can be notified
immediately. Take similar actions as above of deleting or adding the
route appropriately.<br>
<br>
So IMHO, the behavior SHOULD be the above stated behaviour, because
thats what routers do, else its not acting like a router anymore.<br>
<br>
Thanks,<br>
Rajesh.<br><div><span class="gmail_quote">On 1/10/07, <b class="gmail_sendername">Sven-Ola Tuecke</b> <<a href="mailto:mail2news@commando.de">mail2news@commando.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Andreas, <a href="http://et.al">et.al</a>.,<br><br>the [ping,traceroute] test needs to be carefully designed. For this reason,<br>freifunk firmware uses policy routing and a very downstripped version of<br>dyngw named "dyngwplain" (no ping test in the plugin itself, it announces
<br>HNA if default route is in the system standard routing table) as well as a<br>cronjob for this:<br><br>- traceroute to root nameservers every minute (limited by N hops)<br>- if fail, remove standard default route (hence remove hna4)
<br>- add old default route to policy routing table "only this device"<br>- continue tracerouting (over the local-iface-defroute)<br>- if connection comes up, restore def route which restores HNA<br><br>One drawback: During outage, the device itself has no connectivity via the
<br>OLSR fallback default route. Needs more policy routing tricks if that should<br>be the case. But of course the [win|mac|lin] PC behind that box will<br>function via both defroutes...<br><br>Using busybox traceroute has the advantage, that a gateway needs to
<br>transport UDP in order to succeed the test. UDP is blocked often due to<br>braindead firewalls / users / settings. I do not call a TCP-only gw an<br>internet gateway - I personally would never accept if any telco blocks this
<br>kind of signalling. Of course ping/icmp is an alternative test (if no UDP),<br>but you need reliable ping peers for that.<br><br>// Sven-Ola<br><br>"Andreas "Tønnesen"" <<a href="mailto:andreto@olsr.org">
andreto@olsr.org</a>> schrieb im Newsbeitrag<br>news:44078.194.196.35.3.1168422504.squirrel@webmail.olsr.org...<br>><br>> Ok, it's been a long time since I've looked at the dyn-gw plugin so I<br>> might be wrong here. But isn't the whole point with the pinging to
<br>> determine if the Internet connection has gone bad? Now if you remove the<br>> route and the pings go via the OLSR network then the node will belive that<br>> it has an Internet connection and therefore will start announcing it
<br>> again. AFAIK the GWs should be dedicated GWs that will loose Internet<br>> connectivity if their uplink goes down. They should not be boxes that<br>> depend on Internet connectivity via the OLSR network.<br>
><br>> So IMO the current behavior is the "correct" one as long as the ping is<br>> routed normally by the IP-stack. I guess one alternative could be to set<br>> up host routes to the pinged hosts...
<br>><br>> - Andreas<br>><br>>> More things to add. I am trying:<br>>> Pings to <a href="http://Google.com">Google.com</a> from Node1 -- This works with Internet A up and<br>>> running.<br>>> Pings to
<a href="http://Google.com">Google.com</a> from Node1 -- FAILS when I remove the link to<br>>> InternetA.<br>>><br>>> I would assume it should hop via Node2 and hit <a href="http://google.com">google.com
</a> via InternetB.<br>>><br>>> Problem is that since Node1 still has InternetA as its default route<br>>> (even<br>>> though it has Node2 as another route), it tries to send all the pings via<br>>> the default route.
<br>>><br>>> What I (and Drew) have contend is that even this route should be removed<br>>> from the local route table preserving only the route via Node2. This I<br>>> proved by manually deleting the default route on Node1 via InternetA,
<br>>> Pings<br>>> go through immediately!<br>>><br>>> Thanks,<br>>> Rajesh.<br>>><br>>> On 1/9/07, Rajesh Narayanan <<a href="mailto:nrajesh71@gmail.com">nrajesh71@gmail.com</a>
> wrote:<br>>>><br>>>> Hi,<br>>>><br>>>> Looks like we might be on to a bug here in the olsr dyn-gw. Yes, my<br>>>> opinion is the same as yours. The default route should be removed if the
<br>>>> pings do not go through that route. Then I am sure it will behave<br>>>> correctly.<br>>>><br>>>><br>>>> For clarification to everyone regarding my setup.<br>>>> Node1 and 2 : Linksys WRT54G routers running the OpenWrt , WhiteRussian,
<br>>>> Release RC4<br>>>> OLSR: compiled for RC4.<br>>>><br>>>> For sake of simplicity please ignore the LaptopsA and B. My apologies<br>>>> its<br>>>> just confusing it. The laptops are being used mainly for accessing the
<br>>>> Linksys routers console via SSH.<br>>>><br>>>> Thanks,<br>>>> Rajesh.<br>>>><br>>>><br>>>> On 1/9/07, Drew <<a href="mailto:drew@alamedawireless.org">
drew@alamedawireless.org</a>> wrote:<br>>>> ><br>>>> > I've asked basically the same thing before, and never got a reply:<br>>>> > <a href="http://www.olsr.org/pipermail/olsr-users/2006-October/646474.html">
http://www.olsr.org/pipermail/olsr-users/2006-October/646474.html</a><br>>>> ><br>>>> > Good luck,<br>>>> > Drew<br>>>> ><br>>>> > Rajesh Narayanan wrote:<br>>>> > > Hi,
<br>>>> > ><br>>>> > ><br>>>>
>
> * *
* *<br>>>> >
> | | | |<br>>>> > > InternetA--------->Node1 <-(OLSR)-> Node2---------->InternetB<br>>>>
>
> ^ ^<br>>>>
>
> |
|<br>>>> >
> |
|<br>>>> >
> Wired
link laptop A Wired link
laptop B<br>>>> >
>
(HNA4) (HNA4)<br>>>> > ><br>>>> > ><br>>>> > > I got the dyn gw plugin up and running and configured as suggested.<br>>>> > > Well the problem is that :
<br>>>> > > * Assume I remove the link the InternetA (cable disconnect to<br>>>> simulate<br>>>> > > link failure)<br>>>> > > * Node 2 gets notified that a route does not exist to the internet
<br>>>> > anymore<br>>>> > > * But the Route to internetA still remains in Node 1!!!<br>>>> > > * Node1 tries to route the pings (to <a href="http://google.com">google.com</a> <
<a href="http://google.com">http://google.com</a>>)<br>>>> > > via this interface since its the default route<br>>>> > > * As the default route does not get removed (due to link failure)<br>
>>> the<br>>>> > > OLSR link is not chosen.<br>>>> > > * If I manually remove the default route, only then the Node1<br>>>> forwards<br>>>> > > the pings via Node2 and out.
<br>>>> > ><br>>>> > > What am I doing wrong? Any other config issues I need to look at??<br>>>> > ><br>>>> > > Thanks,<br>>>> > > Rajesh<br>>>> >
<br>>>> ><br>>>><br>>> _______________________________________________<br>>> olsr-users mailing list<br>>> <a href="mailto:olsr-users@olsr.org">olsr-users@olsr.org</a><br>>> <a href="https://www.olsr.org/mailman/listinfo/olsr-users">
https://www.olsr.org/mailman/listinfo/olsr-users</a><br>>><br>><br>><br>><br>> _______________________________________________<br>> olsr-users mailing list<br>> <a href="mailto:olsr-users@olsr.org">
olsr-users@olsr.org</a><br>> <a href="https://www.olsr.org/mailman/listinfo/olsr-users">https://www.olsr.org/mailman/listinfo/olsr-users</a><br><br><br>_______________________________________________<br>olsr-users mailing list
<br><a href="mailto:olsr-users@olsr.org">olsr-users@olsr.org</a><br><a href="https://www.olsr.org/mailman/listinfo/olsr-users">https://www.olsr.org/mailman/listinfo/olsr-users</a><br></blockquote></div><br>