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).
Signed-off-by: Joerg Roedel <[email protected]>
On Sat, 2006-09-23 14:07:04 +0200, Joerg Roedel <[email protected]> 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?
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second :
This patch contains the reworked EtherIP driver, the necessary header
updates and adds an entry for EtherIP to the MAINTAINERS file.
Signed-off-by: Joerg Roedel <[email protected]>
This patch changes the device check in the bridge code to allow EtherIP
devices to be added.
Signed-off-by: Joerg Roedel <[email protected]>
This patch adds support for EtherIP tunnels and devices to the iproute2
userspace software package.
Signed-off-by: Joerg Roedel <[email protected]>
On Sat, Sep 23, 2006 at 02:13:27PM +0200, Jan-Benedict Glaw wrote:
> 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?
In general it is possible to use a tap interface to tunnel Ethernet
packets. But this driver uses the EtherIP protocol defined in RFC 3378
which itself defines an own IP protocol for it (number 97). This
protocol is also supported by different other operating systems (some of
the major BSD versions). This driver makes Linux interoperable with
these implementations.
Regards,
Joerg Roedel
On Sat, 2006-23-09 at 14:13 +0200, Jan-Benedict Glaw wrote:
> On Sat, 2006-09-23 14:07:04 +0200, Joerg Roedel <[email protected]> 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
On Sat, Sep 23, 2006 at 08:38:37AM -0400, jamal wrote:
Hello Jamal,
> You just need to use GRE tunnel instead of what you describe above.
The main intention for this driver was not only to provide Ethernet over
IPv4 tunneling. This is also possible in userspace using a tap interface
(as Jan-Benedict Glaw mentioned). Another main intention for this driver
was to provide tunneling of Ethernet packets using the EtherIP protocol.
> 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).
You are right. I completly agree with this. But this is also true for
the IPIP and the SIT driver. You can do both with GRE. And there are
reasons to keep both in the Kernel.
> 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.
At the moment I know at least that at least OpenBSD, NetBSD and FreeBSD
support the EtherIP protocol. The first of them was OpenBSD, thats
right. I don't think OpenBSD made a wrong implementation at this point
(I assume you are speaking of the position of the 3 in the header). The
RFC is not clear at this point. It defines that the first 4 bits in the
16 bit Ethernet header MUST be 0011. But it don't defines the
byteorder of that 16 bit word nor if the least or most significant bit
comes first. This was the reason (to keep interoperability with the
existing implementations) I implemented it the same way as OpenBSD and
my driver does not check the incoming EtherIP header.
> I am actually curious if anyone uses it instead of GRE in openbsd?
When I searched Google for EtherIP I found some entries in BSD forums
discussing questions concering EtherIP usage. This, and the fact I know
a BSD user that uses EtherIP too, makes be believe there are numerous
users of EtherIP in the BSD world. And at least the BSD user I know
wants interoperability of his NetBSD implemenation with Linux. This
request was the starting point for this driver.
> 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 am not a friend of censorship. I think the users should have the
freedom to decide what they want to use. There are reasons to have more
than one way to tunnel Ethernet packets in the Kernel (the reason for
EtherIP is the interoperability with the BSD implementations). I don't
know if the GRE driver in mainline already support Ethernet tunneling.
But if not, my driver is already the second way to do it (after the tap
devices).
> I prefer the later - and hope this doesnt discourage Joerg from
> contributing in the future.
Surely not. I intend to further contribute even if this driver would be
finally rejected :)
Regards,
Joerg Roedel
From: jamal <[email protected]>
Date: Sat, 23 Sep 2006 08:38:37 -0400
> 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.
First, the only mentioned real use of EtherIP I've seen anywhere is to
tunnel old LAN based games that used protocols other than IP :-)
Second, the OpenBSD interoperability issues are very real, and there
is even a Xerox implementation that used an 8-bit instead of a 16-bit
header size.
Third, even the introductory material in RFC3378 mentions that people
are strongly encouraged to use other technologies over EtherIP.
Fourth, and finally, if GRE can provide the same functionality then
that plus the first three points makes EtherIP something we really
should not latch onto.
And if it doesn't go in, it's not the end of the world. Anyone can
maintain and use the external patch, and if usage gets widespread
enough we'll of course be required to reevaluate integration.
So I think we should pass on this for now.
On Sat, 23 Sep 2006 14:16:29 +0200
Joerg Roedel <[email protected]> wrote:
> This patch changes the device check in the bridge code to allow EtherIP
> devices to be added.
>
> Signed-off-by: Joerg Roedel <[email protected]>
If the device looks like a duck (Ethernet), then why does it need
a separate ARP type. There are other tools that might work without
modification if it just fully pretended to be an ether device.
On Sat, 23 Sep 2006 15:27:36 +0200, Joerg Roedel said:
> (I assume you are speaking of the position of the 3 in the header). The
> RFC is not clear at this point. It defines that the first 4 bits in the
> 16 bit Ethernet header MUST be 0011. But it don't defines the
> byteorder of that 16 bit word nor if the least or most significant bit
> comes first.
Unless stated otherwise, it's pretty safe to assume that all "on the wire" data
mentioned in an RFC is in 'network byte order'. That's why hton*() and ntoh*()
functions exist...
Is there something in the RFC that suggests that a byte order other than
'network order' is possible/acceptable there?
On Sat, Sep 23, 2006 at 04:35:35PM -0700, David Miller wrote:
> First, the only mentioned real use of EtherIP I've seen anywhere is to
> tunnel old LAN based games that used protocols other than IP :-)
Thats an important use case for EtherIP, thats right :-)
But people often use Ethernet over IP tunneling to transparently switch
between wired and wireless network connections on laptops (and secure
the WLAN path with IPSEC).
Xen also implements the EtherIP protocol in their vnet module.
> Second, the OpenBSD interoperability issues are very real, and there
> is even a Xerox implementation that used an 8-bit instead of a 16-bit
> header size.
Ok, I don't know if the Xerox implementation is still in use anywhere. I
can't find anything in the web about it. But it is mentioned in the RFC,
thats right. The interoperability issue with the BSDs is real. At least
of NetBSD I know that its implementation does not check the incoming
header because of that issue. My implementation also avoids this check.
> Third, even the introductory material in RFC3378 mentions that people
> are strongly encouraged to use other technologies over EtherIP.
Yes, thats right.
> Fourth, and finally, if GRE can provide the same functionality then
> that plus the first three points makes EtherIP something we really
> should not latch onto.
GRE additionally provides interoperability with some hardware devices.
But it does not provide compatibility to the BSDs.
> And if it doesn't go in, it's not the end of the world. Anyone can
> maintain and use the external patch, and if usage gets widespread
> enough we'll of course be required to reevaluate integration.
Ok. I will maintain the driver outside the kernel for the next time.
Lets see if there are enough users for it :)
Cheers,
Joerg
On Sat, Sep 23, 2006 at 09:01:12PM -0700, Stephen Hemminger wrote:
> If the device looks like a duck (Ethernet), then why does it need
> a separate ARP type. There are other tools that might work without
> modification if it just fully pretended to be an ether device.
This solves the problem of getting a list of all EtherIP devices. If
they use ARPHRD_ETHER and use an ioctl in the SIOCDEVPRIVATE space is
not a save way (not even if the ioctl uses ethip0, this device could be
owned by another driver if EtherIP is not present).
On the other hand, a new ARP type opens a lot of new problems. A lot of
userspace tools and libraries must be changed. So this solutions is not
perfect.
Cheers,
Joerg
On Sun, Sep 24, 2006 at 09:07:43PM -0400, [email protected] wrote:
> On Sat, 23 Sep 2006 15:27:36 +0200, Joerg Roedel said:
>
> > (I assume you are speaking of the position of the 3 in the header). The
> > RFC is not clear at this point. It defines that the first 4 bits in the
> > 16 bit Ethernet header MUST be 0011. But it don't defines the
> > byteorder of that 16 bit word nor if the least or most significant bit
> > comes first.
>
> Unless stated otherwise, it's pretty safe to assume that all "on the wire" data
> mentioned in an RFC is in 'network byte order'. That's why hton*() and ntoh*()
> functions exist...
Yes. Thats what the OpenBSD people did :-)
The problem with the header is the bitorder. The OpenBSD people assumed
that the least significant bits come first in the 16-bit header.
> Is there something in the RFC that suggests that a byte order other than
> 'network order' is possible/acceptable there?
No. The RFC states nothing at all about byte- or bitorder. That is why
the RFC is ambigious at this point.
David Miller <[email protected]> writes:
>
> First, the only mentioned real use of EtherIP I've seen anywhere is to
> tunnel old LAN based games that used protocols other than IP :-)
How would you convince those old LAN games to use a MTU < 1500 which
is needed for the tunnel? I bet they have the size hardcoded.
-Andi
On Mon, Sep 25, 2006 at 12:22:41PM +0200, Andi Kleen wrote:
> How would you convince those old LAN games to use a MTU < 1500 which
> is needed for the tunnel? I bet they have the size hardcoded.
The tunnel provides an MTU of 1500. To guarantee this, it never sets the
DF flag in outgoing packets.
Joerg
On Monday 25 September 2006 13:57, Joerg Roedel wrote:
> On Mon, Sep 25, 2006 at 12:22:41PM +0200, Andi Kleen wrote:
>
> > How would you convince those old LAN games to use a MTU < 1500 which
> > is needed for the tunnel? I bet they have the size hardcoded.
>
> The tunnel provides an MTU of 1500. To guarantee this, it never sets the
> DF flag in outgoing packets.
This means it will multiply all full sized packets. That sounds horrible.
-Andi
On Mon, Sep 25, 2006 at 02:16:15PM +0200, Andi Kleen wrote:
> On Monday 25 September 2006 13:57, Joerg Roedel wrote:
> > On Mon, Sep 25, 2006 at 12:22:41PM +0200, Andi Kleen wrote:
> >
> > > How would you convince those old LAN games to use a MTU < 1500 which
> > > is needed for the tunnel? I bet they have the size hardcoded.
> >
> > The tunnel provides an MTU of 1500. To guarantee this, it never sets the
> > DF flag in outgoing packets.
>
> This means it will multiply all full sized packets. That sounds horrible.
Yes, all full sized packets gets fragmented at the IP layer according to
the MTU of the physical device. As I know, this is the only way to
guarantee the full Ethernet MTU on the tunnel device. This guarantee is
required for layer 3 protocols that does not know the concept of a path
MTU (as used by some old LAN based games ;-)
And for some cases this procedure is also defined in RFC 2473, section
7. for "Generic Packet Tunneling in IPv6".
Joerg
On Mon, 25 Sep 2006 10:24:45 +0200
Joerg Roedel <[email protected]> wrote:
> On Sat, Sep 23, 2006 at 09:01:12PM -0700, Stephen Hemminger wrote:
>
> > If the device looks like a duck (Ethernet), then why does it need
> > a separate ARP type. There are other tools that might work without
> > modification if it just fully pretended to be an ether device.
>
> This solves the problem of getting a list of all EtherIP devices. If
> they use ARPHRD_ETHER and use an ioctl in the SIOCDEVPRIVATE space is
> not a save way (not even if the ioctl uses ethip0, this device could be
> owned by another driver if EtherIP is not present).
> On the other hand, a new ARP type opens a lot of new problems. A lot of
> userspace tools and libraries must be changed. So this solutions is not
> perfect.
>
> Cheers,
> Joerg
To get a list of all EtherIP devices, just maintain a linked list
in the private device information. Use list macros, it isn't hard.
On Mon, Sep 25, 2006 at 07:40:09AM -0700, Stephen Hemminger wrote:
>
> To get a list of all EtherIP devices, just maintain a linked list
> in the private device information. Use list macros, it isn't hard.
I use lists in the driver to maintain the list. The problem is to get
such a list in userspace in a safe way (the way over SIOCDEVPRIVATE
ioctls is not safe).
Joerg Roedel wrote:
>> Is there something in the RFC that suggests that a byte order other than
>> 'network order' is possible/acceptable there?
>
> No. The RFC states nothing at all about byte- or bitorder. That is why
> the RFC is ambigious at this point.
RFC 791 (IPv4) Appendix B does give instructions on byte ordering for
all IPv4 headers and data, and RFC 791 is listed in the References for
RFC 3378. I noticed this is only Informational, not a Standards track
document, so I guess the non-interoperable implementations kind of go
with the territory.
-Brian