[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