From: Stephen Hemminger <stephen@networkplumber.org>
To: Etienne Buira <etienne.buira@free.fr>
Cc: davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Bug] Linux sends poisonous ARP replies on ethernet
Date: Mon, 18 Nov 2024 17:49:10 -0800 [thread overview]
Message-ID: <20241118174910.7fe410bc@hermes.local> (raw)
In-Reply-To: <ZzuuSDQZux8uof5O@Z926fQmE5jqhFMgp6>
On Mon, 18 Nov 2024 22:14:48 +0100
Etienne Buira <etienne.buira@free.fr> wrote:
> Hi all,
>
> I found problematic behaviours in linux network stack, which all look
> so related i make a single bug-report.
>
> The underlying bug(s) might be ancient (i previously had strange
> behaviours that could be caused by this), therefore fixes should
> probably find their way to stable@vger.kernel.org.
>
> The configuration:
> Two boxes are present on a dedicated virtual hub, both run
> linux-torvalds b5a24181e461e8bfa8cdf35e1804679dc1bebcdd configured with
> attached linux.config file and untainted, under qemu (Gentoo's version
> 8.2.3) as kvm guests using virtio NICs.
>
> box1:
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> valid_lft forever preferred_lft forever
> 2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:16:3e:00:00:04 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.1/24 brd 10.0.1.255 scope global nic0
> valid_lft forever preferred_lft forever
> 3: nic1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:16:3e:00:00:01 brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.1/24 brd 10.0.0.255 scope global nic1
> valid_lft forever preferred_lft forever
> 4: nic2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:16:3e:00:00:02 brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.2/24 brd 10.0.0.255 scope global nic2
> valid_lft forever preferred_lft forever
>
> box2:
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> valid_lft forever preferred_lft forever
> 2: nic3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:16:3e:00:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.3/24 brd 10.0.0.255 scope global nic3
> valid_lft forever preferred_lft forever
>
>
>
> The problem i found is that linux replies to ARP requests not directed
> at it, this behaviour is not complying with RFC826:
> box2# arping -c 5 10.0.0.2 -I nic3
> ARPING 10.0.0.2 from 10.0.0.3 nic3
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:04] 2.285ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:01] 2.357ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 2.368ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.598ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.771ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.600ms
> Unicast reply from 10.0.0.2 [00:16:3e:00:00:02] 0.627ms
> Sent 5 probe(s) (0 broadcast(s))
> Received 7 response(s) (0 request(s), 0 broadcast(s))
>
> Here, all box1's NICs have replied with their own ethernet address(!),
> including 00:16:3e:00:00:04 which is not even on the same IP network.
>
> Unfortunately, i cannot afford to get familiar enough with linux's
> network stack to fix it without sponsorship.
>
> Best wishes.
>
It is not a bug.
Linux uses the weak host model https://en.wikipedia.org/wiki/Host_model
You can control how ARP is handled via the arp_ignore sysctl as
documented here:
https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
prev parent reply other threads:[~2024-11-19 1:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 21:14 [Bug] Linux sends poisonous ARP replies on ethernet Etienne Buira
2024-11-19 1:49 ` Stephen Hemminger [this message]
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=20241118174910.7fe410bc@hermes.local \
--to=stephen@networkplumber.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=etienne.buira@free.fr \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).