[PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver

[PATCH 00/03][RESUBMIT] net: EtherIP tunnel driver

[Joerg Roedel]

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 <joro-lkml@zlug.org>

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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Sat, 2006-09-23 14:07:04 +0200, Joerg Roedel <joro-lkml@zlug.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?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[PATCH 01/03] net: EtherIP driver, header and MAINTAINERS changes

[Joerg Roedel]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

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 <joro-lkml@zlug.org>

[-- Attachment #2: patch_etherip --]
[-- Type: text/plain, Size: 17058 bytes --]

diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/include/linux/if_arp.h linux-2.6.18/include/linux/if_arp.h
--- linux-2.6.18-vanilla/include/linux/if_arp.h	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/include/linux/if_arp.h	2006-09-23 12:50:05.000000000 +0200
@@ -85,6 +85,7 @@
 #define ARPHRD_IEEE80211 801		/* IEEE 802.11			*/
 #define ARPHRD_IEEE80211_PRISM 802	/* IEEE 802.11 + Prism2 header  */
 #define ARPHRD_IEEE80211_RADIOTAP 803	/* IEEE 802.11 + radiotap header */
+#define ARPHRD_ETHERIP  804		/* Ethernet over IPv4  tunnel   */
 
 #define ARPHRD_VOID	  0xFFFF	/* Void type, nothing is known */
 #define ARPHRD_NONE	  0xFFFE	/* zero header length */
diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/include/linux/in.h linux-2.6.18/include/linux/in.h
--- linux-2.6.18-vanilla/include/linux/in.h	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/include/linux/in.h	2006-09-20 22:52:30.000000000 +0200
@@ -40,6 +40,7 @@ enum {
 
   IPPROTO_ESP = 50,            /* Encapsulation Security Payload protocol */
   IPPROTO_AH = 51,             /* Authentication Header protocol       */
+  IPPROTO_ETHERIP = 97,		/* Ethernet over IPv4 protocol */
   IPPROTO_PIM    = 103,		/* Protocol Independent Multicast	*/
 
   IPPROTO_COMP   = 108,                /* Compression Header protocol */
diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv4/etherip.c linux-2.6.18/net/ipv4/etherip.c
--- linux-2.6.18-vanilla/net/ipv4/etherip.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.18/net/ipv4/etherip.c	2006-09-23 12:52:38.000000000 +0200
@@ -0,0 +1,542 @@
+/*
+ * etherip.c: Ethernet over IPv4 tunnel driver (according to RFC3378)
+ *
+ * This driver could be used to tunnel Ethernet packets through IPv4
+ * networks. This is especially usefull together with the bridging
+ * code in Linux.
+ *
+ * This code was written with an eye on the IPIP driver in linux from
+ * Sam Lantinga. Thanks for the great work.
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      version 2 (no later version) as published by the
+ *      Free Software Foundation.
+ *
+ */
+
+#include <linux/capability.h>                           
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/mutex.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/ip.h>
+#include <linux/if_tunnel.h>
+#include <linux/if_arp.h>
+#include <linux/list.h>
+#include <linux/string.h>
+#include <linux/netfilter_ipv4.h>
+#include <net/ip.h>
+#include <net/protocol.h>
+#include <net/route.h>
+#include <net/ipip.h>
+#include <net/xfrm.h>
+#include <net/inet_ecn.h>
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Joerg Roedel <joerg@zlug.org>");
+MODULE_DESCRIPTION("Ethernet over IPv4 tunnel driver");
+
+/*
+ * These 2 defines are taken from ipip.c - if it's good enough for them
+ * it's good enough for me.
+ */
+#define HASH_SIZE        16
+#define HASH(addr)       ((addr^(addr>>4))&0xF)
+
+#define ETHERIP_HEADER   ((u16)0x0300)
+#define ETHERIP_HLEN     2
+
+#define BANNER1 "etherip: Ethernet over IPv4 tunneling driver\n"
+
+struct etherip_tunnel {
+	struct list_head list;
+	struct net_device *dev;
+	struct net_device_stats stats;
+	struct ip_tunnel_parm parms;
+	unsigned int recursion;
+};
+
+static struct net_device *etherip_tunnel_dev;
+static struct list_head tunnels[HASH_SIZE];
+
+static DEFINE_RWLOCK(etherip_lock);
+
+static void etherip_tunnel_setup(struct net_device *dev);
+
+/* add a tunnel to the hash */
+static void etherip_tunnel_add(struct etherip_tunnel *tun)
+{
+	unsigned h = HASH(tun->parms.iph.daddr);
+	list_add_tail(&tun->list, &tunnels[h]);
+}
+
+/* delete a tunnel from the hash*/
+static void etherip_tunnel_del(struct etherip_tunnel *tun)
+{
+	list_del(&tun->list);
+}
+
+/* find a tunnel in the hash by parameters from userspace */
+static struct etherip_tunnel* etherip_tunnel_find(struct ip_tunnel_parm *p)
+{
+	struct etherip_tunnel *ret;
+	unsigned h = HASH(p->iph.daddr);
+
+	list_for_each_entry(ret, &tunnels[h], list)
+		if (ret->parms.iph.daddr == p->iph.daddr)
+			return ret;
+
+	return NULL;
+}
+
+/* find a tunnel by its destination address */
+static struct etherip_tunnel* etherip_tunnel_locate(u32 remote)
+{
+	struct etherip_tunnel *ret;
+	unsigned h = HASH(remote);
+
+	list_for_each_entry(ret, &tunnels[h], list)
+		if (ret->parms.iph.daddr == remote)
+			return ret;
+
+	return NULL;
+}
+
+/* netdevice start function */
+static int etherip_tunnel_open(struct net_device *dev)
+{
+	netif_start_queue(dev);
+	return 0;
+}
+
+/* netdevice stop function */
+static int etherip_tunnel_stop(struct net_device *dev)
+{
+	netif_stop_queue(dev);
+	return 0;
+}
+
+/* netdevice hard_start_xmit function
+ * it gets an Ethernet packet in skb and encapsulates it in another IP
+ * packet */
+static int etherip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct etherip_tunnel *tunnel = netdev_priv(dev);
+	struct rtable *rt;
+	struct iphdr *iph;
+	struct flowi fl;
+	struct net_device *tdev;
+	int max_headroom;
+	struct net_device_stats *stats = &tunnel->stats;
+
+	if (tunnel->recursion++) {
+		tunnel->stats.collisions++;
+		goto tx_error;
+	}
+
+	memset(&fl, 0, sizeof(fl));
+	fl.oif               = tunnel->parms.link;
+	fl.proto             = IPPROTO_ETHERIP;
+	fl.nl_u.ip4_u.daddr  = tunnel->parms.iph.daddr;
+	fl.nl_u.ip4_u.saddr  = tunnel->parms.iph.saddr;
+
+	if (ip_route_output_key(&rt, &fl)) {
+		tunnel->stats.tx_carrier_errors++;
+		goto tx_error_icmp;
+	}
+
+	tdev = rt->u.dst.dev;
+	if (tdev == dev) {
+		ip_rt_put(rt);
+		tunnel->stats.collisions++;
+		goto tx_error;
+	}
+
+	max_headroom = (LL_RESERVED_SPACE(tdev)+sizeof(struct iphdr)
+			+ ETHERIP_HLEN);
+
+	if (skb_headroom(skb) < max_headroom || skb_cloned(skb)
+			|| skb_shared(skb)) {
+		struct sk_buff *skn = skb_realloc_headroom(skb, max_headroom);
+		if (!skn) {
+			ip_rt_put(rt);
+			dev_kfree_skb(skb);
+			tunnel->stats.tx_dropped++;
+			return 0;
+		}
+		if (skb->sk)
+			skb_set_owner_w(skn, skb->sk);
+		dev_kfree_skb(skb);
+		skb = skn;
+	}
+
+	skb->h.raw = skb->nh.raw;
+	skb->nh.raw = skb_push(skb, sizeof(struct iphdr)+ETHERIP_HLEN);
+	memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
+	IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED |
+			IPSKB_REROUTED);
+        if (skb->dst)
+		skb->dst->ops->update_pmtu(skb->dst, dev->mtu);
+
+	dst_release(skb->dst);
+	skb->dst = &rt->u.dst;
+
+	/* Build the IP header for the outgoing packet
+	 *
+	 * Note: This driver never sets the DF flag on outgoing packets
+	 *       to ensure that the tunnel provides the full Ethernet MTU.
+	 *       This behavior guarantees that protocols can be
+	 *       encapsulated within the Ethernet packet which do not
+	 *       know the concept of a path MTU
+	 */
+	iph = skb->nh.iph;
+	iph->version = 4;
+	iph->ihl = sizeof(struct iphdr)>>2;
+	iph->frag_off = 0;
+	iph->protocol = IPPROTO_ETHERIP;
+	iph->tos = tunnel->parms.iph.tos & INET_ECN_MASK;
+	iph->daddr = rt->rt_dst;
+	iph->saddr = rt->rt_src;
+	iph->ttl = tunnel->parms.iph.ttl;
+	if (iph->ttl == 0)
+		iph->ttl = dst_metric(&rt->u.dst, RTAX_HOPLIMIT);
+
+	/* add the 16bit etherip header after the ip header */
+	*((u16*)(skb->nh.raw + sizeof(struct iphdr))) = ntohs(ETHERIP_HEADER);
+	nf_reset(skb);
+	IPTUNNEL_XMIT();
+	tunnel->dev->trans_start = jiffies;
+	tunnel->recursion--;
+
+	return 0;
+
+tx_error_icmp:
+	dst_link_failure(skb);
+
+tx_error:
+	tunnel->stats.tx_errors++;
+	dev_kfree_skb(skb);
+	tunnel->recursion--;
+	return 0;
+}
+
+/* get statistics callback */
+static struct net_device_stats *etherip_tunnel_stats(struct net_device *dev)
+{
+	struct etherip_tunnel *ethip = netdev_priv(dev);
+	return &ethip->stats;
+}
+
+/* checks parameters the driver gets from userspace */
+static int etherip_param_check(struct ip_tunnel_parm *p)
+{
+	if (p->iph.version != 4 ||
+	    p->iph.protocol != IPPROTO_ETHERIP ||
+	    p->iph.ihl != 5 ||
+	    p->iph.daddr == INADDR_ANY ||
+	    MULTICAST(p->iph.daddr))
+		return -EINVAL;
+
+	return 0;
+}
+
+/* central ioctl function for all netdevices this driver manages
+ * it allows to create, delete, modify a tunnel and fetch tunnel
+ * information */
+static int etherip_tunnel_ioctl(struct net_device *dev, struct ifreq *ifr,
+		int cmd)
+{
+	int err = 0;
+	struct ip_tunnel_parm p;
+	struct net_device *tmp_dev;
+	char *dev_name;
+	struct etherip_tunnel *t;
+
+
+	switch (cmd) {
+	case SIOCGETTUNNEL:
+		t = netdev_priv(dev);
+		if (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms,
+				sizeof(t->parms)))
+			err = -EFAULT;
+		break;
+	case SIOCADDTUNNEL:
+		err = -EINVAL;
+		if (dev != etherip_tunnel_dev)
+			goto out;
+
+	case SIOCCHGTUNNEL:
+		err = -EPERM;
+		if (!capable(CAP_NET_ADMIN))
+			goto out;
+
+		err = -EFAULT;
+		if (copy_from_user(&p, ifr->ifr_ifru.ifru_data,
+					sizeof(p)))
+			goto out;
+		p.i_flags = p.o_flags = 0;
+
+		if ((err = etherip_param_check(&p)) < 0)
+			goto out;
+
+		t = etherip_tunnel_find(&p);
+
+		err = -EEXIST;
+		if (t != NULL && t->dev != dev)
+			goto out;
+
+		if (cmd == SIOCADDTUNNEL) {
+
+			p.name[IFNAMSIZ-1] = 0;
+			dev_name = p.name;
+			if (dev_name[0] == 0)
+				dev_name = "ethip%d";
+
+			err = -ENOMEM;
+			tmp_dev = alloc_netdev(
+					sizeof(struct etherip_tunnel),
+					dev_name,
+					etherip_tunnel_setup);
+
+			if (tmp_dev == NULL)
+				goto out;
+
+			if (strchr(tmp_dev->name, '%')) {
+				err = dev_alloc_name(tmp_dev, tmp_dev->name);
+				if (err < 0)
+					goto add_err;
+			}
+
+			t = netdev_priv(tmp_dev);
+			t->dev = tmp_dev;
+			strncpy(p.name, tmp_dev->name, IFNAMSIZ);
+			memcpy(&(t->parms), &p, sizeof(p));
+
+			err = -EFAULT;
+			if (copy_to_user(ifr->ifr_ifru.ifru_data, &p,
+						sizeof(p)))
+				goto add_err;
+			
+			err = register_netdevice(tmp_dev);
+			if (err < 0)
+				goto add_err;
+
+			write_lock_bh(&etherip_lock);
+			etherip_tunnel_add(t);
+			write_unlock_bh(&etherip_lock);
+
+		} else {
+			err = -EINVAL;
+			if ((t = netdev_priv(dev)) == NULL)
+				goto out;
+			if (dev == etherip_tunnel_dev)
+				goto out;
+			write_lock_bh(&etherip_lock);
+			memcpy(&(t->parms), &p, sizeof(p));
+			write_unlock_bh(&etherip_lock);
+		}
+
+		err = 0;
+		break;
+add_err:
+		free_netdev(tmp_dev);
+		goto out;
+
+	case SIOCDELTUNNEL:
+		err = -EPERM;
+		if (!capable(CAP_NET_ADMIN))
+			goto out;
+
+		err = -EFAULT;
+		if (copy_from_user(&p, ifr->ifr_ifru.ifru_data,
+					sizeof(p)))
+			goto out;
+
+		err = -EINVAL;
+		if (dev == etherip_tunnel_dev) {
+			t = etherip_tunnel_find(&p);
+			if (t == NULL) {
+				goto out;
+			}
+		} else
+			t = netdev_priv(dev);
+
+		write_lock_bh(&etherip_lock);
+		etherip_tunnel_del(t);
+		write_unlock_bh(&etherip_lock);
+
+		unregister_netdevice(t->dev);
+		err = 0;
+
+		break;
+	default:
+		err = -EINVAL;
+	}
+
+out:
+	return err;
+}
+
+/* device init function - called via register_netdevice
+ * The tunnel is registered as an Ethernet device. This allows
+ * the tunnel to be added to a bridge */
+static void etherip_tunnel_setup(struct net_device *dev)
+{
+	SET_MODULE_OWNER(dev);
+	dev->open            = etherip_tunnel_open;
+	dev->hard_start_xmit = etherip_tunnel_xmit;
+	dev->stop            = etherip_tunnel_stop;
+	dev->get_stats       = etherip_tunnel_stats;
+	dev->do_ioctl        = etherip_tunnel_ioctl;
+	dev->destructor      = free_netdev;
+
+	ether_setup(dev);
+	dev->type = ARPHRD_ETHERIP;
+	dev->tx_queue_len = 0;
+	random_ether_addr(dev->dev_addr);
+}
+
+/* receive function for EtherIP packets
+ * Does some basic checks on the MAC addresses and
+ * interface modes */
+static int etherip_rcv(struct sk_buff *skb)
+{
+	struct iphdr *iph;
+	struct ethhdr *ehdr;
+	struct etherip_tunnel *tunnel;
+	struct net_device *dev;
+
+	iph = skb->nh.iph;
+
+	read_lock_bh(&etherip_lock);
+	tunnel = etherip_tunnel_locate(iph->saddr);
+	if (tunnel == NULL)
+		goto drop;
+
+	dev = tunnel->dev;
+	secpath_reset(skb);
+	memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options));
+	skb_pull(skb, (skb->nh.raw - skb->data)
+			+ sizeof(struct iphdr) + ETHERIP_HLEN);
+	ehdr = (struct ethhdr*)skb->data;
+	skb->dev = dev;
+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, tunnel->dev);
+	skb->ip_summed = CHECKSUM_UNNECESSARY;
+	dst_release(skb->dst);
+	skb->dst = NULL;
+
+	/* do some checks */
+	if (skb->pkt_type == PACKET_HOST || skb->pkt_type == PACKET_BROADCAST)
+		goto accept;
+
+	if (skb->pkt_type == PACKET_MULTICAST &&
+			(dev->mc_count > 0 || dev->flags & IFF_ALLMULTI))
+		goto accept;
+
+	if (skb->pkt_type == PACKET_OTHERHOST && dev->flags & IFF_PROMISC)
+		goto accept;
+
+	goto drop;
+
+accept:
+	tunnel->dev->last_rx = jiffies;
+	tunnel->stats.rx_packets++;
+	tunnel->stats.rx_bytes += skb->len;
+	nf_reset(skb);
+	netif_rx(skb);
+	read_unlock_bh(&etherip_lock);
+	return 0;
+
+drop:
+	read_unlock_bh(&etherip_lock);
+	kfree_skb(skb);
+	return 0;
+}
+
+static struct net_protocol etherip_protocol = {
+	.handler      = etherip_rcv,
+	.err_handler  = 0,
+	.no_policy    = 0,
+};
+
+/* module init function
+ * initializes the EtherIP protocol (97) and registers the initial
+ * device */
+static int __init etherip_init(void)
+{
+	int err, i;
+	struct etherip_tunnel *p;
+
+	printk(KERN_INFO BANNER1);
+
+	for (i = 0; i < HASH_SIZE; ++i)
+		INIT_LIST_HEAD(&tunnels[i]);
+
+	if (inet_add_protocol(&etherip_protocol, IPPROTO_ETHERIP)) {
+		printk(KERN_ERR "etherip: can't add protocol\n");
+		return -EAGAIN;
+	}
+
+	etherip_tunnel_dev = alloc_netdev(sizeof(struct etherip_tunnel),
+			"ethip0",
+			etherip_tunnel_setup);
+
+	if (!etherip_tunnel_dev) {
+		err = -ENOMEM;
+		goto err2;
+	}
+
+	p = netdev_priv(etherip_tunnel_dev);
+	p->dev = etherip_tunnel_dev;
+	/* set some params for iproute2 */
+	strcpy(p->parms.name, "ethip0");
+	p->parms.iph.protocol = IPPROTO_ETHERIP;
+
+	if ((err = register_netdev(etherip_tunnel_dev)))
+		goto err1;
+
+out:
+	return err;
+err1:
+	free_netdev(etherip_tunnel_dev);
+err2:
+	inet_del_protocol(&etherip_protocol, IPPROTO_ETHERIP);
+	goto out;
+}
+
+/* destroy all tunnels */
+static void __exit etherip_destroy_tunnels(void)
+{
+	int i;
+	struct list_head *ptr;
+	struct etherip_tunnel *tun;
+
+	for (i = 0; i < HASH_SIZE; ++i) {
+		list_for_each(ptr, &tunnels[i]) {
+			tun = list_entry(ptr, struct etherip_tunnel, list);
+			ptr = ptr->prev;
+			etherip_tunnel_del(tun);
+			unregister_netdevice(tun->dev);
+		}
+	}
+}
+
+/* module cleanup function */
+static void __exit etherip_exit(void)
+{
+	rtnl_lock();
+	etherip_destroy_tunnels();
+	unregister_netdevice(etherip_tunnel_dev);
+	rtnl_unlock();
+	if (inet_del_protocol(&etherip_protocol, IPPROTO_ETHERIP))
+		printk(KERN_ERR "etherip: can't remove protocol\n");
+}
+
+module_init(etherip_init);
+module_exit(etherip_exit);
diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv4/Kconfig linux-2.6.18/net/ipv4/Kconfig
--- linux-2.6.18-vanilla/net/ipv4/Kconfig	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/net/ipv4/Kconfig	2006-09-23 13:02:18.000000000 +0200
@@ -272,6 +272,19 @@ config NET_IPGRE_BROADCAST
 	  Network), but can be distributed all over the Internet. If you want
 	  to do that, say Y here and to "IP multicast routing" below.
 
+config NET_ETHERIP
+	tristate "IP: Ethernet over IP tunneling (experimental)"
+	help
+	 Tunneling means encapsulating data of one protocol type within
+	 another protocol and sending it over a channel that understands the
+	 encapsulating protocol. This tunnel driver implements the
+	 encapsulation of Ethernet frames into IP packets using the EtherIP
+	 protocol defined in RFC 3378. This is especially usefull together with
+	 the bridging code to build distributed OSI Layer 2 networks.
+
+	 You can build this driver as a module. The module will be called
+	 etherip.ko. If unsure, say N.
+
 config IP_MROUTE
 	bool "IP: multicast routing"
 	depends on IP_MULTICAST
diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/net/ipv4/Makefile linux-2.6.18/net/ipv4/Makefile
--- linux-2.6.18-vanilla/net/ipv4/Makefile	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/net/ipv4/Makefile	2006-09-20 22:52:30.000000000 +0200
@@ -17,6 +17,7 @@ obj-$(CONFIG_PROC_FS) += proc.o
 obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
 obj-$(CONFIG_IP_MROUTE) += ipmr.o
 obj-$(CONFIG_NET_IPIP) += ipip.o
+obj-$(CONFIG_NET_ETHERIP) += etherip.o
 obj-$(CONFIG_NET_IPGRE) += ip_gre.o
 obj-$(CONFIG_SYN_COOKIES) += syncookies.o
 obj-$(CONFIG_INET_AH) += ah4.o
--- linux-2.6.18-vanilla/MAINTAINERS	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/MAINTAINERS	2006-09-23 12:41:09.000000000 +0200
@@ -1016,6 +1016,11 @@ M:	philb@gnu.org
 L:	netdev@vger.kernel.org
 S:	Maintained
 
+ETHERIP TUNNEL DRIVER
+P:	Joerg Roedel
+M:	joro@zlug.org
+S:	Maintained
+
 ETHERNET BRIDGE
 P:	Stephen Hemminger
 M:	shemminger@osdl.org

[PATCH 02/03] net/bridge: add support for EtherIP devices

[Joerg Roedel]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

This patch changes the device check in the bridge code to allow EtherIP
devices to be added.

Signed-off-by: Joerg Roedel <joro-lkml@zlug.org>

[-- Attachment #2: patch_etherip_bridge --]
[-- Type: text/plain, Size: 614 bytes --]

diff -uprN -X linux-2.6.18-vanilla/Documentation/dontdiff linux-2.6.18-vanilla/net/bridge/br_if.c linux-2.6.18/net/bridge/br_if.c
--- linux-2.6.18-vanilla/net/bridge/br_if.c	2006-09-20 05:42:06.000000000 +0200
+++ linux-2.6.18/net/bridge/br_if.c	2006-09-20 23:03:26.000000000 +0200
@@ -407,7 +407,8 @@ int br_add_if(struct net_bridge *br, str
 	struct net_bridge_port *p;
 	int err = 0;
 
-	if (dev->flags & IFF_LOOPBACK || dev->type != ARPHRD_ETHER)
+	if (dev->flags & IFF_LOOPBACK ||
+	    dev->type != ARPHRD_ETHER && dev->type != ARPHRD_ETHERIP)
 		return -EINVAL;
 
 	if (dev->hard_start_xmit == br_dev_xmit)

Re: [PATCH 03/03][IPROUTE2] EtherIP tunnel and device support for iproute2

[Joerg Roedel]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

This patch adds support for EtherIP tunnels and devices to the iproute2
userspace software package.

Signed-off-by: Joerg Roedel <joro-lkml@zlug.org>

[-- Attachment #2: patch_iproute2 --]
[-- Type: text/plain, Size: 5317 bytes --]

diff -urp iproute2-2.6.16-060323.orig/ip/iptunnel.c iproute2-2.6.16-060323/ip/iptunnel.c
--- iproute2-2.6.16-060323.orig/ip/iptunnel.c	2005-02-10 19:31:18.000000000 +0100
+++ iproute2-2.6.16-060323/ip/iptunnel.c	2006-09-20 22:35:30.000000000 +0200
@@ -44,7 +44,7 @@ static void usage(void) __attribute__((n
 static void usage(void)
 {
 	fprintf(stderr, "Usage: ip tunnel { add | change | del | show } [ NAME ]\n");
-	fprintf(stderr, "          [ mode { ipip | gre | sit } ] [ remote ADDR ] [ local ADDR ]\n");
+	fprintf(stderr, "          [ mode { ipip | gre | sit | etherip } ] [ remote ADDR ] [ local ADDR ]\n");
 	fprintf(stderr, "          [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]\n");
 	fprintf(stderr, "          [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
 	fprintf(stderr, "\n");
@@ -202,6 +202,12 @@ static int parse_args(int argc, char **a
 					exit(-1);
 				}
 				p->iph.protocol = IPPROTO_IPV6;
+			} else if (strcmp(*argv, "etherip") == 0) {
+				if (p->iph.protocol && p->iph.protocol != IPPROTO_ETHERIP) {
+					fprintf(stderr,"You managed to ask for more than one tunnel mode.\n");
+					exit(-1);
+				}
+				p->iph.protocol = IPPROTO_ETHERIP;
 			} else {
 				fprintf(stderr,"Cannot guess tunnel mode.\n");
 				exit(-1);
@@ -324,11 +330,15 @@ static int parse_args(int argc, char **a
 			p->iph.protocol = IPPROTO_IPIP;
 		else if (memcmp(p->name, "sit", 3) == 0)
 			p->iph.protocol = IPPROTO_IPV6;
+		else if (memcmp(p->name, "ethip", 5) == 0)
+			p->iph.protocol = IPPROTO_ETHERIP;
 	}
 
-	if (p->iph.protocol == IPPROTO_IPIP || p->iph.protocol == IPPROTO_IPV6) {
+	if (p->iph.protocol == IPPROTO_IPIP || 
+	    p->iph.protocol == IPPROTO_IPV6 ||
+	    p->iph.protocol == IPPROTO_ETHERIP) {
 		if ((p->i_flags & GRE_KEY) || (p->o_flags & GRE_KEY)) {
-			fprintf(stderr, "Keys are not allowed with ipip and sit.\n");
+			fprintf(stderr, "Keys are not allowed with ipip, sit or etherip.\n");
 			return -1;
 		}
 	}
@@ -351,6 +361,21 @@ static int parse_args(int argc, char **a
 		fprintf(stderr, "Broadcast tunnel requires a source address.\n");
 		return -1;
 	}
+
+	if (p->iph.protocol == IPPROTO_ETHERIP) {
+		if ((cmd == SIOCADDTUNNEL || cmd == SIOCCHGTUNNEL) && !p->iph.daddr) {
+			fprintf(stderr, "EtherIP tunnel requires a "
+					"destination address.\n");
+			return -1;
+		}
+
+		/*
+		if (cmd != SIOCDELTUNNEL && p->iph.frag_off & htons(IP_DF)) {
+			fprintf(stderr, "Warning: [no]pmtudisc is ignored on"
+					" EtherIP tunnels\n");
+		}
+		*/
+	}
 	return 0;
 }
 
@@ -374,6 +399,8 @@ static int do_add(int cmd, int argc, cha
 		return do_add_ioctl(cmd, "gre0", &p);
 	case IPPROTO_IPV6:
 		return do_add_ioctl(cmd, "sit0", &p);
+	case IPPROTO_ETHERIP:
+		return do_add_ioctl(cmd, "ethip0", &p);
 	default:	
 		fprintf(stderr, "cannot determine tunnel mode (ipip, gre or sit)\n");
 		return -1;
@@ -395,6 +422,8 @@ int do_del(int argc, char **argv)
 		return do_del_ioctl("gre0", &p);
 	case IPPROTO_IPV6:
 		return do_del_ioctl("sit0", &p);
+	case IPPROTO_ETHERIP:
+		return do_del_ioctl("ethip0", &p);
 	default:	
 		return do_del_ioctl(p.name, &p);
 	}
@@ -418,7 +447,8 @@ void print_tunnel(struct ip_tunnel_parm 
 	       p->name,
 	       p->iph.protocol == IPPROTO_IPIP ? "ip" :
 	       (p->iph.protocol == IPPROTO_GRE ? "gre" :
-		(p->iph.protocol == IPPROTO_IPV6 ? "ipv6" : "unknown")),
+	       (p->iph.protocol == IPPROTO_ETHERIP ? "etherip" :
+		(p->iph.protocol == IPPROTO_IPV6 ? "ipv6" : "unknown"))),
 	       p->iph.daddr ? format_host(AF_INET, 4, &p->iph.daddr, s1, sizeof(s1))  : "any",
 	       p->iph.saddr ? rt_addr_n2a(AF_INET, 4, &p->iph.saddr, s2, sizeof(s2)) : "any");
 
@@ -431,19 +461,19 @@ void print_tunnel(struct ip_tunnel_parm 
 	if (p->iph.ttl)
 		printf(" ttl %d ", p->iph.ttl);
 	else
-		printf(" ttl inherit ");
+		printf(" ttl %s", p->iph.protocol != IPPROTO_ETHERIP ? "inherit " : "default");
 	
 	if (p->iph.tos) {
 		SPRINT_BUF(b1);
 		printf(" tos");
 		if (p->iph.tos&1)
-			printf(" inherit");
+			printf(" %s", p->iph.protocol != IPPROTO_ETHERIP ? "inherit" : "default");
 		if (p->iph.tos&~1)
 			printf("%c%s ", p->iph.tos&1 ? '/' : ' ',
 			       rtnl_dsfield_n2a(p->iph.tos&~1, b1, sizeof(b1)));
 	}
 
-	if (!(p->iph.frag_off&htons(IP_DF)))
+	if (p->iph.protocol != IPPROTO_ETHERIP && !(p->iph.frag_off&htons(IP_DF)))
 		printf(" nopmtudisc");
 
 	if ((p->i_flags&GRE_KEY) && (p->o_flags&GRE_KEY) && p->o_key == p->i_key)
@@ -506,8 +536,13 @@ static int do_tunnels_list(struct ip_tun
 			fprintf(stderr, "Failed to get type of [%s]\n", name);
 			continue;
 		}
-		if (type != ARPHRD_TUNNEL && type != ARPHRD_IPGRE && type != ARPHRD_SIT)
+
+		if (type != ARPHRD_TUNNEL &&
+		    type != ARPHRD_IPGRE &&
+		    type != ARPHRD_SIT &&
+		    type != ARPHRD_ETHERIP)
 			continue;
+
 		memset(&p1, 0, sizeof(p1));
 		if (do_get_ioctl(name, &p1))
 			continue;
diff -urp iproute2-2.6.16-060323.orig/lib/ll_types.c iproute2-2.6.16-060323/lib/ll_types.c
--- iproute2-2.6.16-060323.orig/lib/ll_types.c	2005-02-09 23:07:24.000000000 +0100
+++ iproute2-2.6.16-060323/lib/ll_types.c	2006-09-23 13:19:16.000000000 +0200
@@ -118,6 +118,9 @@ __PF(IEEE802_TR,tr)
 #ifdef ARPHRD_IEEE80211
 __PF(IEEE80211,ieee802.11)
 #endif
+#ifdef ARPHRD_ETHERIP
+__PF(ETHERIP, etherip)
+#endif
 #ifdef ARPHRD_VOID
 __PF(VOID,void)
 #endif

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

[Joerg Roedel]

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

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

[jamal]

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@zlug.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

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

[Joerg Roedel]

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

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

[David Miller]

From: jamal <hadi@cyberus.ca>
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.

Re: [PATCH 02/03] net/bridge: add support for EtherIP devices

[Stephen Hemminger]

On Sat, 23 Sep 2006 14:16:29 +0200
Joerg Roedel <joro-lkml@zlug.org> wrote:

> This patch changes the device check in the bridge code to allow EtherIP
> devices to be added.
> 
> Signed-off-by: Joerg Roedel <joro-lkml@zlug.org>

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.

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

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

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?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

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

[Joerg Roedel]

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

Re: [PATCH 02/03] net/bridge: add support for EtherIP devices

[Joerg Roedel]

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

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

[Joerg Roedel]

On Sun, Sep 24, 2006 at 09:07:43PM -0400, Valdis.Kletnieks@vt.edu 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.

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

[Andi Kleen]

David Miller <davem@davemloft.net> 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

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

[Joerg Roedel]

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

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

[Andi Kleen]

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

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

[Joerg Roedel]

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

Re: [PATCH 02/03] net/bridge: add support for EtherIP devices

[Stephen Hemminger]

On Mon, 25 Sep 2006 10:24:45 +0200
Joerg Roedel <joro-lkml@zlug.org> 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.

Re: [PATCH 02/03] net/bridge: add support for EtherIP devices

[Joerg Roedel]

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).

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

[Brian Haley]

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