Opened 14 years ago
Closed 14 years ago
#7649 closed defect (fixed)
bridged networking does not work starting with 2.6.36 on TAP-devices => Fixed in SVN
| Reported by: | Michael Kromer | Owned by: | |
|---|---|---|---|
| Component: | network | Version: | VirtualBox 3.2.10 |
| Keywords: | Cc: | ||
| Guest type: | Linux | Host type: | Linux |
Description (last modified by )
As you can read on
http://amailbox.org/mailarchive/linux-netdev/2010/10/23/6288128/thread
VBox stops working with bridged Networking and TAP devices since 2.6.36.
I don't think VBox.log will help you much, the only thing which might help is that transmits are ok, but recv is completely dead.
A short test with
#include <fcntl.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <net/if.h>
#include <linux/if_tun.h>
int main(int argc, const char **argv)
{
struct ifreq ifr;
char *p;
int fd;
if (argc < 2) {
fprintf(stderr, "Need tun name\n");
return EXIT_FAILURE;
}
fd = open("/dev/net/tun", O_RDWR);
if (fd < 0) {
perror("open");
return EXIT_FAILURE;
}
memset(&ifr, 0, sizeof(ifr));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
p = strncpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name) - 1);
if (ioctl(fd, TUNSETIFF, &ifr) < 0) {
perror("ioctl");
return EXIT_FAILURE;
}
while (true)
sleep(3600);
return EXIT_SUCCESS;
}
results in a positive fix.
I think the problem is, that vboxnetflt simply transmits via skb->dev=tapX and doesn't open the tap/tun fd. The upstream (kernel) patch is suboptimal for vbox in a way that it actually needs to open the file descriptor - otherwise the interface has status NO-CARRIER and packets will not be accepted by core kernel.
Attachments (1)
Change History (12)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 14 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | bridged networking does not work starting with 2.6.35 on TAP-devices → bridged networking does not work starting with 2.6.36 on TAP-devices |
comment:4 by , 14 years ago
I've attached the patch that should fix the problem. Can you try it out? Please apply it in your virtualbox install directory and then run
/etc/init.d/vboxdrv setup
to rebuild netfilter module.
by , 14 years ago
| Attachment: | netflt_tap.patch added |
|---|
comment:6 by , 14 years ago
| Summary: | bridged networking does not work starting with 2.6.36 on TAP-devices → bridged networking does not work starting with 2.6.36 on TAP-devices => Fixed in SVN |
|---|
Thanks for the feedback! The fix will be included in the next maintenance release.
comment:7 by , 14 years ago
As far as I can read the code this patch only works for devices named tapX, which is rather suboptimal, as TAP-Devices can hold any name (which is also used pretty often AFAIK).
Wouldn't it be better to identify TAP-Devices via ioctl(TUNSETLINK) and dev->type (other than ARPHRD_ETHER)? Would not need any patches to distributions and/or kernel, but temporarily need exclusive access to the interface (because of ioctl(TUNSETIFF)).
comment:8 by , 14 years ago
This patch should work with any device name as long as it is created with standard Linux tun/tap driver. It uses driver identification, not the device name to detect tap device. Just try it with any name different from tapX.
comment:9 by , 14 years ago
If you are curious why it should work please take a look at the implementation of the function the patch code calls: http://lxr.linux.no/linux+v2.6.36/drivers/net/tun.c#L1543
comment:10 by , 14 years ago
Btw, this patch is applied to vboxnetflt module which is not a part of kernel/distrubutions. It is included in vbox package. And the reason we are not using ioctl is that, given the existing design of vbox networking, it is really preferable to do all bridging-related code in kernel space. Using ioctl approach is not the right thing to do in kernel space.
Thanks a lot for cooperation and pointing out the problem and possible solution. It really helped to solve the issue quickly.


Correction: Problem exists since 2.6.36, not 2.6.35 with commit bee31369ce16fc3898ec9a54161248c9eddb06bc (follow the link posted, it provides exact information)