[ipxe-devel] SAN Boot Windows XP with USB-NIC.

[jerrycheng-hinet]

Thanks, Michael,

> Could you try to establish the real MTU that your USB NIC is prepared to
> accept:
>
> a) start up iPXE and enter the iPXE command line via Ctrl-B
>
> b) type "dhcp" to acquire an IP address, and "route" to show the acquired
> address
>
> c) ping iPXE from the server to check that it responds to pings
>
> d) use the "-s <size>" option to try increasingly larger ping packets 
> until
> you find the size at which iPXE stops responding.  (I would expect "-s 
> 1472" to
> be the largest value that works, corresponding to an MTU of 1500 after
> allowing for 28 bytes of IP+ICMP header.)

After testing, the largest value that works is "-s 1464". It inspired me to 
try to setup mtu as 1492. Amazingly, it works. I can see logo of windows xp 
now!

Although it finally hanged at windows blue screen (looks like to be 0x7B), I 
think it should relate to "boot form usb device" issue this time. I will try 
to install windows xp into usb flash drive, and use it to create a new image 
for a trial.

I deeply appreciated all of your great help. Thank you so much!

Regards,
Jerry

----- Original Message ----- 
From: "Michael Brown" <mbrown at fensystems.co.uk>
To: <ipxe-devel at ipxe.org>
Cc: "jerrycheng-hinet" <jaspers.cheng at msa.hinet.net>
Sent: Friday, March 18, 2011 6:42 PM
Subject: Re: [ipxe-devel] SAN Boot Windows XP with USB-NIC.


> On Friday 18 Mar 2011 09:24:11 jerrycheng-hinet wrote:
>> 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!
>
> I see "eth:ip:tcp:data" for both; I think this is some kind of artefact in
> wireshark rather than a real problem.
>
> However, I do notice something interesting regarding the TCP segment 
> sizes:
>
> In the trace "wireshark_ipxe_xp_ok_part", frame 2 is a 2962-byte frame
> containing bytes [1,2897) in the sequence space.  The ACK for this frame 
> is
> split across frame 4, which ACKs [1,1449), and frame 5, which ACKs
> [1449,2897).  There is no logic within iPXE that would cause the ACK to be
> split in this way.
>
> In the trace "wireshark_mtu1500_fail_part", frame 2 is also a 2962-byte 
> frame,
> which should not be happening with an MTU of 1500.  Even more 
> interestingly,
> the retransmissions of this frame (in frames 6, 7, and 8) are 1514-byte
> frames.
>
> I am not convinced that wireshark is truly capturing the packets that are
> being sent out on the wire.  There appears to be some kind of TCP 
> segmentation
> offload still in effect on the server side.
>
> Could you try to establish the real MTU that your USB NIC is prepared to
> accept:
>
> a) start up iPXE and enter the iPXE command line via Ctrl-B
>
> b) type "dhcp" to acquire an IP address, and "route" to show the acquired
> address
>
> c) ping iPXE from the server to check that it responds to pings
>
> d) use the "-s <size>" option to try increasingly larger ping packets 
> until
> you find the size at which iPXE stops responding.  (I would expect "-s 
> 1472" to
> be the largest value that works, corresponding to an MTU of 1500 after
> allowing for 28 bytes of IP+ICMP header.)
>
> Thanks,
>
> Michael