Need help with ping (DUP!) + route + wlan + more.

I'm clueless, I've been so for a week, and I'm in desperate need of help.
Therefore I post as much relevant information as possibly can at once.
I hope someone is able to help me debug my system from this =)


I have a client and a server.
The server is an embedded ARM)-system running Linux 2.4.27/Busybox.
The client is a normal x86 running Linux 2.6.10/Debian.
They have two network devices each:

Client: Server:
eth0 (192.168.17.2) <--- network cable ---> eth0 (192.168.17.1)
wlan0 (10.0.0.44) <--- ad-hoc wlan ---> wlan0 (10.0.0.1)

The server uses an USB wlan dongle for its wlan0 device, with a
driver that I've cross-compiled myself using Buildroot.
I'm beginning to thing that it's this driver, that's unreliable;
On my x86 it can crash the box when unloading it. But then again,
it *almost* works.

But please read on ...



The server runs the minimalistic web server, httpd.
When I do this on the client (accessing the server though its eth0):
wget http://192.168.17.1/index.html
it works as expected.
But when I do this from the client (accessing the server though its wlan0):
wget http://10.0.0.1/index.html
then wget halts at "HTTP request sent, awaiting response...".

HOWEVER telnetting to 10.0.0.1 works. Also telnet 10.0.0.1 80 followed by
"get /index.html html/1.0" works!

So far, everything (wget and ssh) on the server's eth0 works, but on wlan0
only telnet works; everything else (wget and ssh) fails.



When I do this on the client, it works as expected:

sth@speedball:~$ ping 192.168.17.1
PING 192.168.17.1 (192.168.17.1) 56(84) bytes of data.
64 bytes from 192.168.17.1: icmp_seq=1 ttl=64 time=1.49 ms
64 bytes from 192.168.17.1: icmp_seq=2 ttl=64 time=0.328 ms

When I do thos in the client, I get DUPs:

64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.63 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=6.62 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=7.87 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=10.7 ms (DUP!)
I have experinced that continuing with ping for a long time, somehow makes the DUPs disappear:
64 bytes from 10.0.0.1: icmp_seq=547 ttl=64 time=2.63 ms
64 bytes from 10.0.0.1: icmp_seq=548 ttl=64 time=2.60 ms
64 bytes from 10.0.0.1: icmp_seq=549 ttl=64 time=2.23 ms

I haven't tried to reproduce this. And even after the DUPs are gone,
it doesn't change anything (wget/ssh still fail).



Running tcpdump on the server's eth0 while doing wget http://192.168.17.1/index.html
on the client gives the following and wget completes successfully:

root@au1901000039:~# tcpdump -n -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
18:38:44.611308 IP 192.168.17.2.32847 > 192.168.17.1.80: S 2012938573:2012938573(0) win 5840 <mss 1460,sackOK,timestamp 66001669[|tcp]>
18:38:44.611674 IP 192.168.17.1.80 > 192.168.17.2.32847: S 2828106147:2828106147(0) ack 2012938574 win 5792 <mss 1460,sackOK,timestamp 6415546[|tcp]>
18:38:44.611827 IP 192.168.17.2.32847 > 192.168.17.1.80: . ack 1 win 1460 <nop,nop,timestamp 66001669 6415546>
18:38:44.612345 IP 192.168.17.2.32847 > 192.168.17.1.80: P 1:110(109) ack 1 win 1460 <nop,nop,timestamp 66001670 6415546>
18:38:44.612589 IP 192.168.17.1.80 > 192.168.17.2.32847: . ack 110 win 5792 <nop,nop,timestamp 6415546 66001670>
18:38:44.623148 IP 192.168.17.1.80 > 192.168.17.2.32847: P 1:167(166) ack 110 win 5792 <nop,nop,timestamp 6415547 66001670>
18:38:44.623300 IP 192.168.17.2.32847 > 192.168.17.1.80: . ack 167 win 1460 <nop,nop,timestamp 66001681 6415547>
18:38:44.623605 IP 192.168.17.1.80 > 192.168.17.2.32847: P 167:469(302) ack 110 win 5792 <nop,nop,timestamp 6415547 66001681>
18:38:44.623788 IP 192.168.17.2.32847 > 192.168.17.1.80: . ack 469 win 1728 <nop,nop,timestamp 66001681 6415547>
18:38:44.624185 IP 192.168.17.1.80 > 192.168.17.2.32847: F 469:469(0) ack 110 win 5792 <nop,nop,timestamp 6415547 66001681>
18:38:44.625558 IP 192.168.17.2.32847 > 192.168.17.1.80: F 110:110(0) ack 470 win 1728 <nop,nop,timestamp 66001683 6415547>
18:38:44.625802 IP 192.168.17.1.80 > 192.168.17.2.32847: . ack 111 win 5792 <nop,nop,timestamp 6415547 66001683>

Running tcpdump on the server's wlan0 while doing wget http://10.0.0.1/index.html
on the client gives the following. After a while where wget hangs on the clinet,
I break it with ^C:

root@au1901000039:~# tcpdump -n -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 68 bytes
18:45:32.848055 IP 10.0.0.44.32849 > 10.0.0.1.80: S 2444878356:2444878356(0) win 5840 <mss 1460,sackOK,timestamp 66409997[|tcp]>
18:45:32.848543 IP 10.0.0.1.80 > 10.0.0.44.32849: S 3245335543:3245335543(0) ack 2444878357 win 5792 <mss 1460,sackOK,timestamp 6456333[|tcp]>
18:45:32.851076 IP 10.0.0.44.32849 > 10.0.0.1.80: . ack 1 win 1460 <nop,nop,timestamp 66409999 6456333>
18:45:32.852083 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66410000 6456333>
18:45:33.052782 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66410202 6456333>
18:45:33.457292 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66410606 6456333>
18:45:34.264329 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66411414 6456333>
18:45:35.880446 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66413030 6456333>
18:45:39.111645 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66416262 6456333>
18:45:39.877760 IP 10.0.0.44.32849 > 10.0.0.1.80: F 106:106(0) ack 1 win 1460 <nop,nop,timestamp 66417028 6456333>
Here I break wget with ^C on the client.
18:45:39.878310 IP 10.0.0.1.80 > 10.0.0.44.32849: . ack 1 win 5792 <nop,nop,timestamp 6457035 66409999,nop,nop,[|tcp]>
18:45:45.573980 IP 10.0.0.44.32849 > 10.0.0.1.80: P 1:106(105) ack 1 win 1460 <nop,nop,timestamp 66422726 6457035>



I can traceroute the server's eth0:

sth@speedball:~$ traceroute 192.168.17.1
traceroute to 192.168.17.1 (192.168.17.1), 30 hops max, 38 byte packets
1 192.168.17.1 (192.168.17.1) 1.576 ms 0.258 ms 0.192 ms

But traceroute on its wlan0 hangs and finds nothing during its 30 hops:

sth@speedball:~$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
...



This is the routing table on the client:

sth@speedball:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 ath0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.17.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.4.1 0.0.0.0 UG 0 0 0 ath0

Yes, I have some extra devices to the outside world. I have tried disabling these and
unload their modules (just to completely erase their existance from ifconfig -a); the
results above are the same.

This is the routing table on the server:

root@au1901000039:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.17.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo


This is the client's ifconfig -a:

sth@speedball:~$ ifconfig -a
ath0 Link encap:Ethernet HWaddr 00:05:4E:4C:F2:80
inet addr:192.168.4.44 Bcast:192.168.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30327 errors:70002 dropped:0 overruns:0 frame:70002
TX packets:15206 errors:1 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:199
RX bytes:11129881 (10.6 MiB) TX bytes:12523771 (11.9 MiB)
Interrupt:11 Memory:e09a0000-e09b0000

eth0 Link encap:Ethernet HWaddr 00:11:25:42:7C:06
inet addr:192.168.17.2 Bcast:192.168.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10329 errors:0 dropped:0 overruns:0 frame:0
TX packets:12469 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:912763 (891.3 KiB) TX bytes:3342389 (3.1 MiB)
Base address:0x8000 Memory:c0220000-c0240000

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:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3328 (3.2 KiB) TX bytes:3328 (3.2 KiB)

wlan0 Link encap:Ethernet HWaddr 00:0C:F6:11:87:31
inet addr:10.0.0.44 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:3029 errors:0 dropped:0 overruns:0 frame:0
TX packets:1704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:262189 (256.0 KiB) TX bytes:189548 (185.1 KiB)



This is the server's ifconfig -a:

root@au1901000039:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:12:CA:01:00:03
inet addr:192.168.17.1 Bcast:192.168.17.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2604 errors:0 dropped:0 overruns:0 frame:0
TX packets:1902 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:220500 (215.3 KiB) TX bytes:264051 (257.8 KiB)
Interrupt:24 Base address:0xc000

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:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1920 (1.8 KiB) TX bytes:1920 (1.8 KiB)

wlan0 Link encap:Ethernet HWaddr 00:0F:CB:C3:58:20
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3576 errors:0 dropped:0 overruns:0 frame:0
TX packets:2921 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:337376 (329.4 KiB) TX bytes:266152 (259.9 KiB)


Any help appreciated.
Thanks in advance,

--
Stephan Henningsen

Stephan Henningsen wrote:
> I have a client and a server.
> The server is an embedded ARM)-system running Linux 2.4.27/Busybox.
> The client is a normal x86 running Linux 2.6.10/Debian.
> They have two network devices each:
>
> Client: Server:
> eth0 (192.168.17.2) <--- network cable ---> eth0 (192.168.17.1)
> wlan0 (10.0.0.44) <--- ad-hoc wlan ---> wlan0 (10.0.0.1)

> When I do this on the client, it works as expected:
>
> sth@speedball:~$ ping 192.168.17.1
> PING 192.168.17.1 (192.168.17.1) 56(84) bytes of data.
> 64 bytes from 192.168.17.1: icmp_seq=1 ttl=64 time=1.49 ms
> 64 bytes from 192.168.17.1: icmp_seq=2 ttl=64 time=0.328 ms
>
> When I do thos in the client, I get DUPs:
>
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.63 ms
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=6.62 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=7.87 ms (DUP!)
> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=10.7 ms (DUP!)
> I have experinced that continuing with ping for a long time, somehow makes
> the DUPs disappear: 64 bytes from 10.0.0.1: icmp_seq=547 ttl=64 time=2.63
> ms 64 bytes from 10.0.0.1: icmp_seq=548 ttl=64 time=2.60 ms
> 64 bytes from 10.0.0.1: icmp_seq=549 ttl=64 time=2.23 ms
>
Hi Stephan,

the DUP means duplicated echo replys. And this is propably the problem. I
guess, that the server will answer using the ethernet connection, if if you
contact it using wlan. You might want to try this using tcpdump. What the
reason is for this behaviour I can not tell. Maybe you want to take a look
at the hosts file and and add the wlan ip address of the client.

With kind regards, Alex

Hi Alexander =)


Alexander Harsch wrote:

> the DUP means duplicated echo replys. And this is propably the problem. I
> guess, that the server will answer using the ethernet connection, if if you
> contact it using wlan. You might want to try this using tcpdump.


Luckily I have an extra serial console connection to the server, so I can tcpdump
on both network interfaces without making noise on the device myself.

I've run tcpdump both on the server's wlan0 and eth0, and on the client's wlan0 and eth0
in all combinations. And I see nothing wrong: When I wget http://10.0.0.1/index.html from
the client, I only get traffic on the wlan0 devices.

I ran tcpdump while pinging:

When I ping 10.0.0.1 from the client, I only get traffic on wlan0 on both machines.
This is what the client's ping looks like:
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=1.97 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=6.22 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=8.10 ms (DUP!)
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=10.9 ms (DUP!)

This is the client's tcpdump of wlan0 generated by one ping request towards the server:
11:48:20.069654 IP 10.0.0.44 > 10.0.0.1: icmp 64: echo request seq 7
11:48:20.071598 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
11:48:20.075844 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
11:48:20.077721 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
11:48:20.080592 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7

This is the server's tcpdump of wlan0 generated by one ping request from the client:
21:10:10.146198 IP 10.0.0.44 > 10.0.0.1: icmp 64: echo request seq 7
21:10:10.146442 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
21:10:10.150257 IP 10.0.0.44 > 10.0.0.1: icmp 64: echo request seq 7
21:10:10.150562 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
21:10:10.152332 IP 10.0.0.44 > 10.0.0.1: icmp 64: echo request seq 7
21:10:10.152637 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7
21:10:10.155231 IP 10.0.0.44 > 10.0.0.1: icmp 64: echo request seq 7
21:10:10.155505 IP 10.0.0.1 > 10.0.0.44: icmp 64: echo reply seq 7

When I ping 192.168.17.1 from the client, I only get traffic on eth0 on both machines,
and the ping look good without DUPs. So far so good; traffic streaming through the
proper channels and the "expected" DUPs.

The same goes the other way around, when ping the client from the server:
DUPs on wlan0 and only traffic on either wlan0 or eth0 on both sides.

Under some (unreproducable I think) circumstances, I can get rid of the DUPs.
But still wget://10.0.0.1/index.html from the client just hangs.

> What the
> reason is for this behaviour I can not tell. Maybe you want to take a look
> at the hosts file and and add the wlan ip address of the client.


This is my server's /etc/hosts:
127.0.0.1 localhost
192.168.17.1 au1901000039-eth0 au1901000039
10.0.0.1 au1901000039-wlan0
10.0.0.44 speedball-wlan0
10.0.0.44 10.0.0.44
192.168.17.2 speedball-eth0
192.168.4.44 speedball-ath0 speedball

The 10.0.0.44=10.0.0.44 was just a desperate attempt; makes no difference.
My server's /etc/resolv.conf is currently empty. I don't know what to put in it,
since the server is on network and makes no use of a DNS currently.

I hope you can help me get further =)
Thank,

--
Stephan Henningsen