Hi all,
It looks the current kernel still do not support bridging over gre

tunnels.
I did find an old patch for ip_gre that would enable this [1]. But

it needs porting from 2.4 to 2.6 kernels and looks like it needs

cleaning up too.
Is there newer/better patches to achieve this? Any thoughts about

doing bridging with gre tunnels?
Cheers,

  Timo
[1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010327.html

--

Timo Ter

There is an essential difference in this patch compared to the one

I referred to. This patch adds a new way to create GRE devices which

results in ethernet style device whereas the older patch modifies

transmit and receive paths to detect packets coming from bridging

code and does not need userland changes at all.
I kind of like the fact that userland tools work as-is and that

I don't need any special flags for the GRE tunnel creation. However

your patch does look way cleaner.
Any comments on what the solution to merged in should look like?
- Timo
--

I posted a cleaner version that's similar to what the old patch

did, see http://marc.info/?l=linux-netdev&m=115449948503549&w=2
But I don't think that is the right approach:

- it forces you to use bridging if you only want ethernet over GRE

- the change fundamentally has nothing to do with bridging
BTW, the STP bits in my patch can be removed too if needed, most users

won't want them and they aren't quite right (stp packets are counted

as errors).  I don't even know what device needed it, I just have a

pcap file with the packets.  After removing that, there's nothing

in the patch related to bridging.
Actually, this change doesn't really belong in GRE either, because

that forces you to choose between ethernet encapsulation and not.

It could be a new device that sits on top of GRE and simply does

ethernet encapsulation then passes it to the raw GRE device.

That's a lot of infrastructure for something so simple though,

and I don't think people will want to use both devices at once.

--

What's the problem with using Ethernet encapsulation on such a

GRE device? If you're referring to the fact that user-space uses

the encapsulation type to determine whether a device is a tunnel,

then we should fix those tools instead.
Rather than trying to resuscitate the ioctl interface, please

create a new extensible netlink interface and make ip(8) use it

where available.
Cheers,

--

Visit Openswan at http://www.openswan.org/

Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>

Home Page: http://gondor.apana.org.au/~herbert/

PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--

Or use rtnl_link, which was created for this purpose :)

--

Excellent, now there is even less excuse to bother with the ioctls :)

--

Visit Openswan at http://www.openswan.org/

Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>

Home Page: http://gondor.apana.org.au/~herbert/

PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--

That's a third way to do it. The patch I referred to changed

ip_gre mostly (only change to bridging was the device type check).
But it has the same limitation that ether encapsulation is only
Yes, I would not do the ethernet header stuff in bridging code
This sounds as the most robust way to do it. But yes, it sounds

unlikely that both devices would be used simultaneously.
Not sure how easy it would be to add a new tunnel type. Apparently

they use IPPROTO_* to differentiate type and it would be the same

in this case.
Thanks for the feedback so far.

- Timo

--

This would be my preferred approach. There are other drivers that use a

netdev to do some encap/decap processing on packets which are then

passed on to another driver, e.g. macvlan, and it works well.
--

James Chapman

Katalix Systems Ltd

http://www.katalix.com

Catalysts for your Embedded Linux software development
--

On Fri, 11 Jul 2008 09:30:08 +0300
The idea is fine, but that patch needs work (kind of a mess).

If you want it, then go through normal process of submitting to

netdev and take the comments and fix it up.

--