extra bytes padding in ethernet frame causes router confusion

[gretchenv]

I have the following situation:
- a brand new computer with 4 ethernet ports all the same
- a router that adds relay agent information (DHCP option 82)
- a server that is set up to give me the right image depending on the port to which the computer is connected to the router (this is where the DHCP option 82 is used)

The problem is that ipxe sends a DHCP discover whose ethernet frame has 13 extra bytes of zero padding after the IPv4 packet containing the DHCP discover. The router adds its relay agent information after the padding and adjust the IPv4 packet header to accommodate this by adding the quantity of bytes added to the IPv4 header. This results in truncation of the relay agent information in the ethernet frame which was invalid anyway as the router placed it after the DHCP END option in the DHCP discver request. As a result no IP address is assigned by the server and booting fails.

I have traced the fault back to:

DHCP packet length: 347 bytes
UDP packet length: 375 bytes (347+28: OK)
Ethernet frame length: 403 bytes (375 + 14=389: NOK)

And from enabling and adding some debugging statements in iPXE:

DHCP packet length: 347: OK
IPv4 length: 375: OK
NETDEV length: 185 (hex) = 389 (decimal): OK, assuming that netdevice.c should add the link layer header.
NII: cpb.mediaheaderlength = 14, cpb.datalength = 389 (14+389=403: NOK!)

It appears that the NII driver whose implementation is in the UEFI BIOS adds the link level header by itself.

Unfortunately, I am kinda forced to use iPXE on an USB boot stick for booting:
- the UEFI BIOS does not allow me to single out a specific network port to do network booting from; the other three network ports are not allowed to send out DHCP requests.
- there is a strict requirement that the machine should attempt to boot infinitely many times until router, server and image to apply are all available and the BIOS PXE downloader gives up after minute.
An embedded iPXE script works wonders to get this functionality going (at least it did on other computers using legacy PXE booting).

How and where do I fix this without mucking up the later DHCP cycles and TFTP transfers?

[NiKiZe]

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?

[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.

[NiKiZe]

(2018-07-03 09:15)gretchenv Wrote:  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.

(2018-07-02 20:08)NiKiZe Wrote:  Do you have any machine with a nic that has native driver support if you use ipxe.efi instead?

Use any other machine with a supported hardware to first see if this is an issue in iPXE in general, or if it is NII specific, and if so if it is on your "speciallized" hardware only, and if it is the later, then wouldn't it be close to impossible to add a fix to iPXE that won't risk breaking NII implementations on other hardware?

[NiKiZe]

Could you check if https://git.ipxe.org/ipxe.git/commitdiff...6d1e55ba82 is related/fixes this issue?