Opened 14 years ago
Last modified 5 months ago
#8698 reopened defect
VirtualBox Host-Only Network Adapter prevents multicast traffic
Reported by: | Michael Irigoyen | Owned by: | |
---|---|---|---|
Component: | network | Version: | VirtualBox 4.0.4 |
Keywords: | multicast nic network | Cc: | |
Guest type: | other | Host type: | Windows |
Description (last modified by )
After installing Oracle VirtualBox and VirtualBox installing the "VirtualBox Host-Only Network" on my Windows 7 64-bit machine, I am no longer able to receive multicast streams on the host machine. This problem occurs even when VirtualBox is not running.
To get around this issue, I have to go into Network Connections everytime I want to stream from a multicast source and disable the VirtualBox Host-Only Network adapter. I then have to remember to reenable it everytime I wish to use VirtualBox.
Attachments (2)
Change History (35)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I have found a workaround: create a script that runs at startup (instructions here: http://technet.microsoft.com/en-us/library/cc770556.aspx) that turns the network interface off and on again:
REM Have you tried to turn it off and on again? REM Fix for VirtualBox issue #8698 and #9532 that prevents receiving multicast packets wmic path win32_networkadapter where name="VirtualBox Host-Only Ethernet Adapter" call disable wmic path win32_networkadapter where name="VirtualBox Host-Only Ethernet Adapter" call ensable
comment:3 by , 12 years ago
I confirm this bug for 4.2.0 r80737 on Windows 7 x64 (and would like to see it fixed).
comment:4 by , 12 years ago
Workaround -
1. Open up Network and Sharing Center
2. Click 'Change Adapter Settings'
3. Right click 'VirtualBox Host-Only Network', go to Properties
4. Double click "Internet Protocol Version 4 (TCP/IPv4)' under 'This connection uses the following items'.
5. In the Properties page, click "Advanced..."
6. In the "Advanced TCP/IP Settings", tab "IP Settings", uncheck the box marked "Automatic Metic" and type in 800 or higher.
OK all dialogs and run whatever software could not Recieve multicast.
The problem stems from Microsoft assigning interface Metrics based on the driver's own reported Link speed in Windows 7. Since that's all 1GB, there is a clash on metric. To Confirm, view the metrics for each adapter by opening up Command Line and running:
>netstat -nr IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.210.50.1 10.210.50.90 20 10.210.50.0 255.255.255.0 On-link 10.210.50.90 276 10.210.50.90 255.255.255.255 On-link 10.210.50.90 276 10.210.50.255 255.255.255.255 On-link 10.210.50.90 276 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.56.0 255.255.255.0 On-link 192.168.56.1 656 192.168.56.1 255.255.255.255 On-link 192.168.56.1 656 192.168.56.255 255.255.255.255 On-link 192.168.56.1 656 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.56.1 656 224.0.0.0 240.0.0.0 On-link 10.210.50.90 276 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.56.1 656 255.255.255.255 255.255.255.255 On-link 10.210.50.90 276 ===========================================================================
You want your internet/LAN adapter to have the LOWEST Metric for the general 224.xxxx and 225 cases.
comment:5 by , 9 years ago
Hello,
For years this has been causing a trouble for our customers using our product DocYard.
It blocks UDP multicast messages, and is very time consuming to debug: two employees here and two more at the customer site took more than 3 hours to figure it out.
This is very pathological behavior.
Please put some resources on resolving it.
comment:6 by , 9 years ago
Description: | modified (diff) |
---|
Stevan, sorry that this is causing so much frustration. Since we unfortunately can't promise to allocate resources to this (not saying it won't happen, but our resources are limited and the things for them to do many), if this is causing you problems in your business you might consider asking or hiring someone to look at the source code and find the problem. We generally do integrate fixes from developers competent at creating and submitting them. As a developer and not a sales person I unfortunately can't say if there is a way for you to purchase this support from Oracle, but if you are using VirtualBox in a business-critical way a support contract might make sense for you.
comment:7 by , 9 years ago
Hello Stevan,
We have prepared a Virtual Box test build for you. You can download the Windows version here: https://www.virtualbox.org/wiki/Testbuilds. In this build we set default metric value for newly created host only interface. Please, check that it helps and write us results.
Sincerely yours, Alexey
follow-up: 10 comment:9 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I use VirtualBox 5.1.18 on Win7x64, and the problem persists there.
The workaround suggested above by shuckc, in fact, works. But I think that, technically, it's a wrong way to solve this issue (to manipulate with the metric of the interface). In my case (which seems to be the most common) the VirtualBox network does not have a gateway (the "Default gateway" property of the interface is empty). Therefore, this network interface must not influence routing of packets that do not directly belong to this private network. It doesn't matter, whether metric of the interface is large or not. So, in other words, the line like
224.0.0.0 240.0.0.0 On-link 192.168.56.1 656
in the route table (see above the message of shuckc) must not exist at all.
So, I suggest that VirtualBox must not add this line to the route table.
follow-up: 11 comment:10 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Replying to dele:
So, I suggest that VirtualBox must not add this line to the route table.
It does not. The OS does that automatically.
follow-up: 12 comment:11 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Replying to vushakov:
It does not. The OS does that automatically.
So, this just means that every time when VirtualBox network interface restarts, its driver must remove the wrong line from the route table itself. The manual command for this is
route delete 224.0.0.0 if 30
where the number "30" must be changed, if the number of the VirtualBox network interface is different.
Why have you set the resolution to "fixed", if it was not fixed? This is a serious problem. Currently VirtualBox behaves like malware that blocks IPTV. And it is very difficult even to figure out the source of the problem.
follow-up: 13 comment:12 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Replying to dele:
Replying to vushakov:
It does not. The OS does that automatically.
So, this just means that every time when VirtualBox network interface restarts, its driver must remove the wrong line from the route table itself. The manual command for this is
route delete 224.0.0.0 if 30where the number "30" must be changed, if the number of the VirtualBox network interface is different.
Why have you set the resolution to "fixed", if it was not fixed? This is a serious problem. Currently VirtualBox behaves like malware that blocks IPTV. And it is very difficult even to figure out the source of the problem.
I (will) keep setting it back to fixed because you do not describe what your problem actually is and instead tell us what VirtualBox should do in your opinion.
Please, state your exact problem completely. The version of VirtualBox, what do you do, what happens, what you expect to happen, the routing table, etc, etc.
comment:13 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Replying to vushakov:
I (will) keep setting it back to fixed because you do not describe what your problem actually is and instead tell us what VirtualBox should do in your opinion. Please, state your exact problem completely. The version of VirtualBox, what do you do, what happens, what you expect to happen, the routing table, etc, etc.
Ok, this sounds reasonable. Though, I thought it should be obvious from what people wrote here before.
I have a computer with Win7x64. It is connected to the Internet. And my ISP allows me to watch IPTV. For this I use VLC MP 2.2.4.
I also have VirtualBox 5.1.18 on that computer. And therefore I have "VirtualBox Host-Only Network" interface on that computer. When this interface is enabled (which is by default), I can not watch IPTV.
So, this is the problem: Installation of VirtualBox breaks IPTV.
Certainly, I expect that installation of VirtualBox will not break IPTV. And I'm pretty sure that 99% of users, who have IPTV, expect the same. They don't want to play with interfaces, metrics and route tables.
follow-up: 15 comment:14 by , 8 years ago
- What is IPTV? Wikipedia does not have an entry for it.
- Why does a hardware emulator need to know what is IPTV? Does Acer/Apple/Dell/IBM/HP/Lenovo care about it?
- 99% of the users (according to who?) of IPTV users should be roughly about 3 people. 1 has complained so far.
- Why would a hardware driver need to care about it?
- Why do you need to have the HostOnly driver installed? You can skip it during installation, if that's what you believe is causing the problem, and not the buggy way that Microsoft decided to assign "metrics"?
- If skipping during installation is not an option, you can always disable the network interface at will. AKA a known workaround.
- If disabling the network interface breaks other functionality, you can change the metric. AKA a known workaround.
- Did you complain to Microsoft about their "algorithm"?
- Did you complain to the IPTV provider about that?
Bottom line: if a lot of users don't show it's a VirtualBox problem, the priority is not going to be that high. If a lot of users don's show the exact mechanism that this affects a lot of users, the priority is not going to be that high. If the developers can't reproduce it (do I have to have an IPTV subscription?), the priority is not going to be that high.
Take a look at the number of open tickets and judge them according to priority (not necessarily yours). Please tell me how high would you rate your problem...
PS. One solution to accommodate Windows' logic would be to change the speed capability reported by the HostOnly controller and rate it at 9600 bps (think modem). If that's even doable. That would definitely put it on the low end of the list of the Windows metrics...
comment:15 by , 8 years ago
Replying to socratis:
What is IPTV? Wikipedia does not have an entry for it.
No, it has: https://en.wikipedia.org/wiki/IPTV
Why does a hardware emulator need to know what is IPTV? Does Acer/Apple/Dell/IBM/HP/Lenovo care about it?
Multiple hardware network interfaces are rare among inexperienced home users. They are not toys for lamers. But VirtualBox is such a toy. :)
99% of the users (according to who?) of IPTV users should be roughly about 3 people. 1 has complained so far.
No, I don't think so. The problem is that it is quite difficult to understand, that VirtualBox is the source of the problem.
Why would a hardware driver need to care about it?
As I said above, a true hardware driver, probably, has less reasons to care about this.
Why do you need to have the HostOnly driver installed? You can skip it during installation, if that's what you believe is causing the problem, and not the buggy way that Microsoft decided to assign "metrics"?
Then, during the installation process VirtualBox must give notice that it will break IPTV. This could be a possible solution. But not the best, I think.
And, as I said above, it seems to me, the true problem is not with metrics, but with a redundant line in the route table.
If skipping during installation is not an option, you can always disable the network interface at will. AKA a known workaround.
If I already know this solution, I can do that. (Though this is very inconvenient.) But the main problem is that this solution is not obvious at all.
If disabling the network interface breaks other functionality, you can change the metric. AKA a known workaround.
Again, this solution is not obvious at all.
Did you complain to Microsoft about their "algorithm"?
No. Possibly, their algorithm is not best in all cases. But it is understandable to some extent. I'm not sure that this should be considered as a bug of Microsoft. But definitely Microsoft provided all necessary means to make necessary corrections in the specific case of VirtualBox.
Did you complain to the IPTV provider about that?
Yes. This was my ISP, who explained to me, that the source of the problem is VirtualBox interface. I didn't even suspect it.
Take a look at the number of open tickets and judge them according to priority (not necessarily yours). Please tell me how high would you rate your problem...
I don't know. Anyway, I believe that VirtualBox installer at least must give a notice that it can break IPTV.
follow-up: 17 comment:16 by , 7 years ago
This issue has caused problems on multiple occasions for us, with a lot of wasted time trying to figure out my multicast doesn't work as it is supposed to be. The solution for me was to just disable all the 'VirtualBox Host-Only Network'-adapters (as also stated earlier in this bug report).
This has nothing to to with IP-television specifically (as suggested above), but all multicast communication seems to be affected. For me I couldn't get any multicast traffic to exit my computer until I disabled the VirtualBox interfaces. I had no problems receiving though.
comment:17 by , 7 years ago
I know I'm repeating myself, but if someone with this issue can paste their netstat -rn
output here it would be a good start.
comment:19 by , 7 years ago
Configuration for interface "VirtualBox Host-Only Network" DHCP enabled: No IP Address: 192.168.56.1 Subnet Prefix: 192.168.56.0/24 (mask 255.255.255.0) InterfaceMetric: 10 Statically Configured DNS Servers: None Register with which suffix: Primary only Statically Configured WINS Servers: None
Here's the output. I read somewhere on Appuals that the issue can also be triggered by bonjour for some reason?
comment:20 by , 7 years ago
Was that host-only interface created with an older version of VirtualBox? Can you delete that interface and then create it anew and check the interface configuration again. It should have larger metric.
comment:21 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
No feedback. Before reopening make sure you have tried the workaround from the comment:20 above and have the requested netsh
output.
by , 6 years ago
by , 6 years ago
follow-up: 24 comment:22 by , 6 years ago
Hi, I added 2 attachments. I have the same problem.
When adding a Host-only adapter I am not able to send a WOL package to my machine in the same network any more.
Removing the adapter solves this issue. Installing virtualbox without adapter does not make any problem. For sending a WOL package I use miniWOL.exe but I suspect (and read about it) that all WOL traffic is not working, also from command line.
Obviously, I would like to have virtualbox with adapter while beeing able to send WOL through my LAN.
I am not an expert and maybe this problem would already be solved by changing Host-only settings.
comment:23 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:24 by , 6 years ago
Replying to bvrulez:
When adding a Host-only adapter I am not able to send a WOL package to my machine in the same network any more.
Which version of VirtualBox are you using?
Was the host-only adapter created by an older version of VirtualBox perhaps? Does it help to remove it and create it anew, what does netsh
say about connection metric of the newly created interface? (please, paste the text, not a picture).
follow-up: 26 comment:25 by , 6 years ago
I am using Version 5.2.22 r126460 (Qt5.6.2). Removing the adapter and adding it as new results in me not beeing able to send WOL, again. I don't know how to find out metric with netsh.
comment:26 by , 6 years ago
Replying to bvrulez:
I don't know how to find out metric with netsh.
"Schnittstellenmetrik" in netsh interface ipv4 show config
(1.PNG).
Strange... The fix for this bug was to try to figure out the metric that wouln't conflict with real interfaces. As a quick workaround you can manually change the metric for now (see comment:4).
follow-up: 28 comment:27 by , 6 years ago
So metric is 281 then. I was not sure what you expected since metric was already included in the netstat picture. Thanks. We leave this open then, right? :)
comment:28 by , 6 years ago
Replying to bvrulez:
So metric is 281 then.
No :), that is route's metric (netstat -rn
output in 2.PNG), not interface metric.
I was not sure what you expected since metric was already included in the netstat picture.
That was the metric for the old, previously created host-only interface. My question was does it change when you create it anew.
Did the workaround from comment:4 help?
comment:29 by , 6 years ago
Thanks for clarification - it is 25 then. This was already a new adapter. I removed and re-installed it. Or would you suggest it is an old adapter and with a new one the metric should be set higher by default from virtualbox? (Metric is a new concept for me.)
comment:30 by , 6 years ago
I just tried the workaround and it worked. I was reluctand first because I did not find the exact network setting in my German Win10. It is just an easy step if you know where to search. So, thanks! I guess this solved the issue. I would be interested in what the metric does, but I guess I will just google it. :) Thanks for the fast replies!
comment:31 by , 6 years ago
I recently discovered this as the source of an IPTV client not working. I'm posting this simply as a "me too" story and an argument that this probably could affect more people than you realize.
I work at NASA and we have a service called DesktopTV that uses a Vitec-based IPTV setup. Our DesktopTV client has ~100 channels with multiple feeds for each NASA center, weather, news, and the ability to live stream coverage of rocket engine tests or "All-Hands" or "Town Hall" style meetings held by admins. A glance at Vitec's website, https://www.vitec.com/solutions/multi-site-video-streaming/ shows this technology having obvious applications in Sports, Entertainment, Church, Corporate, Government and Military environments. I get that multicast isn't required for video streams in general, and IPTV is a drop in the bucket compared to the likes of YouTube, Netflix, and Twitch, but I'm just trying to illustrate that IPTV-based streaming may occur quite commonly behind the firewall of large organizations.
Comment 15 above expressed an attitude that IPTV is an obscure technology with "3 users". I would argue that, while I can take a joke, there are likely closer to millions of multicast IPTV "users" who don't even know they are using it. It may even be possible that there are more people benefiting from multicast IPTV solutions than there are virtualbox users. Certainly the average person watching a screen at an airport or hospital or a church service being broadcast to a satellite location or a briefing from Secretary/Administrator of a government agency may not also be the administrator of that system, may not also use Virtual Box, and may not also have an Oracle/virtualbox account in order to post their feedback here. I get that this is an obscure bug, but I think it is obscure because of the small overlap in VirtualBox and IPTV users, not the obscurity of multicast IPTV as a technology.
comment:32 by , 5 years ago
Had the same problem: PC with VirtualBox latest 5.x (Jan 2020) not sending wake-on-lan magic packet over LAN while "VirtualBox Host-Only Network" exists on it.
This workaround solved it and allowed keeping the VB adapter: https://www.virtualbox.org/ticket/8698#comment:4
Thank you.
comment:34 by , 4 years ago
I have the same problem (in my case, it's the multicasting that Minecraft uses to find LAN servers that doesn't work).
The output of netsh interface ipv4 show config tells me that VirtualBox Host-Only Network has InterfaceMetric 25, which is the same as what my hardware interface has. I suspect this is the problem.
I also have two virtual VMware Network Adapters (installed by VMware Workstation Player), but they both have InterfaceMetric 35.
I'm guessing that this is because VirtualBox Host-Only Network acts a 1 Gbps interface, but the VMware Network Adapters act as 100 Mbps interfaces?
I can fix it by manually setting the metric of the Virtualbox Host-Only Network to a higher value, but it would of course be nice if this wasn't needed. Here's a one-liner to do it in an elevated command prompt (where XX = your desired metric):
netsh interface ipv4 set interface "VirtualBox Host-Only Network" metric=XX
Making the VirtualBox Host-Only Network act as a 100 Mbps interface would probably work, but that just feels like a dirty hack (especially since it likely wouldn't work if the hardware interface would also be 100 Mbps).
Oh, forgot to mention that I'm on Windows 10 x64 1909 with VirtualBox 6.1.10 r138449.
This is probably related to Issue #9532. That bug is closed as "fixed in VBox 4.1.4". However, I still have this problem on Windows 2008 R2 with VirtualBox 4.1.18).
Strangely, when I reenable the VirtualBox Host-Only adapter, it's still possible to receive multicast streams...