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

[Michael Brown]

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