search for: tap

...BLIC KEY----- ---------------------------------------------------------------------------- ----------- Log on Windows (support). First ping fails, then (after pinged one time from office to support) it starts working: tincd -n office -d5 -D tincd 1.0.7 (Jan 5 2007 15:26:38) starting, debug level 5 Tap reader running {091E295E-E35A-4C52-A9D1-1CCD3C7176DE} (office) is a Windows tap device Listening on 0.0.0.0 port 655 Ready Trying to connect to office (111.111.111.111 port 655) Connected to office (111.111.111.111 port 655) Sending ID to office (111.111.111.111 port 655): 0 support 17 Sending 12 b...

On Thu, Sep 06, 2018 at 12:05:25PM +0800, Jason Wang wrote: > This patch implement TUN_MSG_PTR msg_control type. This type allows > the caller to pass an array of XDP buffs to tuntap through ptr field > of the tun_msg_control. Tap will build skb through those XDP buffers. > > This will avoid lots of indirect calls thus improves the icache > utilization and allows to do XDP batched flushing when doing XDP > redirection. > > Signed-off-by: Jason Wang <ja...

...------------------------------------------------------ Backport of the following patch from development: # User Ian Campbell <[hidden email]> # Date 1309968705 -3600 # Node ID e4781aedf817c5ab36f6f3077e44c43c566a2812 # Parent 700d0f03d50aa6619d313c1ff6aea7fd429d28a7 libxl: attempt to cleanup tapdisk processes on disk backend destroy. This patch properly terminates the tapdisk2 process(es) started to service a virtual block device. Signed-off-by: Greg Wettstein <greg@enjellic.com> diff -r 700d0f03d50a tools/blktap2/control/tap-ctl-list.c --- a/tools/blktap2/control/tap-ctl-list.c M...

...0-10.0 sec 2.12 MBytes 17.8 Mbits/sec 0.794 ms 321/ 389 (83%) [ 4] 0.0-10.3 sec 51.5 MBytes 42.2 Mbits/sec 8.437 ms 2168/ 3817 (57%) Debug output: of tincd when above is run. Received packet of 1450 bytes from server (10.172.241.254 port 655) Writing packet of 1450 bytes to Linux tun/tap device (tap mode) Received packet of 96 bytes from server (10.172.241.254 port 655) Writing packet of 96 bytes to Linux tun/tap device (tap mode) Got REQ_KEY from server (10.172.241.254 port 655): 15 server hostA 21 .....key is removed from here.... and for lines below .... Received packet of 1450...

Hello, I'm wondering if anyone out there is doing tap:aio disk devices on a Xen HVM vm with any success. Please let me know if you are, and perhaps your version info and a config file snippet. I've posted this to the xen-users list, and what I'm trying to do seems to be correct, works on Ubuntu, Debian, and XenSource; but it doesn't work...

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 pre-created tap devices into libvirt guests - that >> would be a requirement to allow kubevirt to run with less capabilities...

...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 pre-created tap devices into libvirt guests - that...

Hello, On KubeVirt, we are trying to pre-create a tap device, then instruct libvirt to consume it (via the type=ethernet , managed='no' attributes). It works as expected, **unless** when we create a multi-queue tap device. The difference when creating the tap device is that we set the multi-queue flag; libvirt throws the following error when...

This patch implement TUN_MSG_PTR msg_control type. This type allows the caller to pass an array of XDP buffs to tuntap through ptr field of the tun_msg_control. Tap will build skb through those XDP buffers. This will avoid lots of indirect calls thus improves the icache utilization and allows to do XDP batched flushing when doing XDP redirection. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drive...

...at.com> wrote: > > > > 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 pre-created tap devices into libvirt guests - that > > >> would be a requiremen...

Etienne Dechamps <etienne at ...> writes: > > You should mention your tinc version and the version of the > "TAP-Windows Adapter V9" driver for the virtual network device you're > using (i.e. the contents of "Driver version" as seen in the Device > Manager). > > On Mon, Dec 15, 2014 at 10:04 PM, Adam Del Vecchio <adam at ...> wrote: > > Hello tincers, > > >...

Hello everyone, I am running into the following error messages everytime I try to use a docker overlay network on top of tinc-vpn: Error getting read result from Windows tap device {F30C422F-4524-435F-A15B-71A7E08C260D}: (995) The I/O operation has been aborted because of either a thread exit or an application request. Received packet of 106 bytes from ... (... port 655) Writing packet of 106 bytes to Windows tap device Error while writing to Windows tap device {F30C42...

Hello tincers, I was recently trying to add a new Windows client to my tinc network and ran into an interesting error; upon starting tinc I am met with the usual successful startup (debug level 0; detects TAP device; Ready), however it appears that any writes/reads from the TAP device fail with: "Error while writing to Windows tap device <device ID truncated>: (997) Overlapped I/O operation is in progress" A bit of googling doesn't reveal much except some possible intrusions by a...

It was reported that the macvtap device selects a different vhost (when used with multiqueue feature) for incoming packets of a single connection. Use packet hash first. Patch tested on MQ virtio_net. Signed-off-by: Krishna Kumar <krkumar2 at in.ibm.com> --- drivers/net/macvtap.c | 16 ++++++++-------- 1 file changed, 8...

It was reported that the macvtap device selects a different vhost (when used with multiqueue feature) for incoming packets of a single connection. Use packet hash first. Patch tested on MQ virtio_net. Signed-off-by: Krishna Kumar <krkumar2 at in.ibm.com> --- drivers/net/macvtap.c | 16 ++++++++-------- 1 file changed, 8...

If VHOST_NET is configured but TUN and TAP are not, then the kernel will build but vhost will not work correctly since it can't setup the necessary tap device. A solution is to select it. Fixes: 9a393b5d5988 ("tap: tap as an independent module") Signed-off-by: Stephen Hemminger <stephen at networkplumber.org> --- driv...

On Wed, Sep 23, 2020 at 05:44:28PM +0100, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2020 at 01:48:08PM +0200, Miguel Duarte de Mora Barroso wrote: > > Hello, > > > > On KubeVirt, we are trying to pre-create a tap device, then instruct > > libvirt to consume it (via the type=ethernet , managed='no' > > attributes). > > > > It works as expected, **unless** when we create a multi-queue tap device. > > > > The difference when creating the tap device is that we set t...

...PM Laine Stump <lstump@redhat.com> wrote: > > 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 pre-created tap devices into libvirt guests - that > >> would be a requirement to allow kubevirt to ru...

...and paravirtualized Linux DomU works fine with QCOW and raw images. If i use QCOW images with my Windows DomU''s i get a stop error: 0x00000007b (inaccessible boot device). It looks like the blkback.3.hda process, that normally starts with normal raw backend, doesnt get started with tap:qcow disks. Instead i get this repeating entry in the qemu log: XenPCI Still waiting for 2 (currently 1)... XenPCI Still waiting for 2 (currently 1)... XenPCI Still waiting for 2 (currently 1)... Any ideas? /Martin _______________________________________________ Xen-u...

Hello, I'm having some doubts about consuming an existing - already configured - tap device from libvirt (with `managed='no' ` attribute set). In KubeVirt, we want to have the consumer side of the tap device run without the NET_ADMIN capability, 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 devi...