| Message ID | 4E71F873.5020700@web.de |
|---|---|
| State | New |
| Headers | show |
2011/9/15 Jan Kiszka <jan.kiszka@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. > diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c > index c1214c0..5a79c68 100644 > --- a/slirp/tcp_input.c > +++ b/slirp/tcp_input.c > @@ -610,6 +610,7 @@ findso: > so->so_ti = ti; > tp->t_timer[TCPT_KEEP] = TCPTV_KEEP_INIT; > tp->t_state = TCPS_SYN_RECEIVED; > + tcp_template(tp); > } > return; > > > Jan > >
On 2011-09-15 15:20, Roy Tam wrote: > 2011/9/15 Jan Kiszka <jan.kiszka@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, Jan
Hi, 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: > On 2011-09-15 15:20, Roy Tam wrote: >> 2011/9/15 Jan Kiszka <jan.kiszka@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. > Jan > >
On 2011-10-26 10:03, Roy Tam wrote: > Hi, > > 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: >> On 2011-09-15 15:20, Roy Tam wrote: >>> 2011/9/15 Jan Kiszka <jan.kiszka@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. Thanks, Jan
Hi, 2011/10/26 Jan Kiszka <jan.kiszka@siemens.com>: > On 2011-10-26 10:03, Roy Tam wrote: >> Hi, >> >> 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: >>> On 2011-09-15 15:20, Roy Tam wrote: >>>> 2011/9/15 Jan Kiszka <jan.kiszka@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. > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux >
2011/10/27 Roy Tam <roytam@gmail.com>: > Hi, > > 2011/10/26 Jan Kiszka <jan.kiszka@siemens.com>: >> On 2011-10-26 10:03, Roy Tam wrote: >>> Hi, >>> >>> 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: >>>> On 2011-09-15 15:20, Roy Tam wrote: >>>>> 2011/9/15 Jan Kiszka <jan.kiszka@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. > >> Thanks, >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT T DE IT 1 >> Corporate Competence Center Embedded Linux >> >
On 2011-10-27 05:21, Roy Tam wrote: > 2011/10/27 Roy Tam <roytam@gmail.com>: >> Hi, >> >> 2011/10/26 Jan Kiszka <jan.kiszka@siemens.com>: >>> On 2011-10-26 10:03, Roy Tam wrote: >>>> Hi, >>>> >>>> 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: >>>>> On 2011-09-15 15:20, Roy Tam wrote: >>>>>> 2011/9/15 Jan Kiszka <jan.kiszka@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. Could you collect a trace of the host-guest communication, e.g. via the dump plugin ('-net dump')? Thanks, Jan
2011/10/27 Jan Kiszka <jan.kiszka@siemens.com>: > On 2011-10-27 05:21, Roy Tam wrote: >> 2011/10/27 Roy Tam <roytam@gmail.com>: >>> Hi, >>> >>> 2011/10/26 Jan Kiszka <jan.kiszka@siemens.com>: >>>> On 2011-10-26 10:03, Roy Tam wrote: >>>>> Hi, >>>>> >>>>> 2011/9/15 Jan Kiszka <jan.kiszka@web.de>: >>>>>> On 2011-09-15 15:20, Roy Tam wrote: >>>>>>> 2011/9/15 Jan Kiszka <jan.kiszka@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 >
diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c index c1214c0..5a79c68 100644 --- a/slirp/tcp_input.c +++ b/slirp/tcp_input.c @@ -610,6 +610,7 @@ findso: so->so_ti = ti; tp->t_timer[TCPT_KEEP] = TCPTV_KEEP_INIT; tp->t_state = TCPS_SYN_RECEIVED; + tcp_template(tp); } return;