extra bytes padding in ethernet frame causes router confusion

[gretchenv]

(2018-07-02 20:08)NiKiZe Wrote:  Since this is on the more technical level, I would suggest posting this to the ipxe mailing list for it to better reach the right audience.

But some more info might help here, Is this an issue with how iPXE creates the DHCP packet? an issue with the NII driver in iPXE, or an issue with the NII implementation in your firmware?
Do you have any machine with a nic that has native driver support if you use ipxe.efi instead?

I hacked the generation of the DHCP packet by iPXE so that it produces exactly the same packet as the UEFI BIOS native PXE implementation, which does generate an ethernet frame of the correct size (389 octets) resulting in a DHCPOFFER on the premise that the router might have gotten confused by some of the options normally put in by iPXE. It was only later that I discovered the zero padding bytes. (difference between -vv and -vvv options to tcpdump).

Whether it is an issue with the NII driver in iPXE or an issue with the NII implementation in the BIOS, that I do not know. I suppose it is possible that the interpretation of the UEFI NII specs differ.

I tried building intelx.efi (the board is an Intel Atom C3758 SoC, which supposedly has 4 Intel X55x LAN ports) but that failed to boot.