I226-LM won't send DHCPOFFER?

[tblancher]

I ran into a problem where the I226-LM NIC will not send the DHCPOFFER on the wire.  The strange thing is I can see in tcpdump that the DHCPOFFER should go out, but the clients never receive it.

After some searching, I discovered this may be a function of vPro Essentials enabled on the I226-LM NIC.  I haven't tried disabling AMT for this NIC in the BIOS, but that is one suggested workaround.  I've also seen that this does not always solve the problem.  It seems to only affect untagged or default VLAN traffic;  if other VLANs are configured it seems to work fine (I can corroborate this because I had other VLANs that the clients could definitely receive the DHCPOFFER).

I'm using Arch Linux on a SimplyNUC Onyx Pro, with two Intel 2.5GbE Ethernet ports:

• 57:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
  Subsystem: Intel Corporation Device 0000
  Kernel driver in use: igc
  Interface name:  enp87s0
• 58:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-LM (rev 04)
  Subsystem: Intel Corporation Device 0000
  Kernel driver in use: igc
  Interface name:  enp88s0

Some of the other posts I've seen linked show both Windows and pfSense (based on FreeBSD) and Proxmox have seen similar behavior.  See the Reddit/Netgate forums in the Arch Linux BBS topic I've been seeking help on for details.

Is this a known issue for my revision?  Do I need to go to my OEM (SimplyNUC) for a fix?  I want to be able to tell them what's going on, before I seek an AMI BIOS/UEFI update.

[tblancher]

I reached out to my OEM, and they confirmed Intel is aware of the bug, and will be addressing it in a future firmware update.

The executive summary of the root cause is:  the I226-LM is misinterpreting the DHCPOFFER as an AMT control packet, so it consumes it before actually sending it on the wire.  This is below the Linux kernel level, so the system has no idea that the DHCPOFFER wasn't sent to the client.