[OLSR-users] Question about address assignment
Andreas Tønnesen
(spam-protected)
Tue May 4 05:33:29 CEST 2004
Richard,
Are you sure it won't work if you add a default route on all interfaces
running OLSR? Didnt the routing code just check for a valid route
to the sender address?
But then again - you have probably tested that :)
But this whole thing sounds like a horrible hack... One should at least
put a maximum metric on these routes.
As I am currently in the process of writing my thesis(ahh... the
documentation - always the documentation) and preparing for a exam -
sadly I don't hve to much time for hacking.
Anybody else got any ideas?
(please keep us updated on what solution you go for)
- Andreas
(spam-protected) wrote:
> Andreas,
>
> I found that by adding a default route pointing to the my interface I could
> get OLSR to work.
>
> On Friday I started looking at the AODV code from Uppsala University. I
> recall
> that you mentioned AODV uses 255.255.255.255 for its protocol messages. I
> found
> this statement in the AODV implementation README file:
>
> -----
> On the ad hoc nodes it is also necessary to add a default route in the
> kernel routing table, pointing to the ad hoc interface. For example, if
> the wireless ad hoc interface is eth1:
>
>
>>route add default dev eth1
>
>
> Otherwise, it will not be possible to communicate with destinations
> outside the ad hoc prefix.
> -----
>
> Apparently they have experienced the same problem as me.
>
> My problem, however, is more complex. My application requires that I run
> the
> MANET protocol on multiple interfaces. The trick of adding a default
> route will only work for one interface. The only solution I can see is to
> hack the kernel to allow Martian packets containing OLSR (or AODV) protocol
> packets.
>
> Any better ideas?
>
> Thanks,
> Richard Herron
> L-3 Communications
>
>
>
> -----Original Message-----
> From: Andreas Tønnesen [mailto:(spam-protected)]
> Sent: Thursday, April 29, 2004 10:22 AM
> To: (spam-protected)
> Cc: (spam-protected)
> Subject: Re: [OLSR-users] Question about address assignment
>
>
> 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