Menu
▾
▴
Re: [ASL] Re: packet forwarding in ASL
|
From: Vikas K. <ka...@co...> - 2003-05-20 04:54:13
|
Yes, the routing daemons not hardcoding the broadcast address is a more general solution. The ASL route_add() also does not let you set the genmask for the default tun route. I'll take note of this for the next revision. Typically though in an adhoc network, each node is a separate subnet of its own. So a subnet mask of all 1's and the broadcast address = the ip address, seems to me the most natural configuration. -vikas On Mon, 19 May 2003, Armen Babikyan wrote: ->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 ->> -> -> -> ->------------------------------------------------------- ->This SF.net email is sponsored by: ObjectStore. ->If flattening out C++ or Java code to make your application fit in a ->relational database is painful, don't do it! Check out ObjectStore. ->Now part of Progress Software. http://www.objectstore.net/sourceforge ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> -- |
