[Qemu-devel] Re: NE2000 problem found

[Qemu-devel] Re: NE2000 problem found

[Mike Nordell]

Fabrice Bellard wrote:

> Can you tell me exactly in which case you have problems with NE2000 ?

Always? :-)

On Windows 2000, running Windows 2000 sp4, -pci -cirrusvga.

It's also the thing that it seems only about every second time networking
"works", to the extent the guest actually gets a DHCP address. It seems the
slirp code is indeed getting the request, and is offering an addr, but the
response is not reaching the guest OS' IP-stack. Whether this is due to the
guests driver not even getting the interrupt from the virtual NIC, the
response frame is malformed or <whatever> I haven't yet been able to
determine. I'm still in the process of adding better tracing, to be able to
see what happens when.

After adding the asic writeb I have observed it being written with 0x43
(just a few times) and 0xff (more times), and only directly after "read
addr=0x7 val=40". I haven't yet added tracing output of rcnt for writeb, and
I don't know the significance of this, but I suspect it means something.

/Mike

Re: [Qemu-devel] Re: NE2000 problem found

[Fabrice Bellard]

Mike Nordell wrote:
> Fabrice Bellard wrote:
> 
> 
>>Can you tell me exactly in which case you have problems with NE2000 ?
> 
> 
> Always? :-)
> 
> On Windows 2000, running Windows 2000 sp4, -pci -cirrusvga.
> 
> It's also the thing that it seems only about every second time networking
> "works", to the extent the guest actually gets a DHCP address. It seems the
> slirp code is indeed getting the request, and is offering an addr, but the
> response is not reaching the guest OS' IP-stack. Whether this is due to the
> guests driver not even getting the interrupt from the virtual NIC, the
> response frame is malformed or <whatever> I haven't yet been able to
> determine. I'm still in the process of adding better tracing, to be able to
> see what happens when.
> 
> After adding the asic writeb I have observed it being written with 0x43
> (just a few times) and 0xff (more times), and only directly after "read
> addr=0x7 val=40". I haven't yet added tracing output of rcnt for writeb, and
> I don't know the significance of this, but I suspect it means something.

Interesting. This problem may really be liked to the WinXP security 
problem I mentionned.

Fabrice.

[Qemu-devel] Re: NE2000 problem found

[Mike Nordell]

I have now seen some pretty convincing evidence that ASIC byte-writes
*shall* be honoured, and disregard the 8/16-bit mode as specified by (dcfg &
1).

Guest: Windows 2000 sp4.

While in 16-bit mode (dcfg & 1):
- It sets EN0_RCNTLO to an odd value.
- Writes everything as 16-bit values (outw) except for the last byte.
- Writes the last byte using outb, which triggers the interrupt.

So there should be a separate ne2000_asic_ioport_writeb.

I also have good reasons to believe there should not be a matching readb
function. As a test I did implement such a function, but then I got a MAC of
52-52-54-54-00-00 :-)

/Mike

[Qemu-devel] Re: NE2000 problem found

[Mike Nordell]

I wrote:

> It's also the thing that it seems only about every second time
> networking "works", to the extent the guest actually gets a
> DHCP address.

I have now identified, and "fixed" this problem it seems. I have rebooted
four times, and the guest has gotten an IP every time.

It was that Windows cached the previous IP and tried to get that again on
next reboot, using DHCPREQUEST. Unfortunately, that failed miserably with
the CVS QEMU/slirp DHCP server. Basically, the code just dropped the request
and therefore the guest never got an IP.

When Windows didn't get an IP, it noted so, and on the next reboot used
DHCPDISCOVER - which works - and so the merro-go-around starts over again on
next reboot. :-)

I "fixed" it in a really Q&D way (probably wrong, and please don't hold the
"goto" against me - I just wanted to display with as little code as possible
how it could be fixed)

bootp_reply, in bootp.c

+try_again:
    if (dhcp_msg_type == DHCPDISCOVER) {
...
    } else {
        bc = find_addr(&daddr.sin_addr, bp->bp_hwaddr);
        if (!bc) {
            dprintf("no address assigned\n");
+#if 1
+            dhcp_msg_type = DHCPDISCOVER;
+            goto try_again;
+#else
            return;
+#endif
        }


/Mike

Re: [Qemu-devel] Re: NE2000 problem found

[Leigh Dyer]

On Thu, 2004-06-10 at 07:21 +0200, Mike Nordell wrote:
> I wrote:
> 
> > It's also the thing that it seems only about every second time
> > networking "works", to the extent the guest actually gets a
> > DHCP address.
> 
> I have now identified, and "fixed" this problem it seems. I have rebooted
> four times, and the guest has gotten an IP every time.
> 

I hadn't seen any more news on this, and I didn't see any patches
committed to CVS to fix this, so I thought I'd mention that I too see
this problem with Windows 2000 (it only gets an IP address from the DHCP
server on every second boot), and that this fix seems to solve the
problem for me as well.

Thanks
Leigh

> It was that Windows cached the previous IP and tried to get that again on
> next reboot, using DHCPREQUEST. Unfortunately, that failed miserably with
> the CVS QEMU/slirp DHCP server. Basically, the code just dropped the request
> and therefore the guest never got an IP.
> 
> When Windows didn't get an IP, it noted so, and on the next reboot used
> DHCPDISCOVER - which works - and so the merro-go-around starts over again on
> next reboot. :-)
> 
> I "fixed" it in a really Q&D way (probably wrong, and please don't hold the
> "goto" against me - I just wanted to display with as little code as possible
> how it could be fixed)
> 
> bootp_reply, in bootp.c
> 
> +try_again:
>     if (dhcp_msg_type == DHCPDISCOVER) {
> ...
>     } else {
>         bc = find_addr(&daddr.sin_addr, bp->bp_hwaddr);
>         if (!bc) {
>             dprintf("no address assigned\n");
> +#if 1
> +            dhcp_msg_type = DHCPDISCOVER;
> +            goto try_again;
> +#else
>             return;
> +#endif
>         }
> 
> 
> /Mike
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: NE2000 problem found

[kazu]

Hi,

I added your patch. Thank you.

http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.5.5-slirp2.patch.gz
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20040621-slirp2.patch.gz

Regards,
kazu

Thursday, June 17, 2004 1:50 PM Leigh Dyer wrote:
> On Thu, 2004-06-10 at 07:21 +0200, Mike Nordell wrote:
> > I wrote:
> >
> > > It's also the thing that it seems only about every second time
> > > networking "works", to the extent the guest actually gets a
> > > DHCP address.
> >
> > I have now identified, and "fixed" this problem it seems. I have
rebooted
> > four times, and the guest has gotten an IP every time.
> >
>
> I hadn't seen any more news on this, and I didn't see any patches
> committed to CVS to fix this, so I thought I'd mention that I too see
> this problem with Windows 2000 (it only gets an IP address from the DHCP
> server on every second boot), and that this fix seems to solve the
> problem for me as well.
>
> Thanks
> Leigh
>
> > It was that Windows cached the previous IP and tried to get that again
on
> > next reboot, using DHCPREQUEST. Unfortunately, that failed miserably
with
> > the CVS QEMU/slirp DHCP server. Basically, the code just dropped the
request
> > and therefore the guest never got an IP.
> >
> > When Windows didn't get an IP, it noted so, and on the next reboot used
> > DHCPDISCOVER - which works - and so the merro-go-around starts over
again on
> > next reboot. :-)
> >
> > I "fixed" it in a really Q&D way (probably wrong, and please don't hold
the
> > "goto" against me - I just wanted to display with as little code as
possible
> > how it could be fixed)
> >
> > bootp_reply, in bootp.c
> >
> > +try_again:
> >     if (dhcp_msg_type == DHCPDISCOVER) {
> > ...
> >     } else {
> >         bc = find_addr(&daddr.sin_addr, bp->bp_hwaddr);
> >         if (!bc) {
> >             dprintf("no address assigned\n");
> > +#if 1
> > +            dhcp_msg_type = DHCPDISCOVER;
> > +            goto try_again;
> > +#else
> >             return;
> > +#endif
> >         }
> >

> >
> > /Mike