linux-kernel - Adding neighbor cache entry solely initiated by multicast traffic

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>] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2014 18:53:32 -0700
From:	Bob Richmond <robert.richmond@...enwavereality.com>
To:	linux-kernel@...r.kernel.org
Subject: Adding neighbor cache entry solely initiated by multicast traffic

For a device on the local network that mostly functions as a multicast 
receiver, the only packets a router may see from this client are IGMP 
membership reports. I believe that alone should be enough information to 
establish a neighbor cache entry for it.

A client intending to unicast to the router will first ARP for the 
router's address, and the router will then respond to the ARP AND cache 
the client's address to avoid ARPing for the client's address when 
replying to original packet.

I believe this patch functions in the same spirit of that approach.

Something like this is necessary for a router managing multicast 
subscriptions in userspace using the ipmr API. Such a thing would need 
to know which interface an IGMP membership report came in on, in order 
to establish a vif route for it. Without a netlink message indicating a 
new neighbor for the subscriber's IP address, it can't be known which 
vif to establish the route on.

Is there anything glaringly wrong with this?

View attachment "linux-3.4.91_add_neighbour_on_multicast.patch" of type "text/x-patch" (1700 bytes)