Can not get DHCP leases on new intel I225-LM based machine

TripleZ

Hello all,

I am new to pfsense and I am tearing my hair out trying to debug an issue on a new machine / new install. I can't get any clients to get a DHCP lease, or so it appears.

I recently bought this NUC: https://www.asrockind.com/en-gb/NUC%20BOX-1260P which has 2x 2.5gb interfaces based on the intel i225-LM NIC.

I see there was a lot of discussion on this NIC on this topic from last year here: https://forum.netgate.com/topic/159994/intel-ethernet-controller-i225-lm-support mainly around enabling the setting to disable hardware checksum offloading in 2.5.2, but that it should not be necessary in 2.6.0. However, my particular issue did not seem to be mentioned (or I am not smart enough to follow the conversation and it was mentioned...).

I have a fresh install of pfsense 2.6.0 and if I manually specify an address and dns on a client (IE: set LAN to static / 192.168.1.1, set windows client to 192.168.2.1, use .1 as my gateway, set dns manually to 8.8.8.8/8.8.4.4), things DO work as expected. I can get to the web UI as well as the outside internet, speed tests look good - no issues, but I simply can not get clients to receive an IP address via DHCP.

Various things I have tried:

disabled hardware checksum offloading
tried updating to the latest development build of pfsense (I read the support for the i225-lm in freebsd 12 might not have been great, so maybe freebsd 14 would make a difference)
tried opnsense as well (freebsd 13 based)
did a windows 10 install to sanity check the hardware seemed functional - nothing seemed out of the ordinary

Output of pciconf -lv

 igc1@pci0:46:0:0:       class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f2 subvendor=0x1849 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-LM'
    class      = network
    subclass   = ethernet

I am not super versed in digging into dhcp logs and other techniques, but with the right guidance, I could probably fumble through it.

Any advice would be appreciated on debugging this, thanks!

rcoleman-netgate

@triplez What does your hardware say on it for it's REV#? Not specifically the one in the driver here (which says it's 3 but might not be).

It was noted last night in the subreddit that R1 and R2 had physical issues with the 2.5GbE driver but R3 works.

TripleZ

@rcoleman-netgate I am a bit of a freebsd newb - what command would help produce that output?

TripleZ

@rcoleman-netgate The document located at:
https://www.intel.com/content/www/us/en/support/articles/000057261/ethernet-products/gigabit-ethernet-controllers-up-to-2-5gbe.html
-->
https://cdrdv2.intel.com/v1/dl/getContent/621661 (downloads a pdf...)

Has information about the different revisions. The document notes the branding string would be either Intel(R) Ethernet Controller I225-LM or Intel(R) Ethernet Controller (2) I225-LM or Intel(R) Ethernet Controller (3) I225-LM. I'm not sure if this information would be accurately reflected by dmesg in freebsd, but dumping some of the output from dmesg looks like:

igc1: <Intel(R) Ethernet Controller I225-LM> mem 0x76200000-0x762fffff,0x76300000-0x76303fff at device 0.0 on pci4

I'm not smart enough to know if the dmesg output is what I'm looking for, though.

TripleZ

Ack, no, sorry. Reinstalled windows and ran the nvm utility referenced here: https://forum.netgate.com/topic/159994/intel-ethernet-controller-i225-lm-support/137

Output:

C:\Windows\system32>C:\Users\Dev\Downloads\mb_driver_intel-i225-firmware-tool\Nvmupdate145\i225\nvmupdatew64e.exe -i -l

Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.35.30.0
Copyright (C) 2013 - 2020 Intel Corporation.

Inventory
[00:045:00:00]: Intel(R) Ethernet Controller (3) I225-LM
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
[00:046:00:00]: Intel(R) Ethernet Controller (3) I225-LM
        Flash inventory started.
        Shadow RAM inventory started.
        Shadow RAM inventory finished.
        Flash inventory finished.
[00:045:00:00]: Intel(R) Ethernet Controller (3) I225-LM
        Vendor                 : 8086
        Device                 : 15F2
        Subvendor              : 1849
        Subdevice              : 0000
        Revision               : 3
        LAN MAC                : A8A159D0C985
        Alt MAC                : A8A159D0C985
        SAN MAC                : 000000000000
        ETrackId               : 80000181
        SerialNumber           : A8A159FFFFD0C985
        NVM Version            : 1.87(1.57)
        PBA                    : G23456-000
        VPD status             : Not set
        VPD size               : 0
        NVM update             : No config file entry
          checksum             : Valid
[00:046:00:00]: Intel(R) Ethernet Controller (3) I225-LM
        Vendor                 : 8086
        Device                 : 15F2
        Subvendor              : 1849
        Subdevice              : 0000
        Revision               : 3
        LAN MAC                : A8A159D0C984
        Alt MAC                : A8A159D0C984
        SAN MAC                : 000000000000
        ETrackId               : 80000181
        SerialNumber           : A8A159FFFFD0C984
        NVM Version            : 1.87(1.57)
        PBA                    : G23456-000
        VPD status             : Not set
        VPD size               : 0
        NVM update             : No config file entry
          checksum             : Valid

Looks like rev 3 to me.

rcoleman-netgate

@triplez it should have no issues there... but I would run a packet capture if you can... focus it on the WAN interface, disconnect and reconnect the cable, see if it asks for a new WAN IP... it probably is, and is getting a response, but I suspect your ISP is PRIQ-tagging their traffic as VLAN0, P7 and that's why you're not getting anything.

stephenw10

That is rev.3 you can see it in the pciconf output:

igc1@pci0:46:0:0:       class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f2 subvendor=0x1849 subdevice=0x0000

But also the issues that applied to were only the i225-V as far as I know so you should be fine i225-LM NICs.

So something else is happening there. Is the dhcpd service even running? Check Status > Sevices.
It should work by default on LAN. It may refuse to start in the event of a conflict though for example.
Check the logs in Status > Logs > DHCP. You should see the service start and clients requesting a lease. Like:

Nov 1 00:42:12 	dhcpd 	92419 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 00:42:12 	dhcpd 	92419 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 00:42:12 	dhcpd 	92419 	All rights reserved.
Nov 1 00:42:12 	dhcpd 	92419 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 00:42:12 	dhcpd 	92419 	Config file: /etc/dhcpdv6.conf
Nov 1 00:42:12 	dhcpd 	92419 	Database file: /var/db/dhcpd6.leases
Nov 1 00:42:12 	dhcpd 	92419 	PID file: /var/run/dhcpdv6.pid
Nov 1 00:42:12 	dhcpd 	92419 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 00:42:12 	dhcpd 	92419 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 00:42:12 	dhcpd 	92419 	All rights reserved.
Nov 1 00:42:12 	dhcpd 	92419 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 00:42:12 	dhcpd 	92419 	Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Nov 1 00:42:12 	dhcpd 	92419 	Bound to *:547
Nov 1 00:42:12 	dhcpd 	92419 	Listening on Socket/6/mvneta1/2a00:23c8:7282:112::/64
Nov 1 00:42:12 	dhcpd 	92419 	Sending on Socket/6/mvneta1/2a00:23c8:7282:112::/64
Nov 1 00:42:12 	dhcpd 	92419 	Server starting service.
Nov 1 00:42:26 	dhcpd 	90650 	DHCPREQUEST for 172.21.16.148 from 5e:f7:c8:ae:82:23 (cedev-3) via mvneta0
Nov 1 00:42:26 	dhcpd 	90650 	DHCPACK on 172.21.16.148 to 5e:f7:c8:ae:82:23 (cedev-3) via mvneta0

Steve

TripleZ

@stephenw10 Yes, I can confirm the service is running. Thank you for pointing me to those logs, I am learning some new terminology.

(I changed my subnet to 192.168.3.0/24 here)

Here is an excerpt from those logs:

Nov 1 01:40:07 	dhcpd 	99893 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 01:40:07 	dhcpd 	99893 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 01:40:07 	dhcpd 	99893 	All rights reserved.
Nov 1 01:40:07 	dhcpd 	99893 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 01:40:07 	dhcpd 	99893 	Config file: /etc/dhcpd.conf
Nov 1 01:40:07 	dhcpd 	99893 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 01:40:07 	dhcpd 	99893 	Database file: /var/db/dhcpd.leases
Nov 1 01:40:07 	dhcpd 	99893 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 01:40:07 	dhcpd 	99893 	PID file: /var/run/dhcpd.pid
Nov 1 01:40:07 	dhcpd 	99893 	All rights reserved.
Nov 1 01:40:07 	dhcpd 	99893 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 01:40:07 	dhcpd 	99893 	Wrote 0 class decls to leases file.
Nov 1 01:40:07 	dhcpd 	99893 	Wrote 0 leases to leases file.
Nov 1 01:40:07 	dhcpd 	99893 	Listening on BPF/igc0/a8:a1:59:d0:c9:85/192.168.3.0/24
Nov 1 01:40:07 	dhcpd 	99893 	Sending on BPF/igc0/a8:a1:59:d0:c9:85/192.168.3.0/24
Nov 1 01:40:07 	dhcpd 	99893 	Sending on Socket/fallback/fallback-net
Nov 1 01:40:07 	dhcpd 	99893 	Server starting service.
Nov 1 01:40:25 	dhcpd 	99893 	DHCPDISCOVER from b0:25:aa:2c:b1:69 via igc0
Nov 1 01:40:26 	dhcpd 	99893 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:29 	dhcpd 	99893 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:29 	dhcpd 	99893 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:33 	dhcpd 	99893 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:33 	dhcpd 	99893 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:42 	dhcpd 	99893 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:42 	dhcpd 	99893 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:49 	dhcpd 	99893 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:49 	dhcpd 	99893 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:53 	dhcpd 	2533 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 01:40:53 	dhcpd 	2533 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 01:40:53 	dhcpd 	2533 	All rights reserved.
Nov 1 01:40:53 	dhcpd 	2533 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 01:40:53 	dhcpd 	2533 	Config file: /etc/dhcpd.conf
Nov 1 01:40:53 	dhcpd 	2533 	Internet Systems Consortium DHCP Server 4.4.2-P1
Nov 1 01:40:53 	dhcpd 	2533 	Database file: /var/db/dhcpd.leases
Nov 1 01:40:53 	dhcpd 	2533 	Copyright 2004-2021 Internet Systems Consortium.
Nov 1 01:40:53 	dhcpd 	2533 	PID file: /var/run/dhcpd.pid
Nov 1 01:40:53 	dhcpd 	2533 	All rights reserved.
Nov 1 01:40:53 	dhcpd 	2533 	For info, please visit https://www.isc.org/software/dhcp/
Nov 1 01:40:53 	dhcpd 	2533 	Wrote 0 class decls to leases file.
Nov 1 01:40:53 	dhcpd 	2533 	Wrote 0 leases to leases file.
Nov 1 01:40:53 	dhcpd 	2533 	Listening on BPF/igc0/a8:a1:59:d0:c9:85/192.168.3.0/24
Nov 1 01:40:53 	dhcpd 	2533 	Sending on BPF/igc0/a8:a1:59:d0:c9:85/192.168.3.0/24
Nov 1 01:40:53 	dhcpd 	2533 	Sending on Socket/fallback/fallback-net
Nov 1 01:40:53 	dhcpd 	2533 	Server starting service.
Nov 1 01:40:54 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 via igc0
Nov 1 01:40:55 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:58 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:40:58 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:06 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:06 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:22 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:22 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:33 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:33 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:37 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:37 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:41 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:41 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:49 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:41:49 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:42:06 	dhcpd 	2533 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 01:42:06 	dhcpd 	2533 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0

So it appears there are offers. I've never used any packet capture techniques, but I assume there are ways to further inspect the traffic on the client and see what it is actually getting. I will look into this.

stephenw10

Yes, indeed it appears the client either never sees the DHCP offer or is rejecting it.

Running a packet capture on the pfSense LAN port should confirm it is being sent at least.
https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/webgui.html

Running a capture on the client directly would show if it's seeing the offers.

Is that laptop connected directly to the LAN port or is there anything in between?

Steve

TripleZ

@stephenw10 Hello again, sorry for the delay.

Yes, the laptop is corrected directly to the LAN port. I did try with a dumb switch in between as well, but behavior was the same. So, running the following tests with the direct connection - my observations...

Packet capture examples from pfsense / LAN / filtered to UDP ports 67, 68

18:15:24.760838 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
18:15:31.645623 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
18:15:38.506824 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
18:15:54.523784 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300

Those look like DHCPOFFERs, right?

Looking at the dhcpd logs around the same time:

Nov 1 18:15:30 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 via igc0
Nov 1 18:15:31 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:15:38 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:15:38 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:15:54 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:15:54 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:26 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:26 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:29 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:29 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:37 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:37 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:54 	dhcpd 	55122 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (LAPTOP) via igc0
Nov 1 18:16:54 	dhcpd 	55122 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (LAPTOP) via igc0

Running wireshark on the client (LAPTOP) around the same time:

17     1.006514     0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0xad5daadb
136    4.741099     0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0xad5daadb
242    12.625480    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0xad5daadb
351    28.641990    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0xad5daadb
368    60.515676    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0x520c9611
372    63.732579    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0x520c9611
376    71.626199    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0x520c9611
379    88.361085    0.0.0.0    255.255.255.255    DHCP    342    DHCP Discover - Transaction ID 0x520c9611

I tried running a packet capture on the client using my existing working router just so I would know what the data should look like (this is now the 192.168.2.0 subnet):

1    0.000000    0.0.0.0    255.255.255.255    DHCP    358    DHCP Request  - Transaction ID 0xd7cb8c86
2    0.005490    192.168.2.1    192.168.2.72    DHCP    342    DHCP ACK      - Transaction ID 0xd7cb8c86

stephenw10

Did you already try disabling hardware checksum offloading? And rebooted to be sure it applied?

Seeing that in a pcap in the igc driver but not at the other end of a directly connected cable implies the hardware is not putting it on the wire for some reason.

Steve

TripleZ

@stephenw10 I did and rebooted multiple times throughout all my testing.

I noticed some generic error message in the windows event view logs:

Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address xxx. The following error occurred: 0x79. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

Which seems...not useful. I tried a completely different windows machine (laptop has a realtek NIC, other machine has an intel NIC) and observed the same behavior. Just to try and rule out some windows issues, I booted a live ubuntu image and experienced the exact same behavior. Can set a manual address and get connected, but DHCP does not work.

pcap (all UDP traffic, might be extraneous things in here) on pfsense LAN:

00:51:11.692951 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 285
00:51:11.693055 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
00:51:12.587322 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 45
00:51:13.264491 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 139
00:51:16.287778 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 285
00:51:16.287871 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
00:51:16.590436 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 45
00:51:40.538343 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 285
00:51:40.538453 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
00:51:40.607481 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 45
00:51:54.490489 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 285
00:51:54.490570 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
00:51:56.306841 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 139
00:51:57.050628 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 285
00:51:57.050703 IP 192.168.3.1.67 > 192.168.3.10.68: UDP, length 300
00:51:57.592485 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 45
00:51:58.339711 IP6 fe80::3ee5:e629:f781:f4ce.5353 > ff02::fb.5353: UDP, length 139

dhcpd logs:

Nov 2 00:49:41 	dhcpd 	89628 	DHCPDISCOVER from b0:25:aa:2c:b1:69 via igc0
Nov 2 00:49:42 	dhcpd 	89628 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:49:46 	dhcpd 	89628 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:49:46 	dhcpd 	89628 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:49:54 	dhcpd 	89628 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:49:54 	dhcpd 	89628 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:50:11 	dhcpd 	89628 	DHCPDISCOVER from b0:25:aa:2c:b1:69 (kubuntu) via igc0
Nov 2 00:50:11 	dhcpd 	89628 	DHCPOFFER on 192.168.3.10 to b0:25:aa:2c:b1:69 (kubuntu) via igc0

To echo what you said, at this point...I think it is some kind of hardware issue. With my limited networking knowledge, it doesn't feel? like this is a pfsense issue. I also tried upgrading to the latest pfsense plus version just to see if anything different would happen - no dice.

There does appear to be a newer version of the NVM for this NIC, though I could not figure out how to get the nvm tool to update (it kept failing with a nondescript error message). I contacted ASRock about this / if they have a way for me to update it, but have yet to hear back. The release notes are as follows:
(in picture form) https://imgur.com/B0LTT74
(or text)

Version 1.68:
• Increment security revision variable in CSS header
• Upgrade PHY FW to 4C08-8754
• Fix LM HW sku value in MAC FW

I doubt it would make a difference, but it's unlikely I could get it updated before my return window on this device is up - and it would be much less stress to simply get a netgate appliance I know would work

TripleZ

Hello again,

I long since returned the unit and got my installation working on another device with no issues. That said, I just (7 months later!) got an update from ASRock that it was in fact a problem on their end. If anyone somehow ends up here via google, it might be good to know that as of 6/2/2023, this is the situation:

We have used isc-dhcp-server (Linux) & Open DHCP Server (Windows) to test in our lab, and we are able to duplicate your symptom.
Test Configuration
BIOS: P1.40
Memory: Corsair CMSX32GX4M2A3200C22
Storage: Kingston A400
OS: Ubuntu / Windows 10 LTSC 2021
We have discovered LAN1 (Intel I225-LM with vPro Essentials) could not work as DHCP server properly.
When we switch to LAN2 (Intel I225-LM without vPro), the client PC could receive DHCPOFFER (assigned IP).
After some further testing, we found the symptom is related to vPro (AMT) function of I225-LM in general.
Currently, we are still co-working with Intel to solve this symptom.
If there is any update about the solution or conclusion, we will inform you as soon as possible.

stephenw10

Hmm, good to know. I wonder what's blocking that....

JimBob Indiana

Nice they confirmed the issue is on their side but gee Intel. With some of the previous issues with rolling out 2.5gb chips one would think they’d make sure to avoid that again. But no……

stephenw10

Mmm, we haven't seen any issues like that on the i225/226 NICs we have. But, yeah....

thundershower71

I think there must be some sort of conflict between AMT & DHCP Server function with I225 NIC.
So far, I couldn't get DHCP Server to work if I225-LM has AMT enabled.
The temporary solution for DHCP Server to work is disabling I225-LM's AMT function.
Not sure if this is also the case with I226 NIC tho.

Richard 1

I have the same ASRock NUC.

How can I disable the AMT function ? On my NUC Bios ?

3 months after having bought this unit, I still cannot use it as I would like and if I don't find a solution, I will resell it.

curiousAboutDHCP

I have the Intel NUC 11 Pro Kit NUC11TNHv70L, which also has a 2.5GB Intel Ethernet Controller I225-LM NIC. I have pfSense installed and have also pulled out my hair for the past three weeks, trying to set up pfSense on Proxmox on the NUC. I've followed all the instructsions for Proxmox, and I've also chatted quite a bit on discord with some experts on Proxmox.

I've set up packet capturing on both clients and server (pfSense), and I'm experiencing the same.

DHCPACK and DHCPOFFER packets are sent from pfSense, but they do not go beyond the network card. They are never received by the client. When I came across this thread, I thought I had my answer. I was using AMT. So I disabled it, but the issue remains.

When I swap DHCP servers to another one on my network, everything works great. When I swap the LAN interface on pfSense to use a USB-Ethernet plugged into the NUC and set up on Proxmox as a Linux Bridge, that also works great.

But using the Intel Ethernet Controller I225-LM does NOT work with pfSense's DHCP Server. I've tried PCI direct. I've tried Linux bridges. I've tried everything.

DHCPACK and DHCPOFFER packets are not received by the client. Something is preventing the packet from going beyond the Intel Ethernet card. There is an issue with this card and pfSense's DHCP Server or with this card and DHCP Server's in general.

I hope someone can figure out why and provide an update/fix.

Richard 1

How did you deactivate the AMT function ?

I have an ASRock 1220p.

Thanks