[Intel-wired-lan] Fw: [Bug 221750] New: igc: Intel I225 silently drops UDP broadcast to port 68 (DHCP) when interface is a bridge member

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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.