netdev - Re: [PATCHv4] net: Add batman-adv meshing protocol

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: <201009082058.15533.sven.eckelmann@gmx.de>
Date:	Wed, 8 Sep 2010 20:58:14 +0200
From:	Sven Eckelmann <sven.eckelmann@....de>
To:	Jesse Gross <jesse@...ira.com>
Cc:	b.a.t.m.a.n@...ts.open-mesh.org, Andi Kleen <andi@...stfloor.org>,
	davem@...emloft.net, netdev@...r.kernel.org,
	b.a.t.m.a.n@...ts.open-mesh.net
Subject: Re: [PATCHv4] net: Add batman-adv meshing protocol

Jesse Gross wrote:
> On Wed, Sep 8, 2010 at 2:42 AM, Sven Eckelmann <sven.eckelmann@....de> 
wrote:
> > Hi,
> > 
> > here are some raw references without any judgment. Maybe Marek will send
> > some more information about that topic later.
> > 
> > Andi Kleen wrote:
> >> Sven Eckelmann <sven.eckelmann@....de> writes:
> >> > B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a
> >> > routing protocol for multi-hop ad-hoc mesh networks. The networks may
> >> > be wired or wireless. See http://www.open-mesh.org/ for more
> >> > information and user space tools.
> >> 
> >> It seems rather unusual to have the complete routing protocol in
> >> kernel. And this is a lot of code. The normal way to do such things is
> >> to have the routing policy etc. in a user daemon and only let the kernel
> >> provide some services to this.
> >> 
> >> Could you elaborate a bit why this approach was not chosen?
> >> 
> >> I assume if it needs a switch it could have a switching "hot path" layer
> >> in kernel and the policy somewhere else.
> 
> Potentially one way to do this is to build on top of Open vSwitch.  It
> contains a pretty generic flow-based kernel module for forwarding data
> packets and making simple modifications.  Control packets can be sent
> to userspace to handle the routing logic, while data packets remain in
> the kernel for performance.  This would dramatically reduce the amount
> of code that needs to be in the kernel and may even help performance
> by simplifying the fast path.
> 
> I don't know the details of your protocol well enough to know if this
> is feasible but it seems like something you might want to look into.
> Open vSwitch is currently in the process of finalizing its interfaces
> to prepare for upstreaming.

It sounds interesting. I haven't looked into it yet, but maybe you could 
easily answer some questions:
 * Does it allow to generate multiple net_devices on the system?
 * Does it allow to attach multiple net_devices to a single openvswitch
   device?
 * Does the attaching of a net_device to a openvswitch device prevent it to be
   added to another openvswitch device?
 * Does it propagate the information about the incoming device to the
   userspace in case of the not routed packets (everything which should
 * Does it allow to append extra header information to the packet?
 * Does it allow fragmentation of packets (not real fragmentation, but more
   single split)?
 * Does it allow to define outgoing patterns (on which attached interface
   goes the thing out again) on packet number or incoming device (the real
   hardware device it was coming in)?
 * Is it possible to define rules like: "If this is a broadcast of an udp/ip
   packet with target port 123 which may or may not have a vlan tag, but is
   coming directly from the virtual device and is not routed by us, then
   change the mac address to following"?
 * Can it be backported to old kernels (~2.6.21 - yes, their are "customers" 
   who need even older kernels due to the fantastic vendors out their)?

Thanks,
	Sven

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