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