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" <[email protected]>
To: <[email protected]>
Cc: "jerrycheng-hinet" <[email protected]>
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
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
