<div dir="ltr">I went back to a (much) older version of ipxe in the interim, but have now run into a new yet possibly related issue.  I've been playing with the OVMF environment (edk2 + qemu + kvm on linux) and have OVMF running as the guest uEFI OS in this VM.  A bridge and taps connect the qemu e1000 NIC device to my physical networks and the whole thing manages to PXE boot ipxe from a real tftp server into the VM.<div>
<br></div><div style>However, the snponly ipxe seems to interfere with the edk2 stack and once ipxe has handed control over to a shell, ping (built into the shell) and various apps act funny (eg. ping packets go out, replies are sent and seen via wireshark on the qemu tap, but the replies don't make it back up the edk2 stack).  PXE boot the shell directly and ping works fine.</div>
<div style><br></div><div style>I hadn't had this problem on real hardware with previous uEFI implementations, so I'm a bit confused why it shows up now in this VM.</div><div style><br></div><div style>I am right in expecting the snponly ipxe to work nicely with existing network devices right?  Or perhaps this usage impacts the question above?</div>
<div style><br></div><div style>Last, at what point does snp ipxe plug into the uEFI stack?  Is the ipxe dhcp config separate from the EFI dhcp client?  (I have noticed two different IP addresses being allocated for this same NIC/MAC)  Could ipxe use more of the existing protocols now that edk2 is more stable?</div>
<div style><br></div></div>