Fw: [Bug 221470] New: ARP reply received at MAC level but neighbor entry not resolved (Linux 5.15, automotive BSP) for vlan interface

Fw: [Bug 221470] New: ARP reply received at MAC level but neighbor entry not resolved (Linux 5.15, automotive BSP) for vlan interface

[Stephen Hemminger]

Begin forwarded message:

Date: Wed, 06 May 2026 05:29:26 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
Subject: [Bug 221470] New: ARP reply received at MAC level but neighbor entry not resolved (Linux 5.15, automotive BSP) for vlan interface


https://bugzilla.kernel.org/show_bug.cgi?id=221470

            Bug ID: 221470
           Summary: ARP reply received at MAC level but neighbor entry not
                    resolved (Linux 5.15, automotive BSP) for vlan
                    interface
           Product: Networking
           Version: 2.5
          Hardware: ARM
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: IPV4
          Assignee: stephen@networkplumber.org
          Reporter: rajkumar.veer@harman.com
        Regression: No

Observed behavior: -
During a system suspend–resume cycle, ARP requests are transmitted successfully
from the target. Corresponding ARP replies are continuously received at the
EMAC/MAC level, as confirmed through driver debug logs and hardware RX
statistics.
However, the ARP entry is not being resolved in the kernel neighbor table (ip
neigh), resulting in failure of communication on a specific VLAN interface.
This issue is sporadic and observed only on a particular VLAN interface.
Recovery currently requires a full reboot of the system to restore proper ARP
functionality for particular vlan interface

Environment: - Kernel version: Linux 5.15.x (vanilla, with automotive BSP
integrations)
Architecture: ARM64 & Exynosv920 soc
Ethernet MAC driver: Sxgmac EMAC controller
PHY: Macsec marvell phy/fixed phy switch  
Network stack: mainline Linux networking stack

What we verified: - ARP reply frame is valid and well formed.
Destination MAC matches the interface MAC.
No RX errors or CRC issues at the hardware level.
ARP reply is visible via driver-level logging but not via tcpdump.
Neighbor entry remains in INCOMPLETE state.

Questions: -
Are there any known issues in Linux 5.15 where ARP replies are dropped before
reaching the neighbor subsystem?
Could RX offloading, VLAN filtering, checksum offload, or NAPI GRO/LRO affect
ARP processing in this scenario?
Has anyone encountered similar issues on automotive BSPs or embedded Ethernet
MAC drivers?

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

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