From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 221470] New: ARP reply received at MAC level but neighbor entry not resolved (Linux 5.15, automotive BSP) for vlan interface
Date: Wed, 6 May 2026 08:43:03 -0700 [thread overview]
Message-ID: <20260506084303.0fd0632b@phoenix.local> (raw)
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.
reply other threads:[~2026-05-06 15:43 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=20260506084303.0fd0632b@phoenix.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox