Menu
▾
▴
aslib-users — Public list for users of ASL
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(7) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(4) |
Apr
(11) |
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dhaval M. <dha...@ya...> - 2004-03-27 19:28:09
|
Hi all, I am facing the same problem as what Armen was facing in the post "AODV-UIUC manual?". Armen, were you able to figure out the cause? Also, do you guys know if route_check.o now works with kernels > 2.4.19? Or do we still need to use 2.4.18? Thanks in advance, Dhaval --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. |
|
From: Vikas K. <ka...@co...> - 2004-03-12 20:01:57
|
This is happening probably becuase the file netfilter_ipv4.h header file has changed over kernl versions. If you notice in the make file below I include -I/lib/modules/`uname-r`/build/include/ the header files from the source of the currently running kernel. So make sure you are booted on the kernel version you want to compile for. If that does not work, make /usr/include/linux a symlink to /usr/include/linux-2.4.18/include/linux -vikas PS: Please subscribe to the mailing list on http://aslib.sourceforege.net and post the questions there, so that other people who know might answer. On Fri, 12 Mar 2004, Mukund Gopalan wrote: ->Hi, -> After loading 2.4.18 we got the following error when we tried to make ->route_check. -> ->BTW we have 2.4.18 along with 2.4.18-14, 2.4.18-3 and 2.4.20-8 in the ->system. Will the fact that there are multiple versions running, affect the ->working of the library? -> ->-Mukund -> -> ->gcc -O3 -Wall -DMODULE -D__KERNEL__ -DLINUX -I/lib/modules/`uname ->-r`/build/include/ -c module_main.c -o module_main.o ->module_main.c: In function `init_module': ->module_main.c:44: invalid use of undefined type `struct nf_hook_ops' ->module_main.c:45: invalid use of undefined type `struct nf_hook_ops' ->module_main.c:46: invalid use of undefined type `struct nf_hook_ops' ->module_main.c:47: invalid use of undefined type `struct nf_hook_ops' ->module_main.c:48: invalid use of undefined type `struct nf_hook_ops' ->module_main.c:51: warning: implicit declaration of function ->`nf_register_hook' ->module_main.c: In function `cleanup_module': ->module_main.c:110: warning: implicit declaration of function ->`nf_unregister_hook' ->module_main.c: At top level: ->module_main.c:24: storage size of `input_filter' isn't known ->module_main.c:25: storage size of `output_filter' isn't known ->make: *** [module_main.o] Error 1 -> -> -> -> -> -> -> -> -> -> -- |
|
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 -> -- |
|
From: Armen B. <ar...@cs...> - 2003-05-19 22:04:54
|
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 > |
|
From: Armen B. <ar...@st...> - 2003-05-10 01:17:36
|
Hi, This question is really pertaining to AODV-UIUC, not specifically ASL. Is there a manual, troubleshooting guide, or any other documentation for the AODV-UIUC daemon on the ASL homepage? Specifically, I am getting two "Error in select" messages once per second on my screen after running the AODV daemon. I do not see any packets (AODV or otherwise) being sent on my local network. Is the "Error in select" message supposed to appear? Are there any other configuration parameters I should be aware of to get AODV-UIUC working? Any and all help is appreciated. Thanks! - Armen |
|
From: Vikas K. <ka...@co...> - 2003-05-08 16:29:29
|
On Thu, 8 May 2003, Dan LaFlamme wrote: ->Vikas, -> ->Excellent. I was having the same problems as well when I was writing an ad ->hoc routing daemon with the ASL. If you track down the problem in ->route_check.o and need someone to test it with different kernel versions, ->I'd be happy to. Just let me know, but wait till after finals. :) -> ->BTW, I don't know if I posted this to the list, but arand is a routing ->daemon utilizing ASL. You can get more information and download it at: -> ->http://signl.cs.umass.edu/arand I have put a link to ARAN from the ASL page. I would be glad to add links to other projects too, so please let me know. thanks -vikas -> -> ->--Dan -> -> ->----- Original Message ----- ->From: "Vikas Kawadia" <ka...@co...> ->To: <asl...@li...> ->Sent: Thursday, May 08, 2003 1:21 AM ->Subject: [ASL] route_check.o problems -> -> ->> ->> Hi all, ->> Recently some people have had problem with the route_check.o ->> module. The kernel panics upon insertion of the module. I have figured ->> that it happens with kernel version 2.4.19 onwards. 2.4.18 and before work ->> fine. ->> ->> I will investigate the problem at the earliest opportunity, Until then ->> please use 2.4.18. ->> ->> Thanks ->> -vikas ->> ->> ->> ->> ------------------------------------------------------- ->> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara ->> The only event dedicated to issues related to Linux enterprise solutions ->> www.enterpriselinuxforum.com ->> ->> _______________________________________________ ->> aslib-users mailing list ->> asl...@li... ->> https://lists.sourceforge.net/lists/listinfo/aslib-users ->> -> -> -> ->------------------------------------------------------- ->Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara ->The only event dedicated to issues related to Linux enterprise solutions ->www.enterpriselinuxforum.com -> ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> -- |
|
From: Dan L. <da...@st...> - 2003-05-08 14:18:42
|
Vikas, Excellent. I was having the same problems as well when I was writing an ad hoc routing daemon with the ASL. If you track down the problem in route_check.o and need someone to test it with different kernel versions, I'd be happy to. Just let me know, but wait till after finals. :) BTW, I don't know if I posted this to the list, but arand is a routing daemon utilizing ASL. You can get more information and download it at: http://signl.cs.umass.edu/arand --Dan ----- Original Message ----- From: "Vikas Kawadia" <ka...@co...> To: <asl...@li...> Sent: Thursday, May 08, 2003 1:21 AM Subject: [ASL] route_check.o problems > > Hi all, > Recently some people have had problem with the route_check.o > module. The kernel panics upon insertion of the module. I have figured > that it happens with kernel version 2.4.19 onwards. 2.4.18 and before work > fine. > > I will investigate the problem at the earliest opportunity, Until then > please use 2.4.18. > > Thanks > -vikas > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > aslib-users mailing list > asl...@li... > https://lists.sourceforge.net/lists/listinfo/aslib-users > |
|
From: Vikas K. <ka...@co...> - 2003-05-08 05:21:16
|
Hi all, Recently some people have had problem with the route_check.o module. The kernel panics upon insertion of the module. I have figured that it happens with kernel version 2.4.19 onwards. 2.4.18 and before work fine. I will investigate the problem at the earliest opportunity, Until then please use 2.4.18. Thanks -vikas |
|
From: Vikas K. <ka...@co...> - 2003-02-27 21:41:40
|
Hi Madhup, To run ASL, you will need netfilter installed on the ipaq also beacuse the modules are inserted into the kernel at run time. Bu the compilation should succeed anyways. May be you can try compiling on the skiff cluster, so that you dont have to cross compile. I remember Dan <da...@st...> was able to run AODV-UIUC on ipaqs. So its definitely possible. -vikas On Tue, 25 Feb 2003, madhup misra wrote: ->I got the UIUC AODV implementation from ->sourceforge.net.I want to compile it for an IPAQ(arm) ->using a cross compiler(arm-linux 2.95.2). ->When I compile it on a linux box it gives lots of ->errors related to in_pktinfo data structure.The ->aodvSocket.cc is trying to do a sizeof this structure ->but the compiler says its incomplete.This structure is ->in "in.h" in the cross compiler include. But we just ->cant get it to work. Any help / information u can -> ->provide would be very helpful. -> ->PS :I have checked the netfilter on the linux box(not ->the ipaq) i'm using to cross compile the code.It is ->installed. -> -> ->Thanks ->Madhup ->CS Dept ->NCSU -> -> ->__________________________________________________ ->Do you Yahoo!? ->Yahoo! Tax Center - forms, calculators, tips, more ->http://taxes.yahoo.com/ -> -> ->------------------------------------------------------- ->This SF.net email is sponsored by: Scholarships for Techies! ->Can't afford IT training? All 2003 ictp students receive scholarships. ->Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. ->www.ictp.com/training/sourceforge.asp ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> -- |
|
From: madhup m. <mad...@ya...> - 2003-02-26 03:00:28
|
I got the UIUC AODV implementation from sourceforge.net.I want to compile it for an IPAQ(arm) using a cross compiler(arm-linux 2.95.2). When I compile it on a linux box it gives lots of errors related to in_pktinfo data structure.The aodvSocket.cc is trying to do a sizeof this structure but the compiler says its incomplete.This structure is in "in.h" in the cross compiler include. But we just cant get it to work. Any help / information u can ->provide would be very helpful. PS :I have checked the netfilter on the linux box(not the ipaq) i'm using to cross compile the code.It is installed. Thanks Madhup CS Dept NCSU __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Manish K. <ka...@is...> - 2002-10-10 21:38:09
|
using ASL0.11 and AODV/UIUC-0.5 is the function prototype for query_route_idle_time() in /usr/local/include/ASL/api.h correct?? it says: int query_route_idle_timer(addr_t dest_ip); should it have a second integer argument as shown below?? int query_route_idle_time(addr_t dest_ip, int flag); thanks manish |
|
From: Dan L. <da...@st...> - 2002-10-08 22:58:40
|
TianZhu, Make sure /usr/local/lib is in /etc/ld.so.conf and run ldconfig -a --Dan On Tue, 8 Oct 2002, Ye Tianzhu wrote: > Dear all, > > I encountered some problem while I ran the demo_router program. The program was compiled successfully, but when I ran it, I got the following error message: > > ./demo_router: error while loading shared libraries: libASL.so.0: cannot open shared object file: No such file or directory > > I've checked the /usr/local/lib directory and the library libASL.so.0 is there. Does anyone know what the problem is? > > > thanks and regards, > TianZhu > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > aslib-users mailing list > asl...@li... > https://lists.sourceforge.net/lists/listinfo/aslib-users > |
|
From: Ye T. <ET...@nt...> - 2002-10-08 08:10:30
|
Dear all, I encountered some problem while I ran the demo_router program. The = program was compiled successfully, but when I ran it, I got the = following error message: ./demo_router: error while loading shared libraries: libASL.so.0: cannot = open shared object file: No such file or directory I've checked the /usr/local/lib directory and the library libASL.so.0 is = there. Does anyone know what the problem is? thanks and regards, TianZhu |
|
From: Vikas K. <ka...@co...> - 2002-09-30 21:50:00
|
How can ping come from an interface which is not up. Check your etc/hosts file. If you have a mapping from the both the IP addresses to the same host name, there might be a problem. It seems like a config problem, rather than an ASl problem. Can you reproduce the problem. ..vikas PS : Sorry for the late response, I was travelling. On Tue, 24 Sep 2002, Dan LaFlamme wrote: ->libASL users, -> ->I am having a strange problem with packets getting sent from an IP address ->that is assigned to a network interface on my machine even when it is down. -> ->My configuration is as follows: -> ->eth0 - wired ethernet, configured for 192.168.1.140 ->eth1 - 802.11b card, configured for 10.1.1.2 -> -> -> ->Ok, I can explicitly bring down the eth0 interface with `/sbin/ifconfig eth0 ->down`. Now, eth0 does not appear in the list of interfaces when I do an ->`/sbin/ifconfig`. Then I ping some address as follows: -> -># ping 10.2.3.4 -> ->[root@localhost libASL]# ping 10.2.3.4 ->PING 10.2.3.4 (10.2.3.4) from 10.1.1.2 : 56(84) bytes of data. ->>From 10.1.1.2 icmp_seq=1 Destination Host Unreachable ->>From 10.1.1.2 icmp_seq=2 Destination Host Unreachable ->>From 10.1.1.2 icmp_seq=3 Destination Host Unreachable -> ->--- 10.2.3.4 ping statistics --- ->4 packets transmitted, 0 received, +3 errors, 100% loss, time 3028ms -> -> -> ->Ok, thats what I want. Note that the ping is coming from 10.1.1.2 (my wireless ->interface) which is what I want. -> -> ->Now I start up my ad-hoc routing daemon on eth1. I do a `/sbin/ifconfig`: -> ->[root@localhost libASL]# /sbin/ifconfig ->eth1 Link encap:Ethernet HWaddr 00:02:2D:05:58:22 -> inet addr:10.1.1.2 Bcast:10.255.255.255 Mask:255.0.0.0 -> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 -> TX packets:24 errors:1 dropped:0 overruns:0 carrier:0 -> collisions:0 txqueuelen:100 -> RX bytes:0 (0.0 b) TX bytes:3200 (3.1 Kb) -> Interrupt:5 Base address:0x100 -> ->lo Link encap:Local Loopback -> inet addr:127.0.0.1 Mask:255.0.0.0 -> UP LOOPBACK RUNNING MTU:16436 Metric:1 -> RX packets:58 errors:0 dropped:0 overruns:0 frame:0 -> TX packets:58 errors:0 dropped:0 overruns:0 carrier:0 -> collisions:0 txqueuelen:0 -> RX bytes:5610 (5.4 Kb) TX bytes:5610 (5.4 Kb) -> ->tun Link encap:Point-to-Point Protocol -> inet addr:127.0.0.2 P-t-P:127.0.0.2 Mask:255.255.255.255 -> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 -> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 -> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 -> collisions:0 txqueuelen:10 -> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) -> -> ->Note the tun interface is up as well as the wireless interface, but not eth0. -> ->Now I try doing the same ping that I did before. I expect the result to be the ->same, except that I get activity on the ASL socket letting my routing daemon ->know of a route request. Here is the ping: -> -> ->[root@localhost libASL]# ping 10.2.3.4 ->PING 10.2.3.4 (10.2.3.4) from 192.168.1.140 : 56(84) bytes of data. -> ->--- 10.2.3.4 ping statistics --- ->4 packets transmitted, 0 received, 100% loss, time 3014ms -> -> ->There it is. I do get the activity on the ASL socket, but as you can see, the ->ping is from "192.168.1.140", which is the IP of eth0, which is down. This ->obviously causes a problem because the routing daemon thinks its IP is ->"10.1.1.2" and won't think this request for a route was generated locally. -> ->Does anyone have any reason why this happens? Is this an issue with libASL or ->the way I am doing something in my routing daemon? -> -> -> -> ->------------------------------------------------------- ->This sf.net email is sponsored by:ThinkGeek ->Welcome to geek heaven. ->http://thinkgeek.com/sf ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Vikas Kawadia ------------- http://www.uiuc.edu/~kawadia -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
|
From: Dan L. <da...@st...> - 2002-09-24 15:34:41
|
libASL users,
I am having a strange problem with packets getting sent from an IP address
that is assigned to a network interface on my machine even when it is down.
My configuration is as follows:
eth0 - wired ethernet, configured for 192.168.1.140
eth1 - 802.11b card, configured for 10.1.1.2
Ok, I can explicitly bring down the eth0 interface with `/sbin/ifconfig eth0
down`. Now, eth0 does not appear in the list of interfaces when I do an
`/sbin/ifconfig`. Then I ping some address as follows:
# ping 10.2.3.4
[root@localhost libASL]# ping 10.2.3.4
PING 10.2.3.4 (10.2.3.4) from 10.1.1.2 : 56(84) bytes of data.
From 10.1.1.2 icmp_seq=1 Destination Host Unreachable
From 10.1.1.2 icmp_seq=2 Destination Host Unreachable
From 10.1.1.2 icmp_seq=3 Destination Host Unreachable
--- 10.2.3.4 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% loss, time 3028ms
Ok, thats what I want. Note that the ping is coming from 10.1.1.2 (my wireless
interface) which is what I want.
Now I start up my ad-hoc routing daemon on eth1. I do a `/sbin/ifconfig`:
[root@localhost libASL]# /sbin/ifconfig
eth1 Link encap:Ethernet HWaddr 00:02:2D:05:58:22
inet addr:10.1.1.2 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:1 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:3200 (3.1 Kb)
Interrupt:5 Base address:0x100
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5610 (5.4 Kb) TX bytes:5610 (5.4 Kb)
tun Link encap:Point-to-Point Protocol
inet addr:127.0.0.2 P-t-P:127.0.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Note the tun interface is up as well as the wireless interface, but not eth0.
Now I try doing the same ping that I did before. I expect the result to be the
same, except that I get activity on the ASL socket letting my routing daemon
know of a route request. Here is the ping:
[root@localhost libASL]# ping 10.2.3.4
PING 10.2.3.4 (10.2.3.4) from 192.168.1.140 : 56(84) bytes of data.
--- 10.2.3.4 ping statistics ---
4 packets transmitted, 0 received, 100% loss, time 3014ms
There it is. I do get the activity on the ASL socket, but as you can see, the
ping is from "192.168.1.140", which is the IP of eth0, which is down. This
obviously causes a problem because the routing daemon thinks its IP is
"10.1.1.2" and won't think this request for a route was generated locally.
Does anyone have any reason why this happens? Is this an issue with libASL or
the way I am doing something in my routing daemon?
|
|
From: Vikas K. <ka...@co...> - 2002-09-06 02:47:21
|
On Thu, 5 Sep 2002 da...@st... wrote: -> ->> Are you using host specific routes, that is all subnet masks are ->> 255.255.255.255. If so then the behavior you depict should not be ->> observed. In any case I cant really conclude much without looking at ->> the ->> logs. If you have the DEBUG flag enabled (README tell you where to do ->> this), try looking at the output to see whats happening. -> ->Would host specific routes be set before the routing daemon is started or by ->the routing daemon itself? I dont have my laptop here, but if I remember ->correctly the routing table that is displayed when the defferred route for ->0.0.0.0 is added looks like the following: -> ->Dest Gateway Genmask Flags Interface ->10.0.0.0 0.0.0.0 255.0.0.0 U eth1 ->127.0.0.0 0.0.0.0 255.0.0.0 U lo ->0.0.0.0 0.0.0.0 0.0.0.0 U tun ->0.0.0.0 10.1.1.2 0.0.0.0 UG eth1 -> ->I assume that the last entry is the defferred route added by my routing ->daemon, and I'm not sure, but woudl the first entry be the reason why any ->connections to 10.x.x.x dont get sent to the routing daemon? -> Yes. You should ensure that the first entry is not there and the routes added by the routing daemon should be like : ->10.1.1.2 10.1.1.x 255.255.255.255 UH eth1 This is if you want host specific routes, which is typically the case in ad-hoc networks. ..vikas -> -> -> ->------------------------------------------------------- ->This sf.net email is sponsored by: OSDN - Tired of that same old ->cell phone? Get a new here for FREE! ->https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Vikas Kawadia ------------- http://www.uiuc.edu/~kawadia -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
|
From: <da...@st...> - 2002-09-05 23:04:17
|
> Are you using host specific routes, that is all subnet masks are > 255.255.255.255. If so then the behavior you depict should not be > observed. In any case I cant really conclude much without looking at > the > logs. If you have the DEBUG flag enabled (README tell you where to do > this), try looking at the output to see whats happening. Would host specific routes be set before the routing daemon is started or by the routing daemon itself? I dont have my laptop here, but if I remember correctly the routing table that is displayed when the defferred route for 0.0.0.0 is added looks like the following: Dest Gateway Genmask Flags Interface 10.0.0.0 0.0.0.0 255.0.0.0 U eth1 127.0.0.0 0.0.0.0 255.0.0.0 U lo 0.0.0.0 0.0.0.0 0.0.0.0 U tun 0.0.0.0 10.1.1.2 0.0.0.0 UG eth1 I assume that the last entry is the defferred route added by my routing daemon, and I'm not sure, but woudl the first entry be the reason why any connections to 10.x.x.x dont get sent to the routing daemon? |
|
From: Yongguang Z. <yg...@hr...> - 2002-09-05 21:27:56
|
At 04:11 PM 9/5/02 -0400, Daniel LaFlamme wrote: >A more general question that relates to question 2 above is what techniques >are people using to test their adhoc routing daemons? Try mobiemu.sourceforge.net Yongguang |
|
From: Vikas K. <ka...@co...> - 2002-09-05 20:41:44
|
On Thu, 5 Sep 2002, Daniel LaFlamme wrote: ->Hello, -> -> ->I have a couple of questions about ASL. -> -> ->1. I was under the impression that when the routing daemon calls the ->route_request_done() function with the destination IP that cannot be found, ->the program trying to communicate with that IP should get "No route to host" ->and should fail. I had a routing daemon running that tried to establish a ->route to a host that an SSH client was trying to access. I have the routing ->daemon set to send a route request message 4 times, which it does, and when ->it fails to find a route (which is what should happen considering no other ->routing daemon is listening for its messages), it calls route_request_done() ->and that returns with no errors. At this point I would expect the SSH client ->to fail in its connection attempt but it does not. A short time later the ->daemon is trying to find the route again. Is this behavior expected? Yes, I would think so. ASL does not keep any history. If it gets an unroutable packet, it notifies the daemon. So if the ssh client retries, the routing daemon will get a notification again. The routing daemon can choose to maintain a history of recent route discovery attempts and immediately return a failure. ASL is not hte right place to implement any policy like this. -> ->2. I have my routing daemon operate on an interface with an IP of 10.1.1.2. ->When I have a client program try to access say 10.1.1.3 or anything in the ->10.x.x.x space, the routing daemon does not get a notification that it has ->to look for a route. However, when I have a client program try to access ->11.2.4.2 or something like that, the routing daemon gets a message from ASL ->to look for a route to that host. Is this behavior what is desired in most ->circumstances? It doesn't seem so to me. I thought by adding the deferred ->route when the routing daemon is initialized (as is done in Binita's AODV) ->would cause connections to any address to not be completed until the routing ->daemon found a route. Are you using host specific routes, that is all subnet masks are 255.255.255.255. If so then the behavior you depict should not be observed. In any case I cant really conclude much without looking at the logs. If you have the DEBUG flag enabled (README tell you where to do this), try looking at the output to see whats happening. -> ->A more general question that relates to question 2 above is what techniques ->are people using to test their adhoc routing daemons? -> Form an ad hoc network, form topologies, measure throughput etc. You can ask Binita Gupta for her MS thesis, she has lot of details on testing. You can also use a network of virtual user-mode-linux nodes, http://user-mode-linux.net. ..vikas -> ->Thanks for any input/clarification. -> ->--Dan -> -> -> -> ->------------------------------------------------------- ->This sf.net email is sponsored by: OSDN - Tired of that same old ->cell phone? Get a new here for FREE! ->https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ->_______________________________________________ ->aslib-users mailing list ->asl...@li... ->https://lists.sourceforge.net/lists/listinfo/aslib-users -> |
|
From: Daniel L. <da...@st...> - 2002-09-05 20:14:21
|
Hello, I have a couple of questions about ASL. 1. I was under the impression that when the routing daemon calls the route_request_done() function with the destination IP that cannot be found, the program trying to communicate with that IP should get "No route to host" and should fail. I had a routing daemon running that tried to establish a route to a host that an SSH client was trying to access. I have the routing daemon set to send a route request message 4 times, which it does, and when it fails to find a route (which is what should happen considering no other routing daemon is listening for its messages), it calls route_request_done() and that returns with no errors. At this point I would expect the SSH client to fail in its connection attempt but it does not. A short time later the daemon is trying to find the route again. Is this behavior expected? 2. I have my routing daemon operate on an interface with an IP of 10.1.1.2. When I have a client program try to access say 10.1.1.3 or anything in the 10.x.x.x space, the routing daemon does not get a notification that it has to look for a route. However, when I have a client program try to access 11.2.4.2 or something like that, the routing daemon gets a message from ASL to look for a route to that host. Is this behavior what is desired in most circumstances? It doesn't seem so to me. I thought by adding the deferred route when the routing daemon is initialized (as is done in Binita's AODV) would cause connections to any address to not be completed until the routing daemon found a route. A more general question that relates to question 2 above is what techniques are people using to test their adhoc routing daemons? Thanks for any input/clarification. --Dan |
|
From: Vikas K. <ka...@co...> - 2002-08-31 17:24:55
|
Checking that everything works. Please use the list for discussions. The project web page is http://aslib.sourceforge.net Thanks Vikas Kawadia |
|
From: Vikas K. <ka...@co...> - 2002-08-31 17:06:05
|
Checing that everything works.. http://aslib.sourceforge.net |
|
From: Vikas K. <ka...@co...> - 2002-08-31 17:02:20
|
Checking that everything works.. |