On 22/07/2026 18:46, Stephen Hemminger wrote:
Linux networking does not really use bugzilla, instead use email.
$ ./scripts/get_maintainer.pl drivers/net/ethernet/intel/igc
Tony Nguyen <[email protected]> (maintainer:INTEL ETHERNET DRIVERS)
Przemek Kitszel <[email protected]> (maintainer:INTEL ETHERNET
DRIVERS)
Andrew Lunn <[email protected]> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <[email protected]> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <[email protected]> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <[email protected]> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <[email protected]> (maintainer:NETWORKING DRIVERS)
[email protected] (moderated list:INTEL ETHERNET DRIVERS)
[email protected] (open list:NETWORKING DRIVERS)
Begin forwarded message:
Date: Mon, 13 Jul 2026 16:20:22 +0000
From: [email protected]
To: [email protected]
Subject: [Bug 221750] New: igc: Intel I225 silently drops UDP broadcast to port
68 (DHCP) when interface is a bridge member
https://bugzilla.kernel.org/show_bug.cgi?id=221750
Bug ID: 221750
Summary: igc: Intel I225 silently drops UDP broadcast to port
68 (DHCP) when interface is a bridge member
Product: Networking
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Other
Assignee: [email protected]
Reporter: [email protected]
Regression: No
## Description
When an Intel I225-LM NIC using the igc driver is added as a member of a Linux
bridge, UDP broadcast packets with destination port 68 (DHCP client port) are
silently dropped at the TX path. The kernel queues the packet for transmission
(visible via AF_PACKET capture on the interface showing PACKET_OUTGOING), but
the frame never appears on the physical wire.
All other UDP broadcast ports (e.g., port 9998) transmit correctly through the
same bridge, same interface, same code path. Only destination port 67/68 (DHCP)
is affected.
This breaks any DHCP server (e.g., dnsmasq) running on the bridge host, as DHCP
offers never reach clients.
### Keywords
igc, I225, bridge, DHCP, broadcast, TX drop, dnsmasq
### Kernel version
Linux version 6.8.0-134-generic (Ubuntu 24.04)
Also tested: 6.17.0-35-generic (Ubuntu 24.04 HWE) - same behavior
### How to reproduce
1. System: Supermicro X13SAZ-F with Intel I225-LM (PCI 8086:15f2), igc driver
2. Create a Linux bridge and enslave the igc interface:
ip link add br-fvn type bridge
ip link set eno1 master br-fvn
ip addr add 172.31.0.3/16 dev br-fvn
ip link set br-fvn up
3. Run dnsmasq as DHCP server on br-fvn:
dnsmasq --interface=br-fvn
--dhcp-range=172.31.100.1,172.31.254.255,255.255.0.0,12h --dhcp-authoritative
4. Connect a DHCP client to eno1 (directly or via switch)
5. Observe: dnsmasq logs show DHCPDISCOVER received and DHCPOFFER sent, but the
client never receives the offer
### Verification that the bug is interface-specific
- Replacing eno1 (igc, I225-LM) with a USB ethernet adapter (r8152, RTL8153) in
the same bridge: DHCP works immediately
- Using an Intel I210 NIC (igb driver) in the same bridge on identical kernel:
DHCP works
- Sending UDP broadcast to port 9998 from the same bridge via the same igc
interface: packets arrive at client
- Sending UDP broadcast to port 68 from the same bridge via the same igc
interface: packets never arrive
- AF_PACKET raw capture on eno1 (host side) shows the DHCP offer as
PACKET_OUTGOING (type=4), confirming the kernel hands it to the driver, but the
frame never hits the wire
- Wireshark/tcpdump on the client confirms zero DHCP offers received
### Environment
Processor: Intel Core i9-14900K
Board: Supermicro X13SAZ-F
NIC: Intel I225-LM (8086:15f2, subsystem 15d9:15f2)
Driver: igc
Firmware: 1073:8754
Bus: 0000:01:00.0 (PCIe x1, 5.0 GT/s)
OS: Ubuntu Core 24 (snap-based)
### Other notes
- ethtool -K br-fvn tx-checksum-ip-generic off was tested - no change
- bridge-nf-call-iptables=0 was tested - no change
- br_netfilter module unloaded - no change
- net.ipv4.ip_forward=1 was tested - no change
- No iptables, nftables, or ebtables rules present
- No eBPF/XDP programs attached
- The igb driver (Intel I210) does NOT exhibit this behavior on the same kernel
Thank you for the detailed analysis and information.
I've done some digging and it looks like an issue that has been fixed in
firmware.
Your environment shows I225-LM Firmware: 1073:8754 which indicates
version 1.73. I believe the fix to be available starting from version 1.91.
It may require an update to the AMT FW as well.
Both should be distributed by the motherboard vendor. I suggest to
inquire with Supermicro whether they have a FW update for your device.
It may be included in the full BIOS/BMC/Bundle that they offer.
--Dima
