<div dir="ltr">Floris,<div><br></div><div>I'm a little late reading this email, but you say that you are having issues with Windows iSCSI on the Intel NUC series. I am curious which exact NUC model you are using. I ask because I have three here at my house all running completely diskless iSCSI and have been for nearly two years without issue. Perhaps I could provide some assistance. I apologize if you already provided this information, I managed to lose all emails prior to this one.</div><div><br></div><div>Steve</div></div><div class="gmail_extra"><br clear="all"><div><div><b><font size="4">Steve Cross</font></b></div><div><font size="1"><a href="mailto:hairlesshobo@stevecross.org" target="_blank">hairlesshobo@stevecross.org</a></font></div></div>
<br><div class="gmail_quote">On Thu, Oct 30, 2014 at 11:31 AM, Floris Bos <span dir="ltr"><<a href="mailto:bos@je-eigen-domein.nl" target="_blank">bos@je-eigen-domein.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/30/2014 02:02 PM, Michael Brown wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- iPXE communcation seems to end with an iSCSI read response, iPXE ACKs<br>
nicely<br>
- then there is this long wait on Windows startup (waiting for disks?),<br>
and during that there are some TCP retransmissions of an iSCSI NOP<br>
command trying to keep the connection warm from SAN to virtualbox.<br>
- straight after that Windows takes over, there is some DHCP/ARP traffic<br>
(not shown below), a LLMNR request for wpad, and a new iSCSI login.<br>
<br>
<snip><br>
<br>
- Seems the iSCSI read response is retransmitted lacking the last ACK.<br>
Those packets may arrive when Windows is about to take over.<br>
- Windows does not seem to do any iSCSI communication<br>
</blockquote>
<br>
Fantastic debugging work.  Could you possibly copies post the two captures (either as attached raw .pcap files, or uploaded to <a href="https://appliance.cloudshark.org/upload/" target="_blank">https://appliance.cloudshark.<u></u>org/upload/</a> ?<br>
<br>
</blockquote>
<br>
<a href="https://www.cloudshark.org/captures/a781ff622adc" target="_blank">https://www.cloudshark.org/<u></u>captures/a781ff622adc</a><br>
<a href="https://www.cloudshark.org/captures/0968b06118f5" target="_blank">https://www.cloudshark.org/<u></u>captures/0968b06118f5</a><br>
<br>
<br>
Note that some communication is missing.<br>
E.g. traffic between the virtualbox VM where Windows is being installed (192.168.178.4), and the virtualbox VM that plays for DHCP/installation server (192.168.178.100), doesn't touch the host system and therefore isn't in this capture.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The iBFT is not created until you attempt to boot from the SAN target.<br>
</blockquote></blockquote>
<br>
My mistake; the iBFT is actually created at the moment of the "sanhook" command, which would give time for any warning message to be displayed.  The architectural issue is then that iPXE has no mechanism in place for displaying non-fatal error messages.  We could make int13_describe() return an error, but this would then prevent the SAN device from being hooked.  We could hack a printf() into int13.c, but that kind of crossover between mechanism and policy is the kind of ugliness that I've worked hard for over a decade to eliminate from this codebase.<br>
<br>
Since it's a fairly pathological system in which the memory above 512kB is all used by the time iPXE starts up, and since it's definitely not the cause of the problem you're experiencing, I don't propose to do anything about it now.<br>
</blockquote>
<br>
Did had that issue on other systems, and still think not getting any warning and it mysterically failing is very annoying.<br>
Affects the Intel NUC series, and doubt I'm the only one that tried to use those in diskless setups.<br>
<br>
<br>
Yours sincerely,<br>
<br>
Floris Bos<br>
<br>
______________________________<u></u>_________________<br>
ipxe-devel mailing list<br>
<a href="mailto:ipxe-devel@lists.ipxe.org" target="_blank">ipxe-devel@lists.ipxe.org</a><br>
<a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel" target="_blank">https://lists.ipxe.org/<u></u>mailman/listinfo.cgi/ipxe-<u></u>devel</a><br>
</blockquote></div><br></div>