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
| ||
|
Message-Id: <201009082225.47498.sven.eckelmann@gmx.de>
Date: Wed, 8 Sep 2010 22:25:46 +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:
[...]
> > * Does it propagate the information about the incoming device to the
> > userspace in case of the not routed packets (everything which should
>
> I think the last part of your question got cut off.
Or I simple was distracted and didn't finish the sentence. :)
> However, packets
> do include metadata about the input device. Userspace would then be
> able to use the normal Linux mechanisms to find out whatever it needs
> (or look at its own information).
>
> > * Does it allow to append extra header information to the packet?
> > * Does it allow fragmentation of packets (not real fragmentation, but
> > more single split)?
>
> I'm assuming that both of these questions are for tunneling. Open
> vSwitch currently supports a few different L2 over L3 tunneling
> mechanisms and has a tunnel library that makes adding additional
> protocols easy. It probably can't do exactly what you need right now,
> but it should be fairly easy to extend.
Hm, low overhead tunneling is one of the main parts, but if you think that it
is easy to extend then fine.
> > * 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)?
>
> I'm not sure what you mean by "packet number". It does allow you to
> specify the output interface based on a number of factors, include the
> input device.
It would mean that for example 5 packets goes over device 1, the next 5
packets goes over
> > * directly influence the traffic flow, i.e., ARQ for broadcasts,
Could you please comment on that one (taken from Mareks mail). Think about
that one:
* A Broadcast packet must be send over wifi (adhoc)
* This packet is probably dropped due to some interferences. So each node
must transmit the broadcast more than one time to be (with a good chance
successful). This is quite essential on l2 based adhoc wifi mesh networks
(as tests showed - but please ask Marek for the actual test setups)
> 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).
Without checking any facts: This sounds a little bit heavy - does it only
sound heavy and in reality is extreme slim? The problem is that it must run on
those low end, "please don't run code on me, because I cannot crunch numbers
and have no ram" machines like the FON2100 or WRT54GL.
thanks,
Sven
Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists