All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com
Cc: intel-wired-lan@lists.osuosl.org
Subject: [Intel-wired-lan] Fw: [Bug 221750] New: igc: Intel I225 silently drops UDP broadcast to port 68 (DHCP) when interface is a bridge member
Date: Wed, 22 Jul 2026 08:46:55 -0700	[thread overview]
Message-ID: <20260722084655.2d190adf@phoenix.local> (raw)

Linux networking does not really use bugzilla, instead use email.

$ ./scripts/get_maintainer.pl drivers/net/ethernet/intel/igc
Tony Nguyen <anthony.l.nguyen@intel.com> (maintainer:INTEL ETHERNET DRIVERS)
Przemek Kitszel <przemyslaw.kitszel@intel.com> (maintainer:INTEL ETHERNET DRIVERS)
Andrew Lunn <andrew+netdev@lunn.ch> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING DRIVERS)
intel-wired-lan@lists.osuosl.org (moderated list:INTEL ETHERNET DRIVERS)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)


Begin forwarded message:

Date: Mon, 13 Jul 2026 16:20:22 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
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: stephen@networkplumber.org
          Reporter: eslopez92@gmail.com
        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.

                 reply	other threads:[~2026-07-22 15:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260722084655.2d190adf@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=przemyslaw.kitszel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.