linux-kernel - Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1159015118.5301.19.camel@jzny2>
Date:	Sat, 23 Sep 2006 08:38:37 -0400
From:	jamal <hadi@...erus.ca>
To:	Jan-Benedict Glaw <jbglaw@...-owl.de>
Cc:	Joerg Roedel <joro-lkml@...g.org>,
	Patrick McHardy <kaber@...sh.net>, davem@...emloft.net,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver

On Sat, 2006-23-09 at 14:13 +0200, Jan-Benedict Glaw wrote:
> On Sat, 2006-09-23 14:07:04 +0200, Joerg Roedel <joro-lkml@...g.org> wrote:
> > This patchset is the resubmit of the Ethernet over IPv4 tunnel driver
> > for Linux.  I want to thank all reviewers for their annotations and
> > helpfull input.  This version contains some major changes to the driver.
> > It uses an own device type now (ARPHRD_ETHERIP). This fixes the problem
> > that EtherIP devices could not be safely differenced from Ethernet
> > devices. This change also required some other changes. First a second
> > patch to the bridge code is included to allow the use of EtherIP devices
> > in a bridge.  The third patch includes the necessary changes to iproute2
> > (support of the new ARPHRD and general tunnel configuration support for
> >  EtherIP).
> 
> I haven't seen the first submission, but is this driver really needed?
> Can't this be done with creating two tap interfaces on both endpoints
> and bridge them with a local ethernet device using userland software?

You just need to use GRE tunnel instead of what you describe above.

While i feel bad that Joerg (and Lennert and others before) have put the
effort to do the work, i too question the need for this driver. I dont
think even the authors of the original RFC feel this provides anything
that GRE cant (according to some posting on netdev that one of the
authors made). My understanding is also that the only other OS that
implemented this got it wrong - hence you will have to interop with them
and provide quirks checks.

I am actually curious if anyone uses it instead of GRE in openbsd?
You could argue that including this driver would allow Linux to have
another bulb in the christmas tree; the other (more pragmatic way) to
look at this is it allows spreading a bad idea and needs to be censored.
I prefer the later - and hope this doesnt discourage Joerg from
contributing in the future.

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/