netdev - Re: bridging with gre tunnel

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <487B11D9.7090800@snapgear.com>
Date:	Mon, 14 Jul 2008 18:44:09 +1000
From:	Philip Craig <philipc@...pgear.com>
To:	Timo Teräs <timo.teras@....fi>
CC:	bridge@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: bridging with gre tunnel

Timo Teräs wrote:
> 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?

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html