[Olsr-dev] Removing default route after program termination

Sven-Ola Tuecke (spam-protected)
Wed Oct 10 16:07:06 CEST 2007


Hi,

oops!? If BSD/MacOS does not handle 2 default routes, this should be really 
fixed. Wondering why nobody notices until now. OK - there are two scenarios:

1) The BSD station *is* the inet gateway. Then olsrd should not insert an 
other default route. But rather announce the local one via HNA 0/0 (e.g. via 
dyngwplain).

2) The BSD station uses a mesh gateway. In this case, the local & static 
default route is unwanted and needs to be removed (and maybe restored after 
olsrd termination). No HNA 0/0 annoucement either.

We can deciced by examing the HNA 0/0 situation. If the BSD announces HNA 
0/0 (either by manual config entry or by dyngw/dyngwplain, it's scenario 1). 
Otherwise 2).

Comments?
// Sven-Ola

"Bernd Petrovitsch" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> On Mit, 2007-10-10 at 12:59 +0200, Mitar wrote:
> [...]
>> Checked on 0.5.2 and current CVS version.
>>
>> On a Mac OS X 10.4.10 computer with static default route (to the
>> Internet) OLSR program after termination cleans default route. It
>> should clean only HNA announced default route.
>>
>> After some investigation I found that on Mac OS X it is possible to
>> have only one default route active in a routing table at a given
>> moment. You can declare other default routes but you also declare
>> policy on which OS would change this default route to a prepared one.
>
> The usual situations are:
> - the mesh net is your only link to the rest of the world.
>  Then you usally have no problem.
> - You have another connection to the rest of the world and also
>  use OLSRD for mesh routes.
>  I have this since ages at home where the normal default route
>  goes via a cable provider and OLSRD adds a second one with a higher
>  metric (routing over an openvpn tunnel).
>  And here you normally have a metric larger than the existing default
>  route.
> Yes, I'm aware of the (possibly non-trivial) implications of this setup.
> And if the tunnel works again, everything should work flawlessly
> (especially since Sven-Ola added the support of a separate routing table
> for olsrd-managed routes).
>
> Short: I had (on a stock Linux kernel) no problems with > 1 default
> route.
>
> Perhaps it's enough to read the default route at startup, delete it and
> set it at the end again (and all changes are #ifdef-ed aout - only for
> MacOS).
> BTW there were reports (also with the default route IIRC) about issues
> on suspend/resume.
>
>> Thus adding other (HNA announced) default routes is not really working
>> as expected in OLSR and this becomes obvious when cleaning them (or
>> more properly, it).
>>
>> As I understood there is no developer working on Mac OS X hardware? I
>
> Aaron is now and then at least compiling on MacOS (but don't ask me for
> the version) - and sends bug reports of problem with (usually)
> non-GNU tools.
>
>> could try to fix this but I would need some guidance.
>
> Bernd
> -- 
> Firmix Software GmbH                   http://www.firmix.at/
> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>          Embedded Linux Development and Services
>
>
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev 





More information about the Olsr-dev mailing list