[OLSR-users] Question about address assignment
Andreas Tønnesen
(spam-protected)
Thu Apr 29 18:21:51 CEST 2004
Hi Richard,
you are ever so right!
On all my tests I have had routes to the networks trough other
interfaces. That must have been why the packets have been sent
up the layers. Sorry about that :)
I'll look more into it tomorrow.
- Andreas
(spam-protected) wrote:
> 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