Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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? pgpdywPD9wfOm.pgp Description: PGP signature
[PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 : signature.asc Description: Digital signature
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
