search for: tunsetiff

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 TUNSETIFF. 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 f...

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 TUNSETIFF. 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 f...

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 TUNSETIFF. 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 f...

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 TUNSETIFF. 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 f...

...gt; > > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > > > scenario). > > > > > > The tap device is effectively created in that function - [2] - by > > > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > > > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > > > NET_ADMIN capability. If I'm correct, this means that the current > > > libvirt implementation makes our goals impossible to achieve. > > > > AFAIK, that is not correct - CAP_NET_ADMIN isn't requi...

...; currently supported, since we'll *always* enter the > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > scenario). > > The tap device is effectively created in that function - [2] - by > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > NET_ADMIN capability. If I'm correct, this means that the current > libvirt implementation makes our goals impossible to achieve. AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open or create a tap device - on...

...oblems using the tap device tincd just keeps printing this error: Error while reading from Linux ethertap device /dev/net/tun: File descriptor in bad state I guess the problem is I cannot manage tun/tap devices on the planet lab nodes even if I am root :( Look at this: bash-3.2# /usr/sbin/tunctl TUNSETIFF: Operation not permitted bash-3.2# whoami root bash-3.2# I know this is more a planetlab problem than I tinc problem and I am offtopic, but I am really looking for some hints, so if anybody can help me please write me an email even privately. thanks Saverio [0] - https://www.planet-lab.eu/

? ? ? Hi, all:? ? ? ? ? I'm playing with Gre Tunnel programming in centos 6. ? ? ? ?? ? ? ? ? I wrote my program in these steps:? ? ? ? ? a, open /dev/net/tun ?device and ioctl with?TUNSETIFF, get fd to tun device, say "tun0"; ? ? ? ? b, create one socket and use it to set tun0's ?ip address, namyly?SIOCSIFADDR and?SIOCSIFDSTADDR; and then turn it up; ? ? ? ? c, create one raw socket to send things which got from the tun0 device to other machine, and to receive packages wh...

...ty, which requires the UID / GID of the tap creator / opener to match, as per the kernel code in [0]. As such, we create the tap device (with the qemu user / group on behalf of qemu), which will ultimately be the tap consumer. This leads me to question: why is libvirt opening / calling `ioctl(..., TUNSETIFF, ...) ` on the tap device when it already exists - [1] & [2] ? Why can't the tap device (already configured) be left alone, and let qemu consume it ? The above is problematic for KubeVirt, since our setup currently has libvirt running as root (while qemu runs as a different user), which is...

[This email is either empty or too large to be displayed at this time]

...;s M:N implementation of multiqueue but I didn't test it. The idea is simple: each socket were abstracted as a queue for tun/tap, and userspace may open as many files as required and then attach them to the devices. In order to keep the ABI compatibility, device creation were still finished in TUNSETIFF, and two new ioctls TUNATTACHQUEUE and TUNDETACHQUEUE were added for user to manipulate the numbers of queues for the tun/tap. I've done some basic performance testing of multi queue tap. For tun, I just test it through vpnc. Notes: - Test shows improvement when receving packets from local/ex...

...;s M:N implementation of multiqueue but I didn't test it. The idea is simple: each socket were abstracted as a queue for tun/tap, and userspace may open as many files as required and then attach them to the devices. In order to keep the ABI compatibility, device creation were still finished in TUNSETIFF, and two new ioctls TUNATTACHQUEUE and TUNDETACHQUEUE were added for user to manipulate the numbers of queues for the tun/tap. I've done some basic performance testing of multi queue tap. For tun, I just test it through vpnc. Notes: - Test shows improvement when receving packets from local/ex...

On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: >> Hi all, >> >> I'm aware that it is possible to plug pre-created macvtap devices to >> libvirt guests - tracked in RFE [0]. >> >> My interpretation of the wording in [1] and [2] is that it is also >> possible to plug

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

....h +++ b/include/linux/if_tun.h @@ -45,6 +45,7 @@ #define TUNGETFEATURES _IOR('T', 207, unsigned int) #define TUNSETOFFLOAD _IOW('T', 208, unsigned int) #define TUNSETTXFILTER _IOW('T', 209, unsigned int) +#define TUNGETIFF _IOR('T', 210, unsigned int) /* TUNSETIFF ifr flags */ #define IFF_TUN 0x0001 -- 1.5.4.1

....h +++ b/include/linux/if_tun.h @@ -45,6 +45,7 @@ #define TUNGETFEATURES _IOR('T', 207, unsigned int) #define TUNSETOFFLOAD _IOW('T', 208, unsigned int) #define TUNSETTXFILTER _IOW('T', 209, unsigned int) +#define TUNGETIFF _IOR('T', 210, unsigned int) /* TUNSETIFF ifr flags */ #define IFF_TUN 0x0001 -- 1.5.4.1

...#define TUNGETFILTER _IOR('T', 219, struct sock_fprog) > #define TUNSETVNETLE _IOW('T', 220, int) > #define TUNGETVNETLE _IOR('T', 221, int) > +#define TUNSETVNETBE _IOW('T', 222, int) > +#define TUNGETVNETBE _IOR('T', 223, int) > > /* TUNSETIFF ifr flags */ > #define IFF_TUN 0x0001

...#define TUNGETFILTER _IOR('T', 219, struct sock_fprog) > #define TUNSETVNETLE _IOW('T', 220, int) > #define TUNGETVNETLE _IOR('T', 221, int) > +#define TUNSETVNETBE _IOW('T', 222, int) > +#define TUNGETVNETBE _IOR('T', 223, int) > > /* TUNSETIFF ifr flags */ > #define IFF_TUN 0x0001

...+ tun->txflt.count = 0; tun_net_init(dev); @@ -751,6 +793,7 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file, struct tun_struct *tun = file->private_data; void __user* argp = (void __user*)arg; struct ifreq ifr; + int ret; DECLARE_MAC_BUF(mac); if (cmd == TUNSETIFF || _IOC_TYPE(cmd) == 0x89) @@ -826,9 +869,6 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file, break; case TUNSETLINK: - { - int ret; - /* Only allow setting the type when the interface is down */ rtnl_lock(); if (tun->dev->flags & IFF_UP) { @@ -842,94 +8...