[ipxe-devel] Windows having problems parsing iBFT from recent iPXE versions?
mcb30 at ipxe.org
Wed Oct 29 17:31:30 GMT 2014
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
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
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.
More information about the ipxe-devel