[B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[Linus Lüssing]

A gratuitous ARP Reply has the following format (example):

Sender MAC: 00:12:34:56:78:9A
Sender IP:  192.168.2.3
Target MAC: FF:FF:FF:FF:FF:FF
Target IP:  192.168.2.3

A gratuitous ARP Reply is commonly used to update an ARP table in the
network in an unsolicited way. Here, the host with the MAC address
00:12:34:56:78:9A announces that it is now the owner of 192.168.2.3.
Gratuitous ARP Replies are usually used for redundancy or for IP address
handovers between hosts.

So far, gratuitous ARP Replies were ignored for DAT processing as it
contains a broadcast MAC address. This patch changes this and allows
snooping such ARP messages, too.

Special care needs to be taken with the target MAC, to not accidentally
add this broadcast MAC to the DAT cache.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

---
Gratuitous ARP Replies were ignored since this commit:

ab361a9ccc5 ("batman-adv: filter ARP packets with invalid MAC addresses in DAT")

Daniel Ehlers is currently working on a distributed DHCP server for mesh
networks. For cases like these it would be helpful if userspace programs
were able to add entries to the DAT, too. Sending gratuitous ARP Replies
would be one easy way for userspace tools to do so.

This patch was verified in VMs with gratuitous ARP Replies generated via
"mausezahn". Sending such packets with a 00:00:00:00:00:00 ethernet
frame destination address even allows updating the DAT without actually
broadcasting the original frame into the mesh.

[0]: https://github.com/sargon/ddhcpd,
[1]: https://media.freifunk.net/search/?q=ddhcp
---
 net/batman-adv/distributed-arp-table.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index 310a4f35..c8923c7d 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -373,9 +373,12 @@ batadv_dat_entry_hash_find(struct batadv_priv *bat_priv, __be32 ip,
 static void batadv_dat_entry_add(struct batadv_priv *bat_priv, __be32 ip,
 				 u8 *mac_addr, unsigned short vid)
 {
-	struct batadv_dat_entry *dat_entry;
+	struct batadv_dat_entry *dat_entry = NULL;
 	int hash_added;
 
+	if (is_multicast_ether_addr(mac_addr))
+		goto out;
+
 	dat_entry = batadv_dat_entry_hash_find(bat_priv, ip, vid);
 	/* if this entry is already known, just update it */
 	if (dat_entry) {
@@ -1117,8 +1120,7 @@ static u16 batadv_arp_get_type(struct batadv_priv *bat_priv,
 	/* don't care about the destination MAC address in ARP requests */
 	if (arphdr->ar_op != htons(ARPOP_REQUEST)) {
 		hw_dst = batadv_arp_hw_dst(skb, hdr_size);
-		if (is_zero_ether_addr(hw_dst) ||
-		    is_multicast_ether_addr(hw_dst))
+		if (is_zero_ether_addr(hw_dst))
 			goto out;
 	}
 
-- 
2.11.0

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[Marek Lindner]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Thursday, 14 February 2019 23:51:00 HKT Linus Lüssing wrote:
> So far, gratuitous ARP Replies were ignored for DAT processing as it
> contains a broadcast MAC address. This patch changes this and allows
> snooping such ARP messages, too.

> Gratuitous ARP Replies were ignored since this commit:
> ab361a9ccc5 ("batman-adv: filter ARP packets with invalid MAC addresses in 
DAT")

You're kind enough to mention when the filter was introduced but fail to 
explain why the filter introduced in the past was has outlived its usefulness 
or how the new behavior addresses the  previous concerns.

Cheers,
Marek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[Linus Lüssing]

On Fri, Feb 15, 2019 at 12:16:31AM +0800, Marek Lindner wrote:
> On Thursday, 14 February 2019 23:51:00 HKT Linus Lüssing wrote:
> > So far, gratuitous ARP Replies were ignored for DAT processing as it
> > contains a broadcast MAC address. This patch changes this and allows
> > snooping such ARP messages, too.
> 
> > Gratuitous ARP Replies were ignored since this commit:
> > ab361a9ccc5 ("batman-adv: filter ARP packets with invalid MAC addresses in 
> DAT")
> 
> You're kind enough to mention when the filter was introduced but fail to 
> explain why the filter introduced in the past was has outlived its usefulness 
> or how the new behavior addresses the  previous concerns.

That patch added filtering for both zero and broadcast MAC
addresses. While the original premise is correct - we do not want
those addresses in the DAT, the assumption that a broadcast MAC
address as ARP target MAC address were invalid, is wrong.
Gratuitous ARP Replies are valid packets.

So that patch was a bit too strict in that regard, I think. For
gratuitous ARP it's enough to ignore the (Target MAC/Target IP)
pair. Snooping the (Sender MAC/Sender IP) should be fine.

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[Antonio Quartulli]

[-- Attachment #1.1: Type: text/plain, Size: 1533 bytes --]

Hi,

On 15/02/2019 03:49, Linus Lüssing wrote:
> On Fri, Feb 15, 2019 at 12:16:31AM +0800, Marek Lindner wrote:
>> On Thursday, 14 February 2019 23:51:00 HKT Linus Lüssing wrote:
>>> So far, gratuitous ARP Replies were ignored for DAT processing as it
>>> contains a broadcast MAC address. This patch changes this and allows
>>> snooping such ARP messages, too.
>>
>>> Gratuitous ARP Replies were ignored since this commit:
>>> ab361a9ccc5 ("batman-adv: filter ARP packets with invalid MAC addresses in 
>> DAT")
>>
>> You're kind enough to mention when the filter was introduced but fail to 
>> explain why the filter introduced in the past was has outlived its usefulness 
>> or how the new behavior addresses the  previous concerns.
> 
> That patch added filtering for both zero and broadcast MAC
> addresses. While the original premise is correct - we do not want
> those addresses in the DAT, the assumption that a broadcast MAC
> address as ARP target MAC address were invalid, is wrong.
> Gratuitous ARP Replies are valid packets.
> 
> So that patch was a bit too strict in that regard, I think. For
> gratuitous ARP it's enough to ignore the (Target MAC/Target IP)
> pair. Snooping the (Sender MAC/Sender IP) should be fine.
> 

Is there any situation where an OS would reject a gracious ARP? Or are
they always blindly accepted and processed accordingly?
If they have any protection against any misuse, I guess batman-adv
should try to do the same.

Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: allow snooping gratuitous ARP Replies

[Linus Lüssing]

Hi Antonio,

On Fri, Feb 15, 2019 at 04:36:08PM +1000, Antonio Quartulli wrote:
> Is there any situation where an OS would reject a gracious ARP? Or are
> they always blindly accepted and processed accordingly?
> If they have any protection against any misuse, I guess batman-adv
> should try to do the same.

I have played some more with gratuitous ARPs and this is what I
could find out:

sysfs, /proc/sys/net/ipv4/conf/<iface>/*arp*:

drop_gratuitous_arp = 0 (default)
arp_accept = 0 (default)
-> no new address added via gratuitous ARP
   cmp.: https://elixir.bootlin.com/linux/v4.20.10/source/net/ipv4/arp.c#L872
-> but existing entries are updated

drop_gratuitous_arp = 1:
-> grat. ARP ignored completely
   cmp.: https://elixir.bootlin.com/linux/v4.20.10/source/net/ipv4/arp.c#L776

drop_gratuitous_arp = 0 (default)
arp_accept = 1
-> grat. ARP Reply updates existing entries and creates new ones


Also, I noticed that using a zero MAC address for the ethernet header
destination did not work. Even if setting promisc-mode on the veth
in its extra network namespace interface, the neighbor table would
not be populated. Using the broadcast MAC for the ethernet header
(and arp_accept = 1) worked, though. But would defeat the idea
of using gratuitous ARP to populate the DHT without flooded
messages. I wasn't able to spot where the ethernet destination is
checked yet.

Regards, Linus