virtualbox.org

Hi guys.

Up until now I had wireless card in windows 7 host which had all protocols unchecked except Virtualbox bridge. Like said that worked until now. In virtualbox 5 situation is changed, interfaces that are confgured like that are not recognized at all and I cannot select them. Is this a bug, or?

Also,
once VM is started I can disable IP protocols in host and VM machine will continue to work, unfortunately, if I try to restart VM, virtualbox will not start the VM because it will loose the "visibility" of that NIC again (no IP protocols checked).

I used this config to completely disable the IP from the Host side and give it exclusively to the Virtualbox bridge VM's. Host would not be pingable or reachable over that NIC rather only VM guest.

In version 4.3 & earlier, unchecking everything except Virtualbox bindings was the way to set a physical NIC aside for the guest's use only. I believe I've read that with version 5 it is now necessary to also have the IP4 binding checked as well. I think....

If this is the new way than it is a step back and a pretty big one. Before we had a way to dedicate nic completely to virtualbox use, now you cannot do it anymore. They should have left some settings no revert back like it was before. Don't understand how they didn't see it as useful thing to have. This is like default setup for almost all my colleges.

Windows apparently redesigned the network stack for Windows 10, or whatever it's called, so Virtualbox had some hoops to go through in version 5. I also read that there's NDIS5 and NDIS6 networking schemes that can be used (Windows 10 requires NDIS6 I think?) and VB 5 might default to NDIS6? As a complete guess, since your host is Windows7, it would be OK with the old NDIS5 setup, and a re-install of VB 5 with the NDIS5 stack might restore former behavior? How to do it is in the forum somewhere. (I'm culling from remembered posts, might not be remembering right, take good restorable backups before trying)

Or wait for BillG or a guy in green to come along...

I've noticed similar post on the forum that is referring to the ticket 14578. Apparently this issue was not present on the 5.0.2, started from 5.0.4. I'll go back to 5.0.2 if I can.

Everything back then was experimental - expect other issues. I would ask on the bugtracker if the devs intend to leave the need-ip4 workaround in place or will they try to restore the old procedure, too.