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 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.