From: Jeff D. <jd...@ka...> - 2001-12-23 22:00:01
|
le...@ti... said: > (I run "bw_tcp -s" on the host and "bw_tcp <host_ip>" on UML). All > data are actually passed through (and it seems very fast..) but the > connection is not closed on one side. Do tcpdump on the host and UML agree on what the final packets of the connection were? I'm not familiar with the TCP handshaking stuff, but it sounds like the host was expecting a packet that never showed up. Presumably UML generated it, so the thing to do would be to figure out what happened to it. Comparing tcpdumps would be a start. I'm not sure what to do after, though. Jeff |
From: Jeff D. <jd...@ka...> - 2001-12-24 17:30:39
|
le...@ti... said: > They are identical. So that means that all the packets generated by UML network are making it out to the host. > Interesting enough, I changed the MTU on both interfaces from 1500 to > 1484. In this way it seems to work, but I get just 1MB/s. This suggests that the TUN/TAP driver is messing up somehow, or the UML driver is sending packets that are too big or something. > UML: > ) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) [snip] > host: > 14:42:12.968224 192.168.1.3.31236 > 192.168.1.128.1026: . [snip] Those two dumps don't look identical at all. Were they generated from the same traffic? Does it work when you reverse the direction? If so, I guess we need to compare that tcpdump to the ones that show the hang. Jeff |
From: Lorenzo A. <le...@ti...> - 2001-12-25 15:02:08
|
At 13.50 24/12/01 -0500, Jeff Dike wrote: >le...@ti... said: >> They are identical. > >So that means that all the packets generated by UML network are making it >out to the host. > >> Interesting enough, I changed the MTU on both interfaces from 1500 to >> 1484. In this way it seems to work, but I get just 1MB/s. > >This suggests that the TUN/TAP driver is messing up somehow, or the UML >driver is sending packets that are too big or something. > >> UML: >> ) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) >[snip] >> host: >> 14:42:12.968224 192.168.1.3.31236 > 192.168.1.128.1026: . >[snip] > >Those two dumps don't look identical at all. Were they generated from the >same traffic? Yes. >Does it work when you reverse the direction? Yes it does, see below. >If so, I guess we need to >compare that tcpdump to the ones that show the hang. bw_tcp -s on UML tcpdump -n -i eth0 (UML): 14:49:51.936850 192.168.1.127.32773 > 192.168.1.128.31236: . ack 10449185 win 47784 <nop,nop,timestamp 19879 2286> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: . 10449185:10450633(1448) ack 9 win 5792 <nop,nop,timestamp 2286 19873> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: . 10450633:10452081(1448) ack 9 win 5792 <nop,nop,timestamp 2286 19873> (DF) 14:49:51.936850 192.168.1.127.32773 > 192.168.1.128.31236: . ack 10452081 win 47784 <nop,nop,timestamp 19879 2286> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: . 10452081:10453529(1448) ack 9 win 5792 <nop,nop,timestamp 2286 19873> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: . 10453529:10454977(1448) ack 9 win 5792 <nop,nop,timestamp 2286 19873> (DF) 14:49:51.936850 192.168.1.127.32773 > 192.168.1.128.31236: . ack 10454977 win 47784 <nop,nop,timestamp 19879 2286> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: . 10454977:10456425(1448) ack 9 win 5792 <nop,nop,timestamp 2286 19873> (DF) 14:49:51.936850 192.168.1.128.31236 > 192.168.1.127.32773: F 10485761:10485761(0) ack 10 win 5792 <nop,nop,timestamp 2286 19879> (DF) 14:49:51.936850 192.168.1.127.32773 > 192.168.1.128.31236: . ack 10485762 win 47784 <nop,nop,timestamp 19881 2286> (DF) 5926 packets received by filter 0 packets dropped by kernel tcpdump -n -i tap0 (host): 14:49:51.819163 192.168.1.128.31236 > 192.168.1.127.32773: . 10348521:10349969(1448) ack 9 win 5792 <nop,nop,timestamp 2285 19866> (DF) 14:49:51.819218 192.168.1.127.32773 > 192.168.1.128.31236: . 9:9(0) ack 10349969 win 47784 <nop,nop,timestamp 19871 2285> (DF) 14:49:51.819421 192.168.1.128.31236 > 192.168.1.127.32773: . 10349969:10351417(1448) ack 9 win 5792 <nop,nop,timestamp 2285 19866> (DF) 14:49:51.819539 192.168.1.128.31236 > 192.168.1.127.32773: . 10351417:10352865(1448) ack 9 win 5792 <nop,nop,timestamp 2285 19866> (DF) 14:49:51.819594 192.168.1.127.32773 > 192.168.1.128.31236: . 9:9(0) ack 10352865 win 47784 <nop,nop,timestamp 19871 2285> (DF) 14:49:51.819801 192.168.1.128.31236 > 192.168.1.127.32773: . 10352865:10354313(1448) ack 9 win 5792 <nop,nop,timestamp 2285 19866> (DF) 14:49:51.819920 192.168.1.128.31236 > 192.168.1.127.32773: P 10354313:10354689(376) ack 9 win 5792 <nop,nop,timestamp 2285 19866> (DF) 14:49:51.819973 192.168.1.127.32773 > 192.168.1.128.31236: . 9:9(0) ack 10354689 win 47784 <nop,nop,timestamp 19871 2285> (DF) 14:49:51.835378 192.168.1.127.32773 > 192.168.1.128.31236: . 9:9(0) ack 10357585 win 47784 <nop,nop,timestamp 19872 2285> (DF) 14:49:51.835784 192.168.1.127.32773 > 192.168.1.128.31236: . 9:9(0) ack 10360481 win 47784 <nop,nop,timestamp 19872 2285> (DF) 5056 packets received by filter 6013 packets dropped by kernel The bandwidth reported by bw_tcp is about 6.7MB/sec. .. and now bw_tcp -s on the host tcpdump -n -i eth0: 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10460769 win 47784 <nop,nop,timestamp 6037 38603> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10462217 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10463665 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10465113 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10466561 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10468009 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10469457 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10470905 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10472353 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.217289 192.168.1.128.1024 > 192.168.1.3.31236: . ack 10473801 win 47784 <nop,nop,timestamp 6037 38604> (DF) 2607 packets received by filter 0 packets dropped by kernel tcpdump -n -i tap0: 14:53:02.168646 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10460769 win 47784 <nop,nop,timestamp 6037 38603> (DF) 14:53:02.168814 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10462217 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.168982 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10463665 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169144 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10465113 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169307 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10466561 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169466 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10468009 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169628 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10469457 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169804 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10470905 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.169973 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10472353 win 47784 <nop,nop,timestamp 6037 38604> (DF) 14:53:02.170140 192.168.1.128.1024 > 192.168.1.3.31236: . 9:9(0) ack 10473801 win 47784 <nop,nop,timestamp 6037 38604> (DF) 1850 packets received by filter 6266 packets dropped by kernel bw_tcp hangs. As you can see in both tests tcpdump reports many dropped packets on the host, but "ifconfig tap0" doesn't report such packets. All tests done with the default MTU, 1500. Host is a SuSE 7.2, UML is a Debian 2.2 root image. Both bw_tcp compiled on Debian 2.2 -- Lorenzo |
From: Jonathan W. <jo...@sp...> - 2001-12-26 19:02:38
|
I'm encountering a problem using gdb on userland programs (running on usermode linux) when they have been linked with libpthread.so. When I try to run the program from gdb, I get Couldn't get floating point status: Input/output error. Here's an example transcript, showing how a simple program cannot be debugged when linked with libpthread: bash-2.04# cat foo.c main() {printf("foo\n");} bash-2.04# cc -g foo.c -lpthread bash-2.04# /mnt/host/usr/bin/gdb ./a.out GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) r Starting program: /root/./a.out [New Thread 1024 (LWP 533)] Couldn't get floating point status: Input/output error. ^^^^^^^ The Error ^^^^^^^^^ (gdb) The program is running. Exit anyway? (y or n) y bash-2.04# cc -g foo.c bash-2.04# /mnt/host/usr/bin/gdb ./a.out GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) r Starting program: /root/./a.out foo Program exited with code 04. ^^^^^^^ Works fine ^^^^^^^^ Sharp eyes will of course notice that I am running gdb from the host fs; could this cause a problem? I'm running UML/linux 2.4.16. Thanks for any help, -Jonathan |
From: Lorenzo A. <le...@ti...> - 2001-12-24 15:33:08
|
At 18.20 23/12/01 -0500, Jeff Dike wrote: >le...@ti... said: >> (I run "bw_tcp -s" on the host and "bw_tcp <host_ip>" on UML). All >> data are actually passed through (and it seems very fast..) but the >> connection is not closed on one side. > >Do tcpdump on the host and UML agree on what the final packets of the >connection were? Looks like they do. Below are the tcpdump logs at the end of the connection. (192.168.1.128 is UML, 192.168.1.3 is the host) UML: ) ack 9 win 5792 <nop,nop,timestamp 110006 19904> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10459321 win 47784 <nop,nop,timestamp 19965 110005> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10460769 win 47784 <nop,nop,timestamp 19965 110005> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10462217 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10463665 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10465113 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10466561 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10468009 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10469457 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10470905 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10472353 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.214089 192.168.1.128.1027 > 192.168.1.3.31236: . ack 10473801 win 47784 <nop,nop,timestamp 19965 110006> (DF) host: ) ack 9 win 5792 <nop,nop,timestamp 110006 19904> (DF) 14:49:55.196069 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10459321 win 47784 <nop,nop,timestamp 19965 110005> (DF) 14:49:55.196299 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10460769 win 47784 <nop,nop,timestamp 19965 110005> (DF) 14:49:55.196462 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10462217 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.196628 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10463665 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.196790 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10465113 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.196950 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10466561 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.197126 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10468009 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.197286 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10469457 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.197444 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10470905 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.197601 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10472353 win 47784 <nop,nop,timestamp 19965 110006> (DF) 14:49:55.197759 192.168.1.128.1027 > 192.168.1.3.31236: . 9:9(0) ack 10473801 win 47784 <nop,nop,timestamp 19965 110006> (DF) They are identical. >I'm not familiar with the TCP handshaking stuff, but it sounds like the >host was expecting a packet that never showed up. Presumably UML generated >it, so the thing to do would be to figure out what happened to it. > >Comparing tcpdumps would be a start. I'm not sure what to do after, though. Interesting enough, I changed the MTU on both interfaces from 1500 to 1484. In this way it seems to work, but I get just 1MB/s. UML: ) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.128.1026 > 192.168.1.3.31236: . ack 10386193 win 47972 <nop,nop,timestamp 10777 63996> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: . 10386193:10387625(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.128.1026 > 192.168.1.3.31236: . ack 10387625 win 47256 <nop,nop,timestamp 10777 63996> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: . 10387625:10389057(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.128.1026 > 192.168.1.3.31236: . ack 10389057 win 47256 <nop,nop,timestamp 10777 63996> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: P 10389057:10390489(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.128.1026 > 192.168.1.3.31236: . ack 10390489 win 46540 <nop,nop,timestamp 10777 63996> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: . 10390489:10391921(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.128.1026 > 192.168.1.3.31236: . ack 10391921 win 45824 <nop,nop,timestamp 10777 63996> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: . 10391921:10393353(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.3.31236 > 192.168.1.128.1026: . 10393353:10394785(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:13.015076 192.168.1.3.312 host: 14:42:12.968224 192.168.1.3.31236 > 192.168.1.128.1026: . 10423425:10424857(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:12.968230 192.168.1.3.31236 > 192.168.1.128.1026: . 10424857:10426289(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:12.968235 192.168.1.3.31236 > 192.168.1.128.1026: . 10426289:10427721(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:12.968241 192.168.1.3.31236 > 192.168.1.128.1026: . 10427721:10429153(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:12.968247 192.168.1.3.31236 > 192.168.1.128.1026: . 10429153:10430585(1432) ack 9 win 5728 <nop,nop,timestamp 63996 10758> (DF) 14:42:12.968732 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10389057 win 47256 <nop,nop,timestamp 10777 63996> (DF) 14:42:12.969321 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10390489 win 46540 <nop,nop,timestamp 10777 63996> (DF) 14:42:12.969901 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10391921 win 45824 <nop,nop,timestamp 10777 63996> (DF) 14:42:12.970926 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10437745 win 25776 <nop,nop,timestamp 10777 63996,nop,nop, sack 1 {10369009:10370441} > (DF) 14:42:12.972096 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10439177 win 25060 <nop,nop,timestamp 10777 64085> (DF) 14:42:12.972194 192.168.1.128.1026 > 192.168.1.3.31236: . 9:9(0) ack 10440609 win 24344 <nop,nop,timestamp 10777 64085> (DF) -- Lorenzo |