On 30/10/14 15:31, Floris Bos wrote:
Fantastic debugging work. Could you possibly copies post the two
captures (either as attached raw .pcap files, or uploaded to
https://appliance.cloudshark.org/upload/ ?
https://www.cloudshark.org/captures/a781ff622adc
https://www.cloudshark.org/captures/0968b06118f5
Thanks!
So, the problem seems to be triggered by the delayed-ACK behaviour from
commit d28bb51 ("[tcp] Defer sending ACKs until all received packets
have been processed"). I don't think commit 18d0818 ("[tcp] Do not send
RST for unrecognised connection") should make any difference, since
there are no unrecognised connections for which a RST could be sent
within these traces.
The delayed-ACK behaviour ends up manifesting as a missing ACK when
using iSCSI, since the ACK is deferred until the next call to step(),
which won't happen until control returns to iPXE. In the case of the
final block read, control will never return to iPXE, so step() is never
called again, so the final ACK is never sent.
We could (and probably should) fix this so that delayed ACKs are sent
before returning control via the INT 13 API. The easiest way to do this
would probably be to treat the TCP transmission process as a "pending
operation" (within the meaning of include/ipxe/pending.h) and to modify
int13_command_wait() to continue calling step() until have_pending()
returns false. I don't think this would substantially impact upon
performance or code size.
However, if the problem is caused by packets arriving during the Windows
driver start-up, then this fix would only make the problem less likely
to occur; it wouldn't eliminate it. A random packet arriving at a bad
time (e.g. a totally unrelated ARP request, NetBIOS name announcement,
etc) could still trigger the problem.
It would be interesting to know if you can reproduce the problem even in
your "fixed" build by sending frequent packets (e.g. flood pings with a
manually created ARP cache entry) from the iSCSI target during the boot.
Michael
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
