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

[Michael Brown]

On 29/10/14 17:14, Floris Bos wrote:
> I'm not sure if it is actually the iBFT that is the problem.
> My initial guess was that was the case because the nameserver does not
> show up in "ipconfig", and my iSCSI disk is not there.
> But perhaps Windows does not copy the nameserver from iBFT, but normally
> gets that by using normal DHCP later on.
> And the real problem is that network connectivity is just screwed up,
> perhaps caused by iPXE leaving the network adapter in some kind of state
> Windows is not expecting.
> That I am seeing DHCP requests, and repeated ARP requests for the IP of
> my SAN after Windows booted supports the theory that it does have the
> iBFT, but that Windows is able to transmit network packets, but somehow
> has problems receiving them.
>
> - Several commits I tried before "[tcp] Do not send RST for unrecognised
> connections" all work properly
> - Several commits I tried after, all fail
> - It might be coincidence, but I just managed to get HEAD to work by
> reversing both "[tcp] Do not send RST for unrecognised connections" and
> "[tcp] Defer sending ACKs until all received packets have been
> processed" both which do hackery in src/net/tcp.c.

The problem does not seem to be related to the iBFT; I think we can 
leave that aside for now.

Interesting.  I wonder if it could be somehow related to the possibility 
of packets arriving between the time that Windows last allows iPXE 
control of the NIC (via an INT 13 call) and the moment that the Windows 
native driver starts up.

Unfortunately there is no way to enforce a clean handover of the NIC 
when doing anything with iSCSI, since the INT 13 API simply does not 
have any "shut down device" call.  The Windows driver will therefore 
always find the NIC in a slightly unexpected state in which it is 
already up and running and receiving packets.  It's plausible that the 
two TCP-related changes alter the behaviour in terms of when packets are 
transmitted (and thus responses received) sufficiently to trigger/avoid 
a bug.

You could try using the iPXE native driver instead of undionly.kkpxe. 
This will definitely change the state of the NIC at the time that the 
Windows driver starts up, and it may be that Windows likes this state 
better.

You could also try using wireshark to see if there are any packets 
present on the network which might arrive after iPXE last relinquishes 
control (i.e. after the last packet sent by iPXE within its TCP 
connection to the iSCSI target) but before the Windows driver has 
started up (i.e. before Windows' initial DHCP request or anything else 
which has obviously been sent by Windows).

>> A problem is that the SAN-booted OS is likely to clear the screen
>> almost immediately, meaning that the warning message would not be seen
>> in practice.
>
> But if I am doing a SAN installation couldn't the warning be printed the
> moment I do the sanhook command?

The iBFT is not created until you attempt to boot from the SAN target.

>> You can get some diagnostic information from the information printed
>> by pxeprefix.S when undionly.[k]kpxe starts up.  In particular, the
>> "XXXkB free base memory after PXE unload" will show you how much
>> memory was free before iPXE claimed its base memory segments.
>
> "577kB free base memory after PXE unload" with Virtualbox.

OK; the 512kB boundary is definitely not the problem.

Michael