22.04 How to stop Gratuitous ARP on connect to network?

[&KyT$0P#]

Using Wireshark shows that my 22.04 systems are sending 3 Gratuitous ARP requests when connecting to a network. This doesn't happen in 20.04. How to disable this automatic Gratuitous ARP? If it can't be disabled, how to block it with nftables, without also blocking ARP traffic that's required for the network connection to function?

[#&thj^%]

Not what your after, just information:
Gratuitous ARPs are useful for four reasons:

They can help detect IP conflicts. When a machine receives an ARP request containing a source IP that matches its own, then it knows there is an IP conflict.


They assist in the updating of other machines' ARP table. Clustering solutions utilize this when they move an IP from one NIC to another, or from one machine to another. Other machines maintain an ARP table that contains the MAC associated with an IP. When the cluster needs to move the IP to a different NIC, be it on the same machine or a different one, it reconfigures the NICs appropriately then broadcasts a gratuitous ARP reply to inform the neighboring machines about the change in MAC for the IP. Machines receiving the ARP packet then update their ARP tables with the new MAC.


They inform switches of the MAC address of the machine on a given switch port, so that the switch knows that it should transmit packets sent to that MAC address on that switch port.


Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts. Thus, a gratuitous ARP will tell us that that host just has had a link up event, such as a link bounce, a machine just being rebooted or the user/sysadmin on that host just configuring the interface up. If we see multiple gratuitous ARPs from the same host frequently, it can be an indication of bad Ethernet hardware/cabling resulting in frequent link bounces.

Without knowing all your seeing: https://www.networkdefenseblog.com/post/troubleshooting-wireshark-arp
And I use something like:


To supress ARP on interface eth0 run the following command as root:


ip link set dev eth0 arp off

To turn it back on again:


ip link set dev eth0 arp on

[&KyT$0P#]

Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts. Thus, a gratuitous ARP will tell us that that host just has had a link up event, such as a link bounce, a machine just being rebooted or the user/sysadmin on that host just configuring the interface up.

Thanks 1fallen, this seems descriptive of the behavior I would like to stop. "other local hosts" have no reason to connect to the systems in question or know when I connected to the network.


Without knowing all your seeing:

Sorry, I didn't realise more details were required.

If I configure a 20.04 machine to use DHCP, and connect it to a network, it will only send the DHCP request and that's it.

If I configure a 22.04 machine to use DHCP, and connect it to a network, after it receives the IP from DHCP it then sends what Wireshark shows as 3 Gratuitous ARP ("ARP Announcement") lines, each about 2 seconds apart.

Testing in more detail on 20.04, if I configure the 20.04 machine's IP manually, and connect it to a network, only then does it send the Gratuitous ARP like 22.04. However, with manually configured IP, this Gratuitous ARP doesn't seem quite as...well...gratuitous ;) since where I actually use manual IP configuration, some of the uses of Gratuitous ARP you mentioned could be beneficial.

So getting 22.04 to behave like 20.04 here would be enough of a solution for me.


To supress ARP on interface eth0 run the following command as root:

Wouldn't that disable all ARP?

[#&thj^%]

Wouldn't that disable all ARP?
Yes.
I was referring to your Net Setup. (Without knowing all your seeing: )
I'm picking up a very bad habit of sounding cryptic in my reply's.:(

So getting 22.04 to behave like 20.04 here would be enough of a solution for me.

This will take some thought.

[The Cog]

You might be able to configure it by writing to /proc/sys/net/ipv4/conf/default/arp_notify, or /proc/sys/net/ipv4/conf/eth0/arp_notify.
This page https://sysctl-explorer.net/net/ipv4/arp_notify/ has a link to the very interesting https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
If that works you will want to read this: https://www.cyberciti.biz/faq/making-changes-to-proc-filesystem-permanently/

[#&thj^%]

You might be able to configure it by writing to /proc/sys/net/ipv4/conf/default/arp_notify, or /proc/sys/net/ipv4/conf/eth0/arp_notify.
This page https://sysctl-explorer.net/net/ipv4/arp_notify/ has a link to the very interesting https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
If that works you will want to read this: https://www.cyberciti.biz/faq/making-changes-to-proc-filesystem-permanently/

Nice, @ halogen2 and there's your thinker.

[&KyT$0P#]

You might be able to configure it by writing to /proc/sys/net/ipv4/conf/default/arp_notify, or /proc/sys/net/ipv4/conf/eth0/arp_notify.

Looks like it is already disabled -

$ find /proc/sys -iname arp_notify -exec cat {} \;
0
0
0
0
0


Could NetworkManager be the culprit? I wasn't able to compile focal version of NetworkManager on 22.04 for testing, but I was able to compile and run jammy version of NetworkManager on 20.04 -

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal
$ apt-cache policy network-manager
network-manager:
Installed: 1.36.4-2ubuntu1
Candidate: 1.36.4-2ubuntu1
Version table:
*** 1.36.4-2ubuntu1 100
100 /var/lib/dpkg/status
1.22.10-1ubuntu2.3 500
[snipped]
And with this I get the unwanted Gratuitous ARP behavior on 20.04 :-k

[#&thj^%]

If looks walks and quack's like a duck=Duck
EDIT: You peaked my curiosity with this, been running wireshark for a few minutes now the only showing ARP was:

120 109.028420599 SeikoEps_27:b1:f5 Broadcast ARP 60 ARP Announcement for 192.168.1.XXX<sniped>
this was run on Arch

Name : networkmanager
Version : 1.36.4-1
Description : Network connection manager and user applications
Architecture : x86_64
URL : https://networkmanager.dev/
Licenses : GPL
Groups : None
Provides : None
Depends On : libnm iproute2 wpa_supplicant libmm-glib libnewt libndp
libteam curl bluez-libs libpsl audit
mobile-broadband-provider-info
Optional Deps : polkit: let non-root users control networking [installed]
dnsmasq: connection sharing [installed]
nftables: connection sharing [installed]
iptables: connection sharing [installed]
bluez: Bluetooth support [installed]
ppp: dialup connection support [installed]
modemmanager: cellular network support [installed]
iwd: wpa_supplicant alternative [installed]
dhclient: alternative DHCP client [installed]
dhcpcd: alternative DHCP client
openresolv: alternative resolv.conf manager [installed]
firewalld: firewall support [installed]
Required By : network-manager-applet

EDIT#2: Tried on Jammy in a kvm and I see 8 and counting ARP's now.

[&KyT$0P#]

If looks walks and quack's like a duck=Duck
...
EDIT#2: Tried on Jammy in a kvm and I see 8 and counting ARP's now.

Appreciate the input. So I tried to dig deeper into NetworkManager and may have found some of the relevant code. This change to jammy NetworkManager seems to stop the Gratuitous ARP completely -

diff --git a/src/n-acd/src/n-acd.c b/src/n-acd/src/n-acd.c
--- a/src/n-acd/src/n-acd.c
+++ b/src/n-acd/src/n-acd.c
@@ -476,6 +476,7 @@ int n_acd_raise(NAcd *acd, NAcdEventNode **nodep, unsigned int event) {
}

int n_acd_send(NAcd *acd, const struct in_addr *tpa, const struct in_addr *spa) {
+ return 0;
struct sockaddr_ll address = {
.sll_family = AF_PACKET,
.sll_protocol = htobe16(ETH_P_ARP),

Unfortunately I don't know how to use this information to find a solution (or conclusive evidence that this can't be disabled), I'm not well versed in C/C++ at all and was unable to understand the code enough to get anywhere further.

(To be clear, I only did this for investigating/testing. Patching NetworkManager source is not a reasonable solution for this in my view. And I would not trust a patch like the one above in a production environment!)

Any insight based on this finding?

[The Cog]

Sorry, halogen2. That's deeper (or higher depending on your outlook) than I can manage.

You might look at using wicd instead of Network Manager. I used to remove Network Manager and use wicd years ago, before Network Manager worked reliable enough. Eventually NM got more tolerable and replacing it with wicd every time I reinstalled stopped being so necessary.

[&KyT$0P#]

Thanks for the suggestion The Cog. Unfortunately wicd is only available for 18.04 (https://packages.ubuntu.com/bionic/wicd) and older (https://launchpad.net/ubuntu/+source/wicd).

[#&thj^%]

@h2 see if this has any possibility's: https://linux-audit.com/filtering-arp-traffic-with-linux-arptables/

[&KyT$0P#]

How to match only Gratuitous ARP in a nftables arp rule, without knowing what IP address the machine will be assigned?

[#&thj^%]

This has become an obsesion now (with me), I have from time to time also used "arping"
the more I dig the more conviced I become, this is configured in net device. (more to come on that)

For now though without killing your internet, I just now used:


sudo arping -I eth0 -q -f 192.168.1.1
defines on that command:

Usage:
arping [options] <destination>

Options:
-f quit on first reply
-q be quiet
-b keep on broadcasting, do not unicast
-D duplicate address detection mode
-U unsolicited ARP mode, update your neighbours
-A ARP answer mode, update your neighbours
-V print version and exit
-c <count> how many packets to send
-w <timeout> how long to wait for a reply
-i <interval> set interval between packets (default: 1 second)
-I <device> which ethernet device to use
-s <source> source ip address
<destination> dns name or ip address

For more details see arping(8).

EDIT: 1 hour after that command above:

sudo arping -I eth0 -c 3 192.168.100.1
ARPING 192.168.100.1 from 192.168.1.175 eth0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)



Dang I forgot to mention I update my standards after install.


cd /usr/share/arp-scan
sudo wget http://standards.ieee.org/develop/regauth/oui/oui.txt
sudo wget http://standards.ieee.org/develop/regauth/iab/iab.txt
no need for anything else it reads them just fine form get command.

[#&thj^%]

halogen2 I no longer have the Gratuitous ARP showing in my kvm on Jammy.

My results will differ from yours if your router is supplied by your ISP.
for that you may need to contact them.
Mine is a linux based router, opnsense.
I just added "arp_ignore" kernel network parameters via grub.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash arp_ignore"


arp -a
OPNsense.localdomain (192.168.1.1) at <snip> [ether] on enp1s0

[&KyT$0P#]

Unfortunately adding arp_ignore boot parameter as shown had no effect here :(

Regarding arping, do you use iputils-arping package or arping package?

[#&thj^%]

apt policy arping
arping:
Installed: 2.22-1
Candidate: 2.22-1
Version table:
*** 2.22-1 500
500 http://us.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status

which will bring in libnet1 && arping is part of iputils package.
I knew the difference's were in the "net device" even router.
I can block mine through the firewall of my router as well.

[#&thj^%]

How to match only Gratuitous ARP in a nftables arp rule, without knowing what IP address the machine will be assigned?
spent yesterday playing around with these as well: https://man7.org/linux/man-pages/man8/ebtables.8.html
some possibles there.

[&KyT$0P#]

ebtables' --arp-gratuitous option looked promising, but use of that option just ends up translated into a nftables comment in a bridge table.

So I tried further experimenting with nftables. And it turns out even overkill rulesets like this don't stop them -

$ sudo nft list ruleset
table arp filter {
chain OUTPUT {
type filter hook output priority filter; policy drop;
}
}
:shock: :o
Am I incorrectly using nftables arp filtering? Or are these Gratuitous ARPs deliberately circumventing nftables because they're super important for some reason?

[#&thj^%]

So I tried further experimenting with nftables. And it turns out even overkill rulesets like this don't stop them -
Am I incorrectly using nftables arp filtering? Or are these Gratuitous ARPs deliberately circumventing nftables because they're super important for some reason?
IJDK, ebtables - Ethernet bridge frame table administration (nft-based)

BUGS top

The version of ebtables this man page ships with does not support
the broute table. Also there is no support for string match.
Further, support for atomic-options (--atomic-file, --atomic-
init, --atomic-save, --atomic-commit) has not been implemented,
although ebtables-save and ebtables-restore might replace them
entirely given the inherent atomicity of nftables. Finally, this
list is probably not complete.

going to look at the diff's you noted in an older post.

EDIT: one diff I see:

gratuitous ARP (GARP) message, is usually broadcast as an ARP request containing the SPA in the target field (TPA=SPA), with THA set to zero. An alternative way is to broadcast an ARP reply with the sender's SHA and SPA duplicated in the target fields (TPA=SPA, THA=SHA).

The ARP request and ARP reply announcements are both standards-based methods,[9][10] but the ARP request method is preferred.[11] Some devices may be configured for the use of either of these two types of announcements.[12]

[&KyT$0P#]

Did some more digging and eventually found a NetworkManager setting ipv4.dad-timeout that looked maybe related, but it has no effect. So in case this behavior is a bug, I tried latest NetworkManager 1.38 rc

$ /usr/sbin/NetworkManager --version
1.37.91
Same behavior, so no bug.

The more I dig into this, the more this is looking like something I shouldn't be messing with:


I originally wanted to stop this for the reasons noted in post #3 (https://ubuntuforums.org/showthread.php?t=2474398&p=14092934&viewfull=1#post14092934). But I'm finding that the DHCP request already sends all the information that's in these Gratuitous ARP, plus more, to all the same places.

These Gratuitous ARP are not used for the purpose I want to stop, but for address conflict detection. In fact, if I'm reading right this exact behavior is a RFC (https://www.rfc-editor.org/rfc/rfc5227).

This behavior is not specific to NetworkManager on 22.04. Other (non-Linux) OSes also send Gratuitous ARP after DHCP connection.

As noted above, it seems nftables arp filtering can't block these Gratuitous ARP?

NetworkManager release notes between 20.04 version and 22.04 version suggest the 20.04 behavior may have been a bug.


At this point I'm thinking maybe I would best leave this alone. :-|