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
| ||
|
Date: Thu, 17 May 2012 19:53:54 +0800 From: Marek Lindner <lindner_marek@...oo.de> To: b.a.t.m.a.n@...ts.open-mesh.org Cc: David Miller <davem@...emloft.net>, ordex@...istici.org, netdev@...r.kernel.org Subject: Re: [B.A.T.M.A.N.] [PATCH 06/15] batman-adv: Distributed ARP Table - add snooping functions for ARP messages 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists