[ipxe-devel] Windows having problems parsing iBFT from recent iPXE versions?

[Michael Brown]

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