Hi, Michael,

Add some of my observations.

My NB has an on board NIC. It can successfully sanboot windows xp. I captured the wireshark trace of the successful case and compare it to USB-NIC case.

Please open the attached wireshark trace files. For the same read command, frame 3 looks a bit different. Refer to the [Protocols in frame] field, the success case is "eth:ip:tcp:iscsi", the USB-NIC case is "eth:ip:tcp".

Do you have idea about why server side respond different for the same read command? Thanks very much!

Regards,
Jerry

----- Original Message ----- From: "jerrycheng-hinet" <[email protected]>
To: "Michael Brown" <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Friday, March 18, 2011 12:39 AM
Subject: Re: [ipxe-devel] SAN Boot Windows XP with USB-NIC.



Thanks, Michael,

You need to prevent your server's network card from sending packets that
are
too large for the USB NIC to receive.  To do this, you can either:

a) set the MTU on the server's NIC down to the standard Ethernet value of
1500
bytes, or

b) disable TCP segmentation offload (TSO) on the server's NIC.

Let me know what happens!

What I did to change the setting:
a) ifconfig eth0 mtu 1500
b) ethtool -K eth0 tso off

I tried both ways with 2 different NICs (INTEL PRO/1000 PT Quad Port Server Adapter and Realtek RTL8186C). Unfortunately, the result remained the same.
Please see attached trace file for more details.

I don't know why the both ways did not take effect. If you have any ideas,
please feel free to tell me. Thanks a lot!

Regards,
Jerry

----- Original Message ----- From: "Michael Brown" <[email protected]>
To: <[email protected]>
Cc: "jerrycheng-hinet" <[email protected]>;
<[email protected]>
Sent: Thursday, March 17, 2011 9:20 AM
Subject: Re: [ipxe-devel] SAN Boot Windows XP with USB-NIC.


On Tuesday 15 Mar 2011 18:06:05 jerrycheng-hinet wrote:
> i.e. assume that the NIC supports interrupts if *either* the
> ServiceFlags
> indicate SUPPORTED_IRQ *or* the IRQ number is non-zero.

I have tried to add above code to undinet.c. It seemed to work for my
USB-NIC.

Yes; unfortunately it would break undionly.kpxe running on an Emulex NIC.
Since the bug is in the PXE stack of your USB NIC (which is incorrectly
advertising that it does not use interrupts), I can't justify breaking the
Emulex NICs in order to make your USB NIC work.  We need to find some
other
solution.

So far, the sanboot seemed to get into trouble in NTDETECT.com. The
screen
showed "NTDETECT FAILED", then NB power reset happened .

I have opened debug messages of "undinet, int13, autoboot, sanboot_cmd,
iscsi" and captured the trace of whole booting process by wireshark.

If you are available, please take a look at attached wireshark trace
and.give me some suggestions? Thanks very much!

Thanks for the packet trace! It hadn't occurred to me to use DEBUG=syslog
as
a means of annotating a wireshark capture with inline debug output; it's
quite
a neat trick.

It looks at a first glance as though the NIC suddenly goes deaf to packets
within a specific TCP connection.  For example, packet 1947 shows that
iPXE
must have received packet 1946 but not packet 1945. It then appears that
iPXE
ignores the retransmissions in packets 1948, 1949, 1950, 1959, 1960 and
1961,
at which point the INT13 layer times out and closes the iSCSI connection.
iPXE then immediately successfully re-opens the iSCSI connection, which
proceeds happily until packet 2021, where the same pattern occurs.

The troublesome packets are the first packets within their respective
connections to have a size which is greater than a standard Ethernet MTU.
Everything we see is wholly consistent with these large packets being
dropped
before they are received by iPXE.

I think the problem is that you have the MTU on the server set to greater
than
1500.  iPXE requests a TCP MSS of 1460 bytes, but I think the TCP offload
on
your server's network card may be ignoring that.

You need to prevent your server's network card from sending packets that
are
too large for the USB NIC to receive.  To do this, you can either:

a) set the MTU on the server's NIC down to the standard Ethernet value of
1500
bytes, or

b) disable TCP segmentation offload (TSO) on the server's NIC.

Let me know what happens!

Michael

Attachment: wireshark_mtu1500_fail_part
Description: Binary data

Attachment: wireshark_ipxe_xp_ok_part
Description: Binary data

_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Reply via email to