Can not get DHCP leases on new intel I225-LM based machine
-
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.htmlRunning 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
-
@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 300Those 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 igc0Running 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 0x520c9611I 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 -
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
-
@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 139dhcpd 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 igc0To 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 FWI 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
-
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. -
Hmm, good to know. I wonder what's blocking that....
-
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……
-
Mmm, we haven't seen any issues like that on the i225/226 NICs we have. But, yeah....
-
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. -
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.
-
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.
-
How did you deactivate the AMT function ?
I have an ASRock 1220p.
Thanks
-
@Richard-1
I think AMT needs to be disabled by SMBus or CSME settings in order to get DHCP Server working.
You should contact ASRock for further assistance. -
@curiousAboutDHCP I have exactly the same issue with I226 NIC. Have you found any solution to this problem?
-
What chip exactly?
I'm not aware of any solution for this in pfSense though. BIOS/firmware fix only as far as I know.
-
@stephenw10 I'm now having the exact same problem on a minisforum ms-01. "i226-LM" and from what i read its the same with the other port on my computer "i226-V".
I think this is a issue in Linux kernel driver "igc". In my case i run pfSense in Proxmox 8.2 with kernel "6.8.8-3-pve".
But i don't know that much really i'm not a programmer.. or even close to it..
https://www.intel.com/content/www/us/en/products/sku/210595/-intel-ethernet-controller-i226lm/downloads.html
Might be related. What if it could be fixed with a driver in pfSense? I don't understand it at all really but trying to learn.. I don't even know how to try that later version or to figure out what it's dependencies are.
-
@thewho said in Can not get DHCP leases on new intel I225-LM based machine:
I'm now having the exact same problem on a minisforum ms-01.
Yup it's a known issue on that device, there's a thread here detailing it. One of those NICs has the Intel vPro OOB access enabled on it and that somehow prevents DHCP working. Try the other i226 NIC.
-
@stephenw10 Yeah! Sorry for that! i ended up using a x710 also on the board for LAN.
Still having lot's of weird issues but can't really what they are more then that they come and goes... might be a really unstable NIC..
-
Anything logged?
