netdev - arp.c: external usage

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]

Message-ID: <20120524160715.GC6454@ritirata.org>
Date:	Thu, 24 May 2012 18:07:16 +0200
From:	Antonio Quartulli <ordex@...istici.org>
To:	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: arp.c: external usage

Hello,

I'm writing here because we, as batman-adv developers, wanted to add a new
feature called D.A.T. (Distributed ARP Table) to the batman-adv module, but we
encountered some issues.

Going into the details, DAT is a DHT (Distributed Hash Table) based ARP cache and
for its purposes it requires a local storage for classic ARP entries. In order
to avoid code duplication, we decided to "consistently" use the local ARP table
provided by the kernel.

These are the operations we wanted to perform on the kernel ARP table:
- Add a new entry
- Check if an entry is present
- Change the default entry timeouts

The code we provided used the following functions provided by the ARP/neighbour
layer API:

- neigh_lookup()
- neigh_release()
- arp_create()

Other than that the code was (necessarily) using "arp_tbl" and was modifying the
timeouts by directly accessing members of "(struct in_device)->arp_parms".

The patches adding the feature has been rejected by David Miller because he
stated that the ARP/neighbour code is going to be heavily modified and for this
reason he wanted to avoid to add other code depending on those components.

You find the emails where David rejected our code here:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-April/006921.html
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-May/006925.html

The last email from David stated that we must not use ARP/neighbour layer
internals, but all the functions we are using are correctly exported by the
ARP/neigh layer and so are part of the API that we are using.

At this point we are stuck and we don't know how to proceed.
From David's last
email I personally got the impression that we should not use the ARP/neigh layer
at all and so we should implement our own ARP backend (which means duplicating a
lot of code). However this does not sound like a good solution.

If changes for the ARP/neigh layer are already planned, is it possible to know
whether we will be able to perform the aforementioned operations by means of the
new API? Or, do you have any suggestion on how to perform the needed operations
without directly touching the ARP/neigh layer?

Thank you in advance,
	Best Regards

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Content of type "application/pgp-signature" skipped