2011/10/27 Jan Kiszka <jan.kis...@siemens.com>: > On 2011-10-27 05:21, Roy Tam wrote: >> 2011/10/27 Roy Tam <roy...@gmail.com>: >>> Hi, >>> >>> 2011/10/26 Jan Kiszka <jan.kis...@siemens.com>: >>>> On 2011-10-26 10:03, Roy Tam wrote: >>>>> Hi, >>>>> >>>>> 2011/9/15 Jan Kiszka <jan.kis...@web.de>: >>>>>> On 2011-09-15 15:20, Roy Tam wrote: >>>>>>> 2011/9/15 Jan Kiszka <jan.kis...@web.de>: >>>>>>>> On 2011-09-15 14:05, Roy Tam wrote: >>>>>>>>> Here you go. >>>>>>>>> >>>>>>>>> sb16: warning: command 0xf,1 is not truly understood yet >>>>>>>>> sb16: warning: command 0xe,2 is not truly understood yet >>>>>>>>> [Switching to Thread 13840.0x3140] >>>>>>>>> >>>>>>>>> Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=4294967295, >>>>>>>>> out_ethaddr=0x20af64a "") at slirp/arp_table.c:75 >>>>>>>>> 75 // assert((ip_addr & htonl(~(0xf << 28))) != 0); >>>>>>>>> (gdb) c >>>>>>>>> Continuing. >>>>>>>>> [New Thread 13840.0x31b8] >>>>>>>>> [Switching to Thread 13840.0x3628] >>>>>>>>> >>>>>>>>> Breakpoint 1, arp_table_search (slirp=0x19f7380, ip_addr=0, >>>>>>>>> out_ethaddr=0x22f642 "\"") at slirp/arp_table.c:75 >>>>>>>>> 75 // assert((ip_addr & htonl(~(0xf << 28))) != 0); >>>>>>>>> (gdb) bt >>>>>>>>> #0 arp_table_search (slirp=0x19f7380, ip_addr=0, >>>>>>>>> out_ethaddr=0x22f642 "\"") >>>>>>>>> at slirp/arp_table.c:75 >>>>>>>>> #1 0x004bafbd in if_encap (slirp=0x19f7488, ifm=0x2255978) >>>>>>>>> at slirp/slirp.c:709 >>>>>>>>> #2 0x004b8a73 in if_start (slirp=0x19f7380) at slirp/if.c:210 >>>>>>>>> #3 0x004b9c9e in ip_output (so=0x2255978, m0=0x0) at >>>>>>>>> slirp/ip_output.c:84 >>>>>>>>> #4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456 >>>>>>>>> #5 0x004c09ad in tcp_drop (tp=0x1cac848, err=0) at >>>>>>>>> slirp/tcp_subr.c:225 >>>>>>>>> #6 0x004c1182 in tcp_timers (timer=<optimized out>, tp=<optimized >>>>>>>>> out>) >>>>>>>>> at slirp/tcp_timer.c:287 >>>>>>>>> #7 tcp_slowtimo (slirp=0x0) at slirp/tcp_timer.c:88 >>>>>>>>> #8 0x004bb6f1 in slirp_select_poll (readfds=0x22fae0, >>>>>>>>> writefds=0x22f9dc, >>>>>>>>> xfds=0x22f8d8, select_error=2291816) at slirp/slirp.c:433 >>>>>>>>> #9 0x0048fb87 in main_loop_wait (nonblocking=0) >>>>>>>>> at C:/msys/home/User/qemu/vl.c:1436 >>>>>>>>> #10 0x00490d10 in main_loop () at C:/msys/home/User/qemu/vl.c:1466 >>>>>>>>> #11 qemu_main (argc=0, argv=0x19f5100, envp=0x0) >>>>>>>>> at C:/msys/home/User/qemu/vl.c:3453 >>>>>>>>> #12 0x0049322d in SDL_main (argc=17, argv=0x19f5100) >>>>>>>>> at C:/msys/home/User/qemu/vl.c:102 >>>>>>>>> #13 0x005eb784 in console_main () >>>>>>>>> #14 0x005eb844 in WinMain@16 () >>>>>>>>> #15 0x005eb068 in main () >>>>>>>>> (gdb) frame 4 >>>>>>>>> #4 0x004bf737 in tcp_output (tp=0x1cac848) at slirp/tcp_output.c:456 >>>>>>>>> 456 error = ip_output(so, m); >>>>>>>>> (gdb) print *tp >>>>>>>>> $1 = {seg_next = 0x1cac848, seg_prev = 0x1cac848, t_state = 0, >>>>>>>>> t_timer = {0, >>>>>>>>> 0, 0, 0}, t_rxtshift = 0, t_rxtcur = 12, t_dupacks = 0, t_maxseg >>>>>>>>> = 1460, >>>>>>>>> t_force = 0 '\000', t_flags = 0, t_template = {ti_i = {ih_mbuf = { >>>>>>>>> mptr = 0x0, dummy = 0}, ih_x1 = 0 '\000', ih_pr = 0 '\000', >>>>>>>>> ih_len = 0, ih_src = {S_un = {S_un_b = {s_b1 = 0 '\000', >>>>>>>>> s_b2 = 0 '\000', s_b3 = 0 '\000', s_b4 = 0 '\000'}, >>>>>>>>> S_un_w = { >>>>>>>>> s_w1 = 0, s_w2 = 0}, S_addr = 0}}, ih_dst = {S_un = >>>>>>>>> {S_un_b = { >>>>>>>>> s_b1 = 0 '\000', s_b2 = 0 '\000', s_b3 = 0 '\000', >>>>>>>>> s_b4 = 0 '\000'}, S_un_w = {s_w1 = 0, s_w2 = 0}, S_addr = >>>>>>>>> 0}}}, >>>>>>>> >>>>>>>> That confirms my theory: the template is not yet initialized. >>>>>>>> >>>>>>>> A shot from the hips: does this patch help? >>>>>>>> >>>>>>> >>>>>>> Yeah the assertion doesn't fail anymore. Thanks. >>>>>> >>>>>> Now I just need to invent some good "why this is correct"... ;) >>>>>> >>>>>> Thanks for testing, >>>>> >>>>> I just have time now to make some tests about -net user. >>>>> And I found that the User mode networking doesn't work anymore after >>>>> your slirp patch series. >>>> >>>> Can you be more verbose? What precisely does not work? Same setup as >>>> before (host, guest, command line, steps to reproduce)? I'm not facing >>>> problems here ATM. >>>> >>> >>> QEMU Revision: 2011-10-12 (latest git give me an Assertion failed: >>> alarm_has_dynticks(t), file qemu-timer.c, line 139. Since there is no >>> change in slirp directory, it should apply to latest git) >>> gcc version:$ gcc -v >>> Target: mingw32 >>> Configured with: ../gcc-4.3.3/configure --prefix=/mingw >>> --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ >>> --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls >>> --disable-win32-registry --enable-libgomp --disable-werror >>> --enable-threads --disable-symvers >>> --enable-cxx-flags='-fno-function-sections -fno-data-sections' >>> --enable-fully-dynamic-string --enable-version-specific-runtime-libs >>> --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' >>> Thread model: win32 >>> gcc version 4.3.3 (4.3.3-tdm-1 mingw32) >>> configure commandline: ./configure --target-list="i386-softmmu >>> x86_64-softmmu mips64el-softmmu" --audio-drv-list=sdl >>> --audio-card-list=ac97,sb16,adlib --disable-linux-aio >>> --enable-vnc-thread --disable-vnc-jpeg --extra-ldflags=-s >>> QEMU Host: Windows XP SP3 >>> QEMU Guest: Windows XP SP3, Linux 2.6.38 (NIC: ne2k-pci, e1000) >>> commandline: qemu-system-i386 -hda xp.vmdk -soundhw sb16 -m 320 >>> -localtime -usb -usbdevice tablet -net user -net nic,model=ne2k_pci >>> >>> Symptoms: >>> Guest can lease IP from QEMU Virtual DHCP Server, but the outgoing >>> traffic are not working: >>> - 10.0.2.3 Virtual DNS Server doesn't respond any DNS query ("nslookup >>> www.google.com" fails with timeout message, "nslookup www.google.com >>> <host's dns server ip>" and "nslookup www.google.com 8.8.8.8" are also >>> failed) >>> - 10.0.2.2 Virtual Gateway is also unable to connect, only reply >>> pings. Other connections are timeout. >>> - 10.0.2.4 Virtual Samba Server is also unconnectable >>> >>> My last worked build is 2011-9-09 build and it starts to fail since >>> 2011-9-10 build. >> >> And I'm tried on trying to build every revision. I can find the range >> df00bed0fa30a6f5712456e7add783e470c534c9(ok) to >> 31ff5cc31b10a4a48f854d8e06090c49f92a6720(fail) only. > > The second hash appears to be a blob rather than a commit. > > I've just re-tested current git head () with a WinXP guest, and it > happily receives dns replies, can ping to the outer world, and connect > to the web. >
I wonder if it is a non-QEMU issue(say, glib issue) or a QEMU-Host issue. As I have no Linux environment to test here. > Could you collect a trace of the host-guest communication, e.g. via the > dump plugin ('-net dump')? > Sure. http://rthost.fam.cx/tmp/qemu-vlan0.pcap > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux >