netdev - Fw: [Bug 219766] New: Garbage Ethernet Frames

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250210084931.23a5c2e4@hermes.local>
Date: Mon, 10 Feb 2025 08:49:31 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Subject: Fw: [Bug 219766] New: Garbage Ethernet Frames

Not really enough information to do any deep analysis but forwarding to netdev
anyway as it is not junk.

Begin forwarded message:

Date: Sun, 09 Feb 2025 12:24:32 +0000
From: bugzilla-daemon@...nel.org
To: stephen@...workplumber.org
Subject: [Bug 219766] New: Garbage Ethernet Frames

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

            Bug ID: 219766
           Summary: Garbage Ethernet Frames
           Product: Networking
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Other
          Assignee: stephen@...workplumber.org
          Reporter: fmei@....com
        Regression: No

I am currently troubleshooting a very strange problem which appears when
upgrading Kernel 6.6.58 to 6.6.60. The kernel version change is part of a
change of talos linux (www.talos.dev) from 1.8.2 to 1.8.3.

We are running this machines at hetzner - a company which is providing server
hosting. they complain that we are using mac addresses which are not allowed
(are not the mac addresses of the physical nic)

In the investigation of the problem I did tcpdumps on the physical adapters and
captured this suspicious ethernet frames. The frames do neither have a known
ethertype, nor do they have a mac address of a known vendor or a known virtual
mac address range. They seem garbage to me. Below an example. More can be found
in the github issue. This frames are not emitted very often and the systems are
operating normally. If I would not be informed by the hosting provider I would
not have noticed it at all.

I also tried to track it down to a specific hardware (r8169), but we have the
same problem with e1000e.

I checked the changelogs of the two kernel versions (6.6.59 & 6.6.60) and
noticed there were some changes which could be the problem, but I simply do not
have the experience for it.

Can anybody check the changelog of the 2 versions and see if there is a change
which might cause the problem? Can anybody give me a hint how to track it down
further?

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp9s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:07:02.329668 20:00:40:11:18:fb > 45:00:00:44:f4:94, ethertype Unknown
(0x58c6), length 68:
        0x0000:  8dda 74ca f1ae ca6c ca6c 0098 969c 0400  ..t....l.l......
        0x0010:  0000 4730 3f18 6800 0000 0000 0000 9971  ..G0?.h........q
        0x0020:  c4c9 9055 a157 0a70 9ead bf83 38ca ab38  ...U.W.p....8..8
        0x0030:  8add ab96 e052                           .....R

Issue with more information: https://github.com/siderolabs/talos/issues/9837

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

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