GRE Ethernet tunneling

GRE Ethernet tunneling

[Boian Bonev]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

hi,

first to explain why i need to make this stuff in kernel space:
 - userland ethernet tunneling provides more features like encryption but not high performance and low latency
 - low MHz cpus choke on high traffic with userland tunnels (have a look at WRAP boards at www.pcengines.ch)
 - since we have many setups with 802.11a cards and 802.11a protocol does not support direct bridging of interfaces the lack of kernel ethernet tunnel limits linux use in this area

btw. mikrotik (www.mikrotik.com - a linux based closed source router os) implements a tunnel called eoip the gre way
btw2. 802.11a cards support mtus over 1500 so at least software fragmentation may be avoided. i am not sure what happens at lower layers but it performs without much cpu usage increase or speed loss

before writing here i have made a concept proof - i cloned the ip_gre.c module and changed:
 - device creation to be ethernet alike (mtu 1500, ARPHRD_ETHER, hard_header, etc)
 - the protocol to be IPPROTO_GRE+1 (just for testing - not to interferre with existing gre tunnels)
 - removed all code that mangled ttl, ecn, mtu etc
 - GRE protocol to 0x6558 (Ethernet over GRE)

then i dirty patched iproute to manage the new interfaces and here i discovered something not very clean in interface management by iproute - when listing interfaces iproute performs a SIOCGIFHWADDR and checks for ARPHRD_TUNNEL... this may be clean for ip tunnels but it cant work for ethernet tunnels.

now i am looking for a clean way to identify ethernet tunnels in iproute:
 - if i change the type to APRHRD_TUNNEL this will break consistency with both userland utils and kernel side.
 - SIOCDEVPRIVATE + x is not appropriate because it may conflict with some real ethernet device
 - dev->flags are all defined
 - dev->priv_flags in not visible in userspace

i need help to choose a clean and consistent strategy for iproute <---> kernel comm
then i will be able to integrate my concept proof code into ip_gre.c

another thing that comes to mind is to implement a small subset ot ethtool ioctls but this does not seem consistent to me...

b.