Home » Mailing lists » Devel » [PATCH] net: Add etun driver
[PATCH] net: Add etun driver [message #18092] |
Fri, 06 April 2007 20:43 |
ebiederm
Messages: 1354 Registered: February 2006
|
Senior Member |
|
|
etun is a simple two headed tunnel driver that at the link layer looks
like ethernet. It's target audience is communicating between network
namespaces but it is general enough it has other valid uses as well.
Ben Greear implemented a similar device called redir-dev, for network
emulation.
OpenVZ has a similar device that goes by the name veth.
I didn't want to mess with ioctls or weird non-general network
interfaces for creating devices, so I used sysfs as my control
mechanism.
To create a pair of devices called veth0 and veth1:
echo -n 'veth0,veth1' > /sys/module/etun/parameters/newif
To destroy a pair of devices:
echo -n 'veth0' > /sys/module/etun/parameters/delif
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/net/Kconfig | 14 ++
drivers/net/Makefile | 1 +
drivers/net/etun.c | 486 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 501 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/etun.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c3f9f59..03cf13f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -119,6 +119,20 @@ config TUN
If you don't know what to use this for, you don't need it.
+config ETUN
+ tristate "Ethernet tunnel device driver support"
+ depends on SYSFS
+ ---help---
+ ETUN provices a pair of network devices that can be used for
+ configuring interesting topolgies. What one devices transmits
+ the other receives and vice versa. The link level framing
+ is ethernet for wide compatibility with network stacks.
+
+ To compile this driver as a module, choose M here: the module
+ will be called etun.
+
+ If you don't know what to use this for, you don't need it.
+
config NET_SB1000
tristate "General Instruments Surfboard 1000"
depends on PNP
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 33af833..549ff3f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MACSONIC) += macsonic.o
obj-$(CONFIG_MACMACE) += macmace.o
obj-$(CONFIG_MAC89x0) += mac89x0.o
obj-$(CONFIG_TUN) += tun.o
+obj-$(CONFIG_ETUN) += etun.o
obj-$(CONFIG_NET_NETX) += netx-eth.o
obj-$(CONFIG_DL2K) += dl2k.o
obj-$(CONFIG_R8169) += r8169.o
diff --git a/drivers/net/etun.c b/drivers/net/etun.c
new file mode 100644
index 0000000..e15893a
--- /dev/null
+++ b/drivers/net/etun.c
@@ -0,0 +1,486 @@
+/*
+ * ETUN - Universal ETUN device driver.
+ * Copyright (C) 2006 Linux Networx
+ *
+ */
+
+#define DRV_NAME "etun"
+#define DRV_VERSION "1.0"
+#define DRV_DESCRIPTION "Ethernet pseudo tunnel device driver"
+#define DRV_COPYRIGHT "(C) 2007 Linux Networx"
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/spinlock.h>
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/rtnetlink.h>
+#include <linux/if.h>
+#include <linux/if_ether.h>
+#include <linux/ctype.h>
+#include <net/dst.h>
+
+
+/* Device cheksum strategy.
+ *
+ * etun is designed to a be a pair of virutal devices
+ * connecting two network stack instances.
+ *
+ * Typically it will either be used with ethernet bridging or
+ * it will be used to route packets between the two stacks.
+ *
+ * The only checksum offloading I can do is to completely
+ * skip the checksumming step all together.
+ *
+ * When used for ethernet bridging I don't believe any
+ * checksum off loading is safe.
+ * - If my source is an external interface the checksum may be
+ * invalid so I don't want to report I have already checked it.
+ * - If my destination is an external interface I don't want to put
+ * a packet on the wire with someone computing the checksum.
+ *
+ * When used for routing between two stacks checksums should
+ * be as unnecessary as they are on the loopback device.
+ *
+ * So by default I am safe and disable checksumming and
+ * other advanced features like SG and TSO.
+ *
+ * However because I think these features could be useful
+ * I provide the ethtool functions to and enable/disable
+ * them at runtime.
+ *
+ * If you think you can correctly enable these go ahead.
+ * For checksums both the transmitter and the receiver must
+ * agree before the are actually disabled.
+ */
+
+#define ETUN_NUM_STATS 1
+static struct {
+ const char string[ETH_GSTRING_LEN];
+} ethtool_stats_keys[ETUN_NUM_STATS] = {
+ { "partner_ifindex" },
+};
+
+struct etun_info {
+ struct net_device *rx_dev;
+ unsigned ip_summed;
+ struct net_device_stats stats;
+ struct list_head list;
+ struct net_device *dev;
+};
+
+/*
+ * I have to hold the rtnl_lock during device delete.
+ * So I use the rtnl_lock to protect my list manipulations
+ * as well. Crude but simple.
+ */
+static LIST_HEAD(etun_list);
+
+/*
+ * The higher levels take care of making this non-reentrant (it's
+ * called with bh's disabled).
+ */
+static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev)
+{
+ struct etun_info *tx_info = tx_dev->priv;
+ struct net_device *rx_dev = tx_info->rx_dev;
+ struct etun_info *rx_info = rx_dev->priv;
+
+ tx_info->stats.tx_packets++;
+ tx_info->stats.tx_bytes += skb->len;
+
+ /* Drop the skb state that was needed to get here */
+ skb_orphan(skb);
+ if (skb->dst)
+ skb->dst = dst_pop(skb->dst); /* Allow for smart routing */
+
+ /* Switch to the receiving device */
+ skb->pkt_type = PACKET_HOST;
+ skb->protocol = eth_type_trans(skb, rx_dev);
+ skb->dev = rx_dev;
+ skb->ip_summed = CHECKSUM_NONE;
+
+ /* If both halves agree no checksum is needed */
+ if (tx_dev->features & NETIF_F_NO_CSUM)
+ skb->ip_summed = rx_info->ip_summed;
+
+ rx_dev->last_rx = jiffies;
+ rx_info->stats.rx_packets++;
+ rx_info->stats.rx_bytes += skb->len;
+ netif_rx(skb);
+
+ return 0;
+}
+
+static struct net_device_stats *etun_get_stats(struct net_device *dev)
+{
+ struct etun_info *info = dev->priv;
+ return &info->stats;
+}
+
+/* ethtool interface */
+static int etun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ cmd->supported = 0;
+ cmd->advertising = 0;
+ cmd->speed = SPEED_10000; /* Memory is fast! */
+ cmd->duplex = DUPLEX_FULL;
+ cmd->port = PORT_TP;
+ cmd->phy_address = 0;
+ cmd->transceiver = XCVR_INTERNAL;
+ cmd->autoneg = AUTONEG_DISABLE;
+ cmd->maxtxpkt = 0;
+ cmd->maxrxpkt = 0;
+ return 0;
+}
+
+static void etun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
+{
+ strcpy(info->driver, DRV_NAME);
+ strcpy(info->version, DRV_VERSION);
+ strcpy(info->fw_version, "N/A");
+}
+
+static void etun_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
+{
+ switch(stringset) {
+ case ETH_SS_STATS:
+ memcpy(buf, ðtool_stats_keys, sizeof(ethtool_stats_keys));
+ break;
+ case ETH_SS_TEST:
+ default:
+ break;
+ }
+}
+
+static int etun_get_stats_count(struct net_device *dev)
+{
+ return ETUN_NUM_STATS;
+}
+
+static void etun_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct etun_info *info = dev->priv;
+
+ data[0] = info->rx_dev->ifindex;
+}
+
+static u32 etun_get_rx_csum(struct net_device *dev)
+{
+ struct etun_info *info = dev->priv;
+ return info->ip_summed == CHECKSUM_UNNECESSARY;
+}
+
+static int etun_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct etun_info *info = dev->priv;
+
+ info->ip_summed = data ? CHECKSUM_UNNECESSARY : CHECKSUM_NONE;
+
+ return 0;
+}
+
+static u32 etun_get_tx_csum(struct net_device *dev)
+{
+ return (dev->features & NETIF_F_NO_CSUM) != 0;
+}
+
+static int etun_set_tx_csum(struct net_device *dev, u32 data)
+{
+ dev->features &= ~NETIF_F_NO_CSUM;
+ if (data)
+ dev->features |= NETIF_F_NO_CSUM;
+
+ return 0;
+}
+
+static struct ethtool_ops etun_ethtool_ops = {
+ .get_settings = etun_get_settings,
+ .get_drvinfo = etun_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_rx_csum = etun_get_rx_csum,
+ .set_rx_csum = etun_set_rx_csum,
+ .get_tx_csum = etun_get_tx_csum,
+ .set_tx_csum = etun_set_tx_csum,
+ .get_sg = ethtool_op_get_sg,
+ .set_sg = ethtool_op_set_sg,
+#if 0 /* Does just setting the bit successfuly emulate tso? */
+ .get_tso = ethtool_op_get_tso,
+ .set_tso = ethtool_op_set_tso,
+#endif
+ .get_strings = etun_get_strings,
+ .get_stats_count = etun_get_stats_count,
+ .get_ethtool_stats = etun_get_ethtool_stats,
+ .get_perm_addr = ethtool_op_get_perm_addr,
+};
+
+static int etun_open(struct net_device *tx_dev)
+{
+ struct etun_info *tx_info = tx_dev->priv;
+ struct net_device *rx_dev = tx_info->rx_dev;
+ /* If we attempt to bring up etun in the small window before
+ * it is connected to it's partner error.
+ */
+ if (!rx_dev)
+ return -ENOTCONN;
+ if (rx_dev->flags & IFF_UP) {
+ netif_carrier_on(tx_dev);
+ netif_carrier_on(rx_dev);
+ }
+ netif_start_queue(tx_dev);
+ return 0;
+}
+
+static int etun_stop(struct net_device *tx_dev)
+{
+ struct etun_info *tx_info = tx_dev->priv;
+ struct net_device *rx_dev = tx_info->rx_dev;
+ netif_stop_queue(tx_dev);
+ if (netif_carrier_ok(tx_dev)) {
+ netif_carrier_off(tx_dev);
+ netif_carrier_off(rx_dev);
+ }
+ return 0;
+}
+
+static int etun_change_mtu(struct net_device *dev, int new_mtu)
+{
+ /* Don't allow ridiculously small mtus */
+ if (new_mtu < (ETH_ZLEN - ETH_HLEN))
+ return -EINVAL;
+ dev->mtu = new_mtu;
+ return 0;
+}
+
+static void etun_set_multicast_list(struct net_device *dev)
+{
+ /* Nothing sane I can do here */
+ return;
+}
+
+static int etun_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+ return -EOPNOTSUPP;
+}
+
+/* Only allow letters and numbers in an etun device name */
+static int is_valid_name(const char *name)
+{
+ const char *ptr;
+ for (ptr =
...
|
|
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18120 is a reply to message #18118] |
Mon, 09 April 2007 18:48 |
Ben Greear
Messages: 30 Registered: June 2006
|
Member |
|
|
David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Mon, 09 Apr 2007 11:14:52 -0700
>
>> Patrick McHardy wrote:
>>
>>> It would be nice if someone would finally come up with a generic
>>> interface based on netlink (RTM_NEWLINK) instead of adding yet
>>> another couple of homegrown interfaces.
>> My preference is for ioctls, procfs, or similar that does not
>> require extra libraries. Ethtool is an ioctl based approach,
>> so that could potentially be used, though I'm not sure if
>> that's the right place to put it...
>
> I totally disagree.
>
> Netlink doesn't require libraries, the libraries just make using it
> easier. It's a simple protocol sent over a socket, if you include
> the right headers you can do it all yourself.
>
> We shouldn't fail to use our proper core network configuration
> interface just because it's inconvenient for you.
Well, I find it inconvenient, so my preference is for other
methods...that shouldn't be too supprising. I'm a lazy programmer
after all! :)
If it does get added, and something like 'ip' gains ability to
use it, then I can just system("ip whatever"), so maybe that's the
out for lazy programmers...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18127 is a reply to message #18116] |
Mon, 09 April 2007 18:45 |
Patrick McHardy
Messages: 107 Registered: March 2006
|
Senior Member |
|
|
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> It would be nice if someone would finally come up with a generic
>> interface based on netlink (RTM_NEWLINK) instead of adding yet
>> another couple of homegrown interfaces.
>
>
> My preference is for ioctls, procfs, or similar that does not
> require extra libraries. Ethtool is an ioctl based approach,
> so that could potentially be used, though I'm not sure if
> that's the right place to put it...
Extra libraries is one of the least important points in my opinion,
I also guess pretty much anyone using a software device already has
iproute installed, which could easily support all of them.
The more important things to consider are in my opinion extendability
and atomicity of changes and dumps:
- ioctls: atomicity, not easily extendable
- sysfs: no atomicity, easily extendable
- procfs: if atomicity not easily extendable, but can of course also
be used similar to sysfs
Only netlink offers both in an easy to use fashion and is already used
for the main parts of network configuration anyway.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18134 is a reply to message #18131] |
Tue, 10 April 2007 00:06 |
Patrick McHardy
Messages: 107 Registered: March 2006
|
Senior Member |
|
|
Johannes Berg wrote:
> On Mon, 2007-04-09 at 22:11 +0200, Patrick McHardy wrote:
>
>
>>Thats why I suggested that we should create one, ideally before adding
>>more sysfs/proc/ioctl/... based interfaces, which we'll have a hard time
>>getting rid of again.
>
>
> But then how would we configure initial parameters along with creating
> the interface? That's something that's good to have, and I don't see how
> you can allow it generically.
>
> Then again, you can of course always add an interface and then change
> its operating parameters etc. but that isn't atomic any more.
Same way as the current RTM_SETLINK message works, but with creating
a new link in advance. It works fine in other subsystems, so I don't
see why it would in this case as well. Some subsystems do it in an
atomic fashion (network schedulers for example), some first create
the object, then configure it (network classifiers in the non-compat
cases). In the network device case I suppose the later should work
fine since a device needs to be set UP in a second action before
it really does anything.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18144 is a reply to message #18142] |
Tue, 10 April 2007 10:46 |
Patrick McHardy
Messages: 107 Registered: March 2006
|
Senior Member |
|
|
Johannes Berg wrote:
> On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
>
>
>>Without having thought much about it yet, roughly like this:
>>
>>- driver receives RTM_NEWLINK message (under rtnl)
>>- driver allocates new device
>>- driver initializes device based on content of RTM_NEWLINK message
>>- driver returns
>
>
> Sounds good to me, but where's the advantage over something that isn't
> generic if RTM_NEWLINK contains totally different things depending on
> the subsystem like wireless where it'd have to contain the hardware
> identifier?
Not totally different, so far I think we should use the same attributes
as for RTM_SETLINK messages and include the device-specific stuff in
IFLA_PROTINFO, which is symetric to what the kernel sends in RTM_NETLINK
messages (see br_netlink.c for an example). The easiest case would be an
empty IFLA_PROTINFO attribute, which would simply create a device
without any configuration.
The main advantage that we don't get more weird sysfs/proc/ioctl based
interfaces and use the same interface that is used for all other network
configuration, which f.e. will allow to add support for all software
devices to iproute without much effort, so you don't need 30 different
tools for configuring the different software device types anymore.
Additionally we get atomic setup/dumps and extensibility.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18146 is a reply to message #18145] |
Tue, 10 April 2007 11:09 |
Patrick McHardy
Messages: 107 Registered: March 2006
|
Senior Member |
|
|
Johannes Berg wrote:
> On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
>
>
>>The main advantage that we don't get more weird sysfs/proc/ioctl based
>>interfaces
>
>
> Please don't put me into a corner I don't want to be in ;) The new
> wireless stuff was completely designed using netlink. The sysfs
> interface to these two specific things was a concession since it used to
> exist before and we don't really have a fully functional userspace tool
> yet.
I know :) It was a few month ago when I noticed the new bonding
sysfs interface when I first thought that we really need this.
>> and use the same interface that is used for all other network
>>configuration, which f.e. will allow to add support for all software
>>devices to iproute without much effort, so you don't need 30 different
>>tools for configuring the different software device types anymore.
>>Additionally we get atomic setup/dumps and extensibility.
>
>
> I don't think wireless can get away without a new tool. So much stuff
> there. Look at
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=include/linux/nl80211.h;hb=HEAD
Maybe not wireless, but bonding, briding, vlan, etun, possibly more.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18160 is a reply to message #18156] |
Wed, 11 April 2007 16:16 |
Stephen Hemminger
Messages: 37 Registered: August 2006
|
Member |
|
|
On Tue, 10 Apr 2007 23:16:59 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
> > Same way as the current RTM_SETLINK message works, but with creating
> > a new link in advance. It works fine in other subsystems, so I don't
> > see why it would in this case as well. Some subsystems do it in an
> > atomic fashion (network schedulers for example), some first create
> > the object, then configure it (network classifiers in the non-compat
> > cases). In the network device case I suppose the later should work
> > fine since a device needs to be set UP in a second action before
> > it really does anything.
>
> Looking at br_netlink.c it seems that this sort of contradicts why
> generic netlink was done, now all the sudden everything that wants to
> create new links need its own netlink protocol number, no?
>
> johannes
Bridging is different since there was already a bridge protocol number assigned,
there was no point in doing generic netlink.
---
Stephen Hemminger <shemminger@linux-foundation.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Re: [PATCH] net: Add etun driver [message #18176 is a reply to message #18156] |
Wed, 11 April 2007 16:15 |
Patrick McHardy
Messages: 107 Registered: March 2006
|
Senior Member |
|
|
Johannes Berg wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
>
>>Same way as the current RTM_SETLINK message works, but with creating
>>a new link in advance. It works fine in other subsystems, so I don't
>>see why it would in this case as well. Some subsystems do it in an
>>atomic fashion (network schedulers for example), some first create
>>the object, then configure it (network classifiers in the non-compat
>>cases). In the network device case I suppose the later should work
>>fine since a device needs to be set UP in a second action before
>>it really does anything.
>
>
> Looking at br_netlink.c it seems that this sort of contradicts why
> generic netlink was done, now all the sudden everything that wants to
> create new links need its own netlink protocol number, no?
No, generic netlink avoids allocating netlink families. br_netlink
uses the same netlink family as the other network configuration stuff
(NETLINK_ROUTE), but a different rtgen_family (which matches the
address families). But you have a valid point, if we want to use
this for things like bonding or VLAN that aren't actually address
families, we should consider introducing "rtnetlink families" to
avoid adding AF_BONDING, AF_8021Q etc.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Re: [PATCH] net: Add etun driver [message #18177 is a reply to message #18176] |
Wed, 11 April 2007 16:43 |
Johannes Berg
Messages: 16 Registered: April 2007
|
Junior Member |
|
|
On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
> No, generic netlink avoids allocating netlink families.
Well, yes, I thought that was pretty much the point. :)
> br_netlink
> uses the same netlink family as the other network configuration stuff
> (NETLINK_ROUTE), but a different rtgen_family (which matches the
> address families).
Ah ok. I got all the family types confused then.
> But you have a valid point, if we want to use
> this for things like bonding or VLAN that aren't actually address
> families, we should consider introducing "rtnetlink families" to
> avoid adding AF_BONDING, AF_8021Q etc.
True.
But this still doesn't help wireless which doesn't have either an
rtnetlink family nor an address family since it uses generic netlink
exclusively.
johannes
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
Re: [PATCH] net: Add etun driver [message #18179 is a reply to message #18178] |
Wed, 11 April 2007 16:59 |
Johannes Berg
Messages: 16 Registered: April 2007
|
Junior Member |
|
|
On Wed, 2007-04-11 at 18:52 +0200, Patrick McHardy wrote:
> I'm not sure I'm following. I was under the impression that the
> conclusion of yesterdays discussion was that its probably not
> worth using rtnetlink for wireless so it will continue to use
> generic netlink exclusively, but even if that is wrong, nothing
> would prevent adding a "rtnetlink family" for wireless as well.
Oh, ok. Yeah nothing stops us from doing that, of course.
johannes
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
Goto Forum:
Current Time: Fri Oct 18 23:09:06 GMT 2024
Total time taken to generate the page: 0.04933 seconds
|