[OLSR-users] Question about address assignment

(spam-protected) (spam-protected)
Thu Apr 29 17:57:01 CEST 2004


Andreas,

I have been looking into the Linux kernel source in
kernel/net/ipv4/route.c and I think I know what is happening.

Recall that I have two Linux systems with IP addresses from
different subnets connected via a switch.  I configured olsrd
to use 255.255.255.255 as its broadcast address.

         Linux        Eth          Linux
        -------      switch       -------
        |     |      -----        |     |
        |  X  |______|   |________|  Y  |
        |     |      |   |        |     |
        -------      -----        -------

The code in route.c, the function ip_route_input_slow() checks
the destination address for 0xffffffff and jumps to the brd_input
label.  There it calls fib_validate_source() which returns an
error and the code jumps to the martian_source label.  The packet
is treated as a Martian packet and dropped because it did not come
from a source address with a known route.

Has anyone encountered this before?  Does anyone have suggestions
for dealing with this besides hacking the kernel?

Thanks,
Richard Herron
L-3 Communications


-----Original Message-----
From: Andreas Tønnesen [mailto:(spam-protected)]
Sent: Thursday, April 22, 2004 9:47 PM
To: (spam-protected)
Cc: (spam-protected)
Subject: Re: [OLSR-users] Question about address assignment


The UDP packets to 255.255.255.255 should be passed up the stack as far 
as I know... You are sure there's no netfilter rule stopping the 
traffic(iptables -F)?
I will check this out when I get back to the lab!

- Andreas

(spam-protected) wrote:
> Andreas,
> 
> I have modified my OLSR config file to set IP4BROAD to 
> 255.255.255.255 and I have attempted to run my systems with IP
> addresses from different subnets, but I am still having trouble.
> 
> I have attached traces from both systems showing the OLSRD debug
> and some tcpdump printouts.  The tcpdump shows that the Hello
> messages are being send and seen at the Ethernet interfaces
> of both machines, but the messages don't seem to be getting to
> the OLSR protocol.
> For example:
> 09:49:15.022709 192.168.97.11.698 > 255.255.255.255.698:  udp 20 (DF) [tos
> 0x10] 
> 09:49:21.000156 192.168.77.21.698 > 255.255.255.255.698:  udp 20 (DF) [tos
> 0x10] 
> 
> Could this be because the Linux network stack is filtering out
> messages that do not originate from the same subnet as the
> interface that receives them?
> 
> I would appreciate any ideas you have on this.
> 
> Thank you,
> Richard Herron
> L-3 Communications
> 
> 
> 
> -----Original Message-----
> From: Andreas Tønnesen [mailto:(spam-protected)]
> Sent: Wednesday, April 14, 2004 12:56 AM
> To: (spam-protected)
> Cc: (spam-protected)
> Subject: Re: [OLSR-users] Question about address assignment
> 
> 
> Hi,
> 
> You are not the first to ask this question ;-)
> 
> OLSR uses the broadcastaddresses that interfaces are pre-configured 
> with. So for two nodes to "hear" eachother they need to use the same 
> broadcast address which usually means that they must be on the same 
> subnet. This is both good and bad. Good in the sense that it allows for 
> subnet design within the manet - bad in the way that it is not very 
> "ad-hocish". By "ad-hocish" I mean the idea of nodes roaming freely 
> entering and exitting MANETS dynamically.
> 
> AODV specifies in the RFC that ALL control traffic should be broadcasted 
> on 255.255.255.255. When using this broadcast address ALL nodes will 
> pick up the traffic. OLSR on the other hand does not specify this. So I 
> figured it was best leave both options to the user. As a result you can 
> set the IP4BROAD option in the configfile to either auto, which will 
> cause OLSRd to use the broadcastaddress fetched from the interface(s), 
> or you can set it to 255.255.255.255 which causes all controltraffic to 
> be broadcasted on 255.255.255.255, meaning that the addresses of your 
> nodes does not have to reside within the same subnet.
> 
> I hope this answered your question
> 
> regards,
> Andreas T
> 
> (spam-protected) wrote:
> 
>>Greetings,
>>
>>The OLSR code seems to be well written and solid.  I have a question
>>about assignment of IP addresses and how addresses are handled by
>>the UniK OLSR daemon.
>>
>>I am running olsrd on Linux machines using an Ethernet interface
>>because I currently have no wireless devices.
>>
>>Section 11.1 of RFC 3626 says:
>>The nodes in the MANET network SHOULD be assigned addresses within a
>>defined address sequence, i.e., the nodes in the MANET SHOULD be
>>addressable through a network address and a netmask. 
>>
>>I understand that this is done to enable us to advertise routes
>>from the OLSR MANET into other routing domains, but that it is not
>>a requirement.  
>>
>>I also understand that generally in a MANET there are no requirements
>>as to how addresses are assigned and there may be nodes from different
>>"IP subnets" in the same MANET.
>>
>>I have the following setup:
>>
>>         Linux        Eth          Linux
>>        -------      switch       -------
>>        |     |      -----        |     |
>>        |  X  |______|   |________|  Y  |
>>        |     |      |   |        |     |
>>        -------      -----        -------
>>
>>When workstations X and Y are on the same IP subnet (192.168.77.0), 
>>OLSR works fine.  When they are on differing subnets (X = 192.168.87.0
>>Y = 192.168.97.0) OLSR doesn't work at all.
>>
>>Is this because of the way olsrd is implemented or is it due to the
>>way routing works on Linux, or is my understanding incorrect?
>>
>>Thanks for any help you can give.
>>
>>Richard Herron
>>L-3 Communications
>>
>>_______________________________________________
>>olsr-users mailing list
>>(spam-protected)
>>https://www.olsr.org/mailman/listinfo/olsr-users
> 
> 

-- 
Andreas Tønnesen((spam-protected))
UniK University Graduation Center
University of Oslo
http://www.olsr.org



More information about the Olsr-users mailing list