[OLSR-users] Question about address assignment
Andreas Tønnesen
(spam-protected)
Wed May 5 07:34:54 CEST 2004
Hi Richard,
I found the solution to your problem!
I remember dealing with the ingress filter of network interfaces when
working on a gateway tunneling solution for olsrd(it took me some time
to figure out...).
The trick is to disable the ingress filtering for the given device. this
is easily done trough the delightfull proc interface:
echo "0" > /proc/sys/net/ipv4/conf/eth0/rp_filter
to disable the ingress filter on eth0.
Now all 255.255.255.255 packets are forwarded up the stack and olsrd
works just fine for a scenario like yours.
Enjoy :-)
regards,
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