1. 13 Oct, 2012 1 commit
  2. 03 May, 2010 1 commit
    • Michael S. Tsirkin's avatar
      tun: add ioctl to modify vnet header size · d9d52b51
      Michael S. Tsirkin authored
      virtio added mergeable buffers mode where 2 bytes of extra info is put
      after vnet header but before actual data (tun does not need this data).
      In hindsight, it would have been better to add the new info *before* the
      packet: as it is, users need a lot of tricky code to skip the extra 2
      bytes in the middle of the iovec, and in fact applications seem to get
      it wrong, and only work with specific iovec layout.  The fact we might
      need to split iovec also means we might in theory overflow iovec max
      This patch adds a simpler way for applications to handle this,
      and future proofs the interface against further extensions,
      by making the size of the virtio net header configurable
      from userspace. As a result, tun driver will simply
      skip the extra 2 bytes on both input and output.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 17 Feb, 2010 1 commit
  4. 15 Jan, 2010 1 commit
  5. 17 Jul, 2009 1 commit
  6. 27 Apr, 2009 1 commit
    • David Woodhouse's avatar
      tun: add IFF_TUN_EXCL flag to avoid opening a persistent device. · f85ba780
      David Woodhouse authored
      When creating a certain types of VPN, NetworkManager will first attempt
      to find an available tun device by iterating through 'vpn%d' until it
      finds one that isn't already busy. Then it'll set that to be persistent
      and owned by the otherwise unprivileged user that the VPN dæmon itself
      runs as.
      There's a race condition here -- during the period where the vpn%d
      device is created and we're waiting for the VPN dæmon to actually
      connect and use it, if we try to create _another_ device we could end up
      re-using the same one -- because trying to open it again doesn't get
      -EBUSY as it would while it's _actually_ busy.
      So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to
      fail if it would be opening an existing persistent tundevice -- so that
      we can make sure we're getting an entirely _new_ device.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 05 Feb, 2009 1 commit
    • Herbert Xu's avatar
      tun: Limit amount of queued packets per device · 33dccbb0
      Herbert Xu authored
      Unlike a normal socket path, the tuntap device send path does
      not have any accounting.  This means that the user-space sender
      may be able to pin down arbitrary amounts of kernel memory by
      continuing to send data to an end-point that is congested.
      Even when this isn't an issue because of limited queueing at
      most end points, this can also be a problem because its only
      response to congestion is packet loss.  That is, when those
      local queues at the end-point fills up, the tuntap device will
      start wasting system time because it will continue to send
      data there which simply gets dropped straight away.
      Of course one could argue that everybody should do congestion
      control end-to-end, unfortunately there are people in this world
      still hooked on UDP, and they don't appear to be going away
      anywhere fast.  In fact, we've always helped them by performing
      accounting in our UDP code, the sole purpose of which is to
      provide congestion feedback other than through packet loss.
      This patch attempts to apply the same bandaid to the tuntap device.
      It creates a pseudo-socket object which is used to account our
      packets just as a normal socket does for UDP.  Of course things
      are a little complex because we're actually reinjecting traffic
      back into the stack rather than out of the stack.
      The stack complexities however should have been resolved by preceding
      patches.  So this one can simply start using skb_set_owner_w.
      For now the accounting is essentially disabled by default for
      backwards compatibility.  In particular, we set the cap to INT_MAX.
      This is so that existing applications don't get confused by the
      sudden arrival EAGAIN errors.
      In future we may wish (or be forced to) do this by default.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 15 Aug, 2008 1 commit
  9. 14 Jul, 2008 1 commit
    • Max Krasnyansky's avatar
      tun: Fix/rewrite packet filtering logic · f271b2cc
      Max Krasnyansky authored
      Please see the following thread to get some context on this
      Basically the issue is that current multi-cast filtering stuff in
      the TUN/TAP driver is seriously broken.
      Original patch went in without proper review and ACK. It was broken and
      confusing to start with and subsequent patches broke it completely.
      To give you an idea of what's broken here are some of the issues:
      - Very confusing comments throughout the code that imply that the
      character device is a network interface in its own right, and that packets
      are passed between the two nics. Which is completely wrong.
      - Wrong set of ioctls is used for setting up filters. They look like
      shortcuts for manipulating state of the tun/tap network interface but
      in reality manipulate the state of the TX filter.
      - ioctls that were originally used for setting address of the the TX filter
      got "fixed" and now set the address of the network interface itself. Which
      made filter totaly useless.
      - Filtering is done too late. Instead of filtering early on, to avoid
      unnecessary wakeups, filtering is done in the read() call.
      The list goes on and on :)
      So the patch cleans all that up. It introduces simple and clean interface for
      setting up TX filters (TUNSETTXFILTER + tun_filter spec) and does filtering
      before enqueuing the packets.
      TX filtering is useful in the scenarios where TAP is part of a bridge, in
      which case it gets all broadcast, multicast and potentially other packets when
      the bridge is learning. So for example Ethernet tunnelling app may want to
      setup TX filters to avoid tunnelling multicast traffic. QEMU and other
      hypervisors can push RX filtering that is currently done in the guest into the
      host context therefore saving wakeups and unnecessary data transfer.
      Signed-off-by: default avatarMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 03 Jul, 2008 3 commits
    • Rusty Russell's avatar
      tun: Allow GSO using virtio_net_hdr · f43798c2
      Rusty Russell authored
      Add a IFF_VNET_HDR flag.  This uses the same ABI as virtio_net
      (ie. prepending struct virtio_net_hdr to packets) to indicate GSO and
      checksum information.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Rusty Russell's avatar
      tun: TUNSETFEATURES to set gso features. · 5228ddc9
      Rusty Russell authored
      ethtool is useful for setting (some) device fields, but it's
      root-only.  Finer feature control is available through a tun-specific
      (Includes Mark McLoughlin <markmc@redhat.com>'s fix to hold rtnl sem).
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Rusty Russell's avatar
      tun: Interface to query tun/tap features. · 07240fd0
      Rusty Russell authored
      The problem with introducing checksum offload and gso to tun is they
      need to set dev->features to enable GSO and/or checksumming, which is
      supposed to be done before register_netdevice(), ie. as part of
      Unfortunately, TUNSETIFF has always just ignored flags it doesn't
      understand, so there's no good way of detecting whether the kernel
      supports new IFF_ flags.
      This patch implements a TUNGETFEATURES ioctl which returns all the valid IFF
      flags.  It could be extended later to include other features.
      Here's an example program which uses it:
      #include <linux/if_tun.h>
      #include <sys/types.h>
      #include <sys/ioctl.h>
      #include <sys/stat.h>
      #include <fcntl.h>
      #include <err.h>
      #include <stdio.h>
      static struct {
      	unsigned int flag;
      	const char *name;
      } known_flags[] = {
      	{ IFF_TUN, "TUN" },
      	{ IFF_TAP, "TAP" },
      	{ IFF_NO_PI, "NO_PI" },
      	{ IFF_ONE_QUEUE, "ONE_QUEUE" },
      int main()
      	unsigned int features, i;
      	int netfd = open("/dev/net/tun", O_RDWR);
      	if (netfd < 0)
      		err(1, "Opening /dev/net/tun");
      	if (ioctl(netfd, TUNGETFEATURES, &features) != 0) {
      		printf("Kernel does not support TUNGETFEATURES, guessing\n");
      		features = (IFF_TUN|IFF_TAP|IFF_NO_PI|IFF_ONE_QUEUE);
      	printf("Available features are: ");
      	for (i = 0; i < sizeof(known_flags)/sizeof(known_flags[0]); i++) {
      		if (features & known_flags[i].flag) {
      			features &= ~known_flags[i].flag;
      			printf("%s ", known_flags[i].name);
      	if (features)
      		printf("(UNKNOWN %#x)", features);
      	return 0;
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarMax Krasnyansky <maxk@qualcomm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 11 Jun, 2008 1 commit
  12. 12 Apr, 2008 1 commit
  13. 28 Jan, 2008 1 commit
  14. 10 Oct, 2007 1 commit
  15. 10 Jul, 2007 1 commit
  16. 01 Sep, 2005 1 commit
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!