[ASL] Re: packet forwarding in ASL

[Armen B. <ar...@cs...>]

Hi Vikas (and list),

Well, after trying to figure a way around it (writing a program to 
sniff the ethernet, and explicitly send the packets to the 
application),  I realized that both AODV-UIUC and arand had broadcast 
addresses of "255.255.255.255" hardcoded into the headers.  Presumably 
my Zaurus and my Debian laptop were expecting to receive packets 
destined to the IP address configured as my eth0's broadcast address, 
192.168.1.255.  Perhaps RedHat and Familiar have some scheme that 
determines that 255.255.255.255 is a broadcast address (like the dest 
mac address is FF:FF:FF:FF:FF:FF or something).

For now, I changed my eth0's broadcast address to 255.255.255.255 and 
everything works fine.  A good long-term solution for this is to figure 
out the broadcast address the broadcast address eth0 was configured 
with.

   - Armen

On Monday, May 19, 2003, at 04:04 PM, Armen Babikyan wrote:

> Hi Vikas,
>
> I've been attempting to use ASL with both AODV-UIUC and ARAND (the 
> ad-hoc routing daemon written by Dan LaFlamme here at UMass).  I've 
> been running into a couple problems and could use some insight.
>
> When my machine starts up, I configure my ethernet device with 
> 192.168.1.3/24, and I configure other nodes in my adhoc network to IPs 
> in this same network.
>
> When I want to run the routing daemon, I start by emptying my kernel 
> routing table (KRT).   This gets rid of the 192.168.1.0/24 over eth0 
> entry that is in my routing table.  Then I run aodvd (or arand, they 
> do essentially the same thing as far as I'm concerned).  The routing 
> daemon calls libASL functions that add the tun device as the default 
> route in the KRT, such as:
>
> Destination     Gateway         Genmask         Flags Metric Ref    
> Use Iface
> 0.0.0.0     0.0.0.0               0.0.0.0   U     0      0        0 tun
>
> This means that any locally generated packets will first get sent to 
> tun, to which the routing daemon is attached.  At that point, the 
> routing daemon will then do route discovery, and and insert host KRT 
> entries to other nodes on the network.
>
> I'm finding that with this configuration, *some* of my machines aren't 
> being able to get packets from the network (i.e. HELLO advertisements 
> by neighbors) when I don't have a 192.168.1.0 entry in my routing 
> table. In other words, when I have the 192.168.1.0 entry IN my table, 
> I can't talk to other people, and when I have 192.168.1.0 entry taken 
> OUT, I don't hear anything anyone else says.  The correct thing to do, 
> as far as I can tell, is to have the route to 192.168.1.0 taken out of 
> the KRT, so that the adhoc routing daemon can do all the route 
> discovery.
>
> I'm not sure if you've seen this problem before, but please tell me if 
> you have.  With the KRT to 192.168.1.0 removed, I (and Dan) have been 
> able to both send AND receive packets on 192.168.1.0/24 on a Compaq 
> Ipaq running Familiar and a Sony Vaio running RedHat 7.3 (i.e. 
> success), but we are not able to receive packets on a Laptop running 
> Debian or on a Sharp Zaurus running OpenZaurus 3.2.  We're baffled as 
> to why this isn't working.
>
> Is there some kind of configurable policy in linux that expects every 
> interface to have a network route in the KRT, and doesn't forward 
> packets from those interfaces to local running apps if it doesn't?  
> Because our goal is to have one network route to tun and lots and lots 
> of host routes on eth0.  But incoming packets (on eth0) from other 
> routing daemons are somehow not getting forwarded to the local routing 
> daemon when the 192.168.1.0 KRT entry is gone.
>
> If you know anyone else who may be working with this software (and may 
> have encountered similar problems), please let us (da...@cs... 
> and I) know.  We'd be very appreciative.
>
> Thanks,
>
>   - Armen
>