When a tap interface is created with openvpn --mktun (what the initscripts do by default if it is available), it can not be used by UML or VDE. It can be used with openvpn itself though. #define SIOCSIFTXQLEN 0 in openvpn fixes the problem. My suggestions is to make tunctl from usermode-utilities the default, because it works with everything I have tested. Reproducible: Always Steps to Reproduce:
Created attachment 121404 [details, diff] Make tunctl the default for tun/tap creation.
Comment on attachment 121404 [details, diff] Make tunctl the default for tun/tap creation. this patch is whitespace damaged
Created attachment 121480 [details, diff] Corrected version
(In reply to comment #0) > When a tap interface is created with openvpn --mktun (what the initscripts do > by default if it is available), it can not be used by UML or VDE. Why? What is wrong with the tap interface? The reason why we prefer openvpn is simply because it's available on many more platforms.
Please tell us why openvpn created tun/tap devices fail for you.
Sorry, I didn't see your first post. in tun.c from openvpn there is a line: if (ioctl (ctl_fd, SIOCSIFTXQLEN, (void *) &netifr) >= 0) If I remember correctly, commenting that out will fix it. I could be wrong though. When it is not fixed, any other application using an openvpn-created tap device can't send any packets through it. I have tried UML and QEMU.
All openvpn versions in the tree create tun/tap interfaces with the correct defaults now as I patched them for this. The default is 100. What do you think the correct value or behaviour should be?
Need more info, sorry
