[ipxe-devel] Two problems/bugs in iPXE related to multiple NICs

Robin Smidsrød robin at smidsrod.no
Thu Feb 14 10:03:08 UTC 2013

On 13.02.2013 16:46, kevin at fantaplay.com wrote:
> Indeed, it appears from my testing that Windows won't initialize the 2nd
> NIC port if it's not given in the iBFT.  This was on an HP ProLiant
> DL145 G3, which has an integrated Broadcom NetXtreme 5715, which is a
> dual-ported gigabit Ethernet controller.  I was using the UNDI-only
> gPXE, but I don't think this would matter to Windows, as it has its own
> protected mode NIC drivers.
> I agree that this is surprising behaviour, and it doesn't make any sense
> to me, but it seems to be the case.  I think you're correct about the
> permanent static route on the boot NIC, but it is apparently not safe to
> assume that the OS will allow unlisted NICs to operate as usual.

What if you install a Realtek or Intel NIC in one of the PCI(e) slots of
the machine, will that NIC be available for Windows to use? Could it be
a problem with NICs using the same driver as the iscsi boot NIC?

> I tested this behaviour by modifying gPXE source code to introduce a
> second NIC section in the iBFT.  At each test I double-checked what was
> going into the iBFT by reconfiguring the iSCSI target server to expose a
> different image on the same LUN, and on that alternate image I had in
> the boot sector a small assembler program I wrote to display a hex dump
> of the raw iBFT contents and then halt.  I can send that program if it
> helps.  Once I verified the iBFT was set as I had intended, I would
> switch the image back and reboot to Windows.

I'm sure someone on the mailing-list would find that useful.

> As mentioned on SF, Windows not only refused to initialize the second
> NIC port if it wasn't in the iBFT, but it was also very picky about how
> the iBFT was structured and which NIC the SAN was on.  I almost gave up
> due to how many changes I had to make to the setup and iBFT before
> finally discovering what worked.
> I've posted a question on Technet:
> http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/4754a750-044d-49d2-a2c2-645e543efb45

I noticed a guy named Tim from Cisco responded and said that was the
responsibility of the NIC vendor. I'd like to hear his response on what
should happen if you have multiple NICs from multiple vendors in one
machine. Obviously one vendors firmware can't include other NICs then
what their own firmware understands, right? And I still don't understand
why NICs that were NOT used in iscsi booting shouldn't operate as normal.

> May I suggest that if you don't tag stable releases, you get rid of the
> tags altogether and/or place a message prominently on the page that
> lists the main branch commits, advising visitors that the whole branch
> represents stable releases?  This may be better than arbitrarily tagging
> only some of the stable commits, unless they actually are more stable.

The old tags are from gPXE days (before forking into iPXE). I guess some
kind of message on the download page could be useful to indicate this
release behavior.

I'd urge you to join the mailing-list, it's quite low-volume (usually
less than 10 messages per week). I've CC-ed my response to the list so
more people can help. I'm not really a C hacker, so my help here is limited.

-- Robin

More information about the ipxe-devel mailing list