netdev - Re: [B.A.T.M.A.N.] [PATCH 06/15] batman-adv: Distributed ARP Table

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

Message-ID: <20120523214802.GA12222@pandem0nium>
Date:	Wed, 23 May 2012 23:48:02 +0200
From:	Simon Wunderlich <simon.wunderlich@...03.tu-chemnitz.de>
To:	David Miller <davem@...emloft.net>
Cc:	b.a.t.m.a.n@...ts.open-mesh.org, netdev@...r.kernel.org,
	Marek Lindner <lindner_marek@...oo.de>
Subject: Re: [B.A.T.M.A.N.] [PATCH 06/15] batman-adv: Distributed ARP Table
 - add snooping functions for ARP messages

Hello David, 

we are a little bit in a pinch here - the DAT feature sent with this
patchset was developed for a long time, and we need your decision to move on
as more and more patches depend on it:

 * should we rewrite DAT to use our own ARP table/backend or
 * can we use the ARP neighbor table in another way, maybe after your changes?

We thought that re-using existing infrastructure would be smarter, but if
you disagree, please tell us so - we would like to get this feature finally
upstream and need your input to make the neccesary changes.

Thanks
	Simon


On Thu, May 17, 2012 at 07:53:54PM +0800, Marek Lindner wrote:
> 
> David,
> 
> > On Tuesday, May 01, 2012 08:59:04 David Miller wrote:
> > > From: Antonio Quartulli <ordex@...istici.org>
> > > Date: Tue, 1 May 2012 00:22:30 +0200
> > > 
> > > > However this patch also contains a procedure which queries the neigh
> > > > table in order to understand whether a given host is known or not.
> > > > Would it be possible to do that in another way (Without manually
> > > > touching the table)?
> > > > 
> > > > Instead, in the next patch (patch 06/15) batman-adv manually increase
> > > > the neigh timeouts. Do you think we should avoid doing that as well?
> > > > If we are allowed to do that, how can we perform the same operation in
> > > > a cleaner way?
> > > > 
> > > > Last question: why can't other modules use exported functions? Are you
> > > > going to change them as well?
> > > 
> > > I really don't have time to discuss your neigh issues right now as I'm
> > > busy speaking at conferences and dealing with the backlog of other
> > > patches.
> > > 
> > > You'll need to find someone else to discuss it with you, sorry.
> > 
> > I hope now is a good moment to bring the questions back onto the table. We
> > still are not sure how to proceed because we have no clear picture of what
> > is going to come and how the exported functions are supposed to be used.
> > 
> > David, if you don't have the time to discuss the ARP handling with us could
> > you name someone who knows your plans and the code equally well ? So far,
> > nobody has stepped up.
> 
> let me add another piece of information: The distributed ARP table does not 
> really depend on the kernel's ARP table. We can easily write our own backend 
> to be totally independent of the kernel's ARP table. Initially, we thought it 
> might be considered a smart move if the code made use of existing kernel 
> infrastructure instead of writing our own storage / user space API / etc, 
> hence duplicating what is already there. But if you feel this is the better 
> way forward we certainly will make the necessary changes.
> 
> Regards,
> Marek
> 

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)