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