[Olsr-dev] OLSR IPs for node with multiple interfaces

[Axel Neumann]

On Mittwoch 30 April 2008, Bernd Petrovitsch wrote:
> On Mit, 2008-04-30 at 14:11 +0200, Henning Rogge wrote:
> > Am Mittwoch 30 April 2008 13:36:45 schrieben Sie:
>
> [...]
>
> > > Am Mittwoch 30 April 2008 13:07:16 schrieb Axel Neumann:
> > > > For older olsrd versions there has been the "recommendation" to
> > > > always use a different netmask for each olsr interface of a node.
>
> Are you sure? I can't remember such a thing (or anything in that
> direction).

I guess my information is mostly based on gossip. Thats why I am trying to 
clarify now. There was at least a reply to a similar question on this mailing 
list last year:
http://lists.olsr.org/pipermail/olsr-dev/2007-September/001280.html

I understood the response as: better dont do it!

>
> In the cable world, both interfaces may be in the same broadcast domain
> (e.g. connected to the same switch, no VLANs or similar).
> Thus the above should work with any (reasonable) OS/device/IP-Stack.
>
> > The kernel has a packet which has to be transfered to a node called
> > 10.0.0.3. How should the kernel determine what interface is to use ?
>
> The kernel can use either one as there are routes etc.
>
> What am I missing in this thread (apart from the fact that I ignored the
> WLAN part and aspects. But from a pure layer 3 point of view, it should
> work)?

This is the point. In a Wireless world, the kernel can not use either one 
because only one of the two wireless ad-hoc interfaces may have a proper 
working link.

I think SO_BINDTODEVICE can be used to identify whether an olsr-hello message 
broadcasted to 10.255.255.255 has been received via the one or the other 
wireless interface. And considering this information, the daemon may 
configure a host route pointing to the correct neighbor *via* the correct 
interface. 

/axel





>
> 	Bernd
> --
> Firmix Software GmbH                   http://www.firmix.at/
> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>           Embedded Linux Development and Services