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: <AANLkTi=Ro-Vnkq75KPEdAsNEHvtF6JnmFV9i4uX2gb=H@mail.gmail.com>
Date:	Wed, 8 Sep 2010 13:07:42 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Marek Lindner <lindner_marek@...oo.de>
Cc:	b.a.t.m.a.n@...ts.open-mesh.org,
	Sven Eckelmann <sven.eckelmann@....de>, netdev@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, davem@...emloft.net
Subject: Re: [B.A.T.M.A.N.] [PATCHv4] net: Add batman-adv meshing protocol

On Wed, Sep 8, 2010 at 12:12 PM, Marek Lindner <lindner_marek@...oo.de> wrote:
> On Wednesday 08 September 2010 20:22:42 Jesse Gross wrote:
>> 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.
>
> Thanks for your input.
>
> I had a quick look at the website to get an idea but I had to notice that
> there is quite a collection of daemons, kernel modules and apps. As you seem
> involved in this project, could you point us to the collection of tools that
> you think we would need to achieve the following:
>
> * sending protocol traffic
> * transmitting the routing logic
> * encapsulation of the various packet types (see http://www.open-
> mesh.org/browser/trunk/batman-adv/packet.h to get an idea)
> * directly influence the traffic flow, i.e., ARQ for broadcasts, interface
> alternating, bonding, forward error correction, etc
> * layer 2 fragmentation

There are three basic components that you need running for Open
vSwitch: the main daemon, ovs-vswitchd, a lightweight configuration
manager, ovsdb-server, and the kernel module, openvswitch_mod.  You
would then be able to write a userspace process to communicate with
the daemons to handle the above.  As I mentioned, the encapsulation
would likely require some small additions to the kernel module for
your particular type of tunneling (unless you are flexible and can use
one of the existing mechanisms).  However, that would be significantly
less kernel code than this patch.  As a starting point, I would
recommend playing around with Open vSwitch as a normal switch to get a
feeling for its operation (see the INSTALL.Linux file in the source
distribution for instructions).
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ