Thread (10 messages) flat view 10 messages, 4 authors, 2012-03-11

Re: Ethernet-over-UDP virtual network interface

From: Mitar <hidden>
Date: 2012-03-04 13:58:22

Hi!

The problem of GRE IP packets (IP protocol type 47) is that some
consumer routers filter them by default (or even do not have an option
to pass them through).

Maybe the best way would be just to implement greudptap link type
which would be the same as gretap, only it would be using UDP packets?
Do Linux bridge interfaces have MAC auto-discovery?

Do Linux gretap tunnels have MTU auto-discovery?

BTW, why is necessary to configure local IP address of the tunnel?
Shouldn't only a local MAC address be enough? And IP address only on
bridge interface?


Mitar

On Sun, Mar 4, 2012 at 1:21 PM, Denys Fedoryshchenko [off-list ref] wrote:
From my wiki :)
ip link add eoip1 type gretap remote IP1 local IP2 nopmtudisc
ifconfig eth1 0.0.0.0
ifconfig eoip1 mtu 1500 up
brctl addbr br0
brctl addif br0 eoip1
brctl addif br0 eth1
ifconfig br0 up

But not sure this will work, just a hint for kernel-mode tunnel



On 2012-03-04 13:30, Mitar wrote:
quoted
Hi!

At community wireless network wlan slovenija (http://dev.wlan-si.net/)
we have been using OpenVPN tunnels to connect our WiFi nodes together
over existing Internet infrastructure. After some time of using it we
have discovered throughput problems using a user-land tunneling
solution on those small/consumer Wifi router hardware. Because of the
context switches we cannot get more than 5 Mbit/s even with disabled
encryption. (And as we have a lot of fiber here, it really makes
uplinks unused a lot.)

We found out that we need a really light-weight tunneling solution,
but on a L2 level. The idea is to have a simple encryption-less,
state-less, and session-less L2 tunneling. Some kind of
Ethernet-over-UDP type of virtual interface where we could configure
multiple peer IP address and virtual interface would work as a simple
switch, only instead of cables, it would send packets encapsulated in
UDP (EoIP is not good because many consumer routers do not allow
non-TCP/UDP packets to get through). No session handling, nothing.
Simply, any packets it gets in it is send (based on auto-learned MAC
addresses) to the destination IP address in the UDP packet. On the
other side decapsulated packet is simply output of the virtual
interface there.

I have searched around and have not found anything which would work
like this. Have I missed something? If not, I have decided to write
our own kernel module for this, but first I would like to hear some
feedback from others. Would anybody be interested in developing it
with me or at mentoring me (it would be my first kernel module)?

I have found this code:

https://lwn.net/Articles/199120/

and was planning to use it as a basis, but use UDP for communication.
What is a proper way to do UDP communication from a kernel module?

Best regards and thank you all for the great work you are doing on Linux


Mitar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help