virtualbox.org

Every time I upgrade VirtualBox on my Windows 7x64, I have to add the *NdisDeviceType key in the registry for the newly created network interfaces.
Please just create the values in the setup process. Should be easy, I guess.
thx, Hannes

The same issue.

I wonder from the 3.x versions of the VirtualBox, why to not to add this key to VB HostOnly network adapter entry at registry during the driver installation in Windows 7.

Each time I upgrade I should go to the regedit and search VB adapter under HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318} and add to it *NdisDeviceType key to make Win7 networking to function correctly with VirtualBox.

This is really weird, especially because problem is well-known for more than a year.

And what does this key do and why is it needed? You are the only ones complaining about it now.

Here is a web page discussing the feature. It looks like the purpose is to work around an irritating feature of Windows - Vista and later. Presumably this is something that could be fixed in the Windows installer... but NDisDeviceType does not seem to be well documented (a link to a Microsoft page is broken), and for that reason I have my doubts whether VBox should be messing with it.

On another web page it says that setting it to 1 tells Vista+ that this device is a "network endpoint", usually meaning that it's a virtual device and not really an open network connection for the security features to get all hot and bothered about.

the MS link is http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Sasquatch wrote:And what does this key do and why is it needed? You are the only ones complaining about it now.

Every person installing VB on Win7 or Vista meets the problem. But, it is partially working, sufficient for web browsing for example. May be that's why you didn't see a lot of complaints.

But, local network browsing may fail because Windows thinks that PC now connected to two networks and one of them (VB) is not secure, so some firewall rules are enforced.

The details, as Hans Ebernard noted, are listed at
http://msdn.microsoft.com/en-us/library ... 85%29.aspx :

*NdisDeviceType
The type of the device. The default value is zero, which indicates a standard networking device that connects to a network. Set *NdisDeviceType to NDIS_DEVICE_TYPE_ENDPOINT (1) if this device is an endpoint device and is not a true network interface that connects to a network. For example, you must specify NDIS_DEVICE_TYPE_ENDPOINT for devices such as smart phones that use a networking infrastructure to communicate to the local computer system but do not provide connectivity to an external network.

To find more information about a particular keyword, search for the keyword in the WDK documentation.

Note Windows Vista automatically identifies and monitors the networks to which a computer connects. If the NDIS_DEVICE_TYPE_ENDPOINT flag is set, the device is an endpoint device and is not a connection to a true external network. Consequently, Windows ignores the endpoint device when Windows identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder.

As I see, that's show enough reasons to set this flag on the adapter and do so during install.

For me it looks like it would disable a valid scenario where you would use the host only network for a complete virtual testing environment with its own network.

On the contrary, it looks to me like the effect is to allow free use of the virtual network port.

I apologise, if some details are not correct, I studied the issue more than 9 month ago, then, I used to google that registry key. So some details could be forgoten.

When *NdisDeviceType key is not existing, or set to "0", VMs have difficulties communicating with network both in Bridging and NAT mode. This is related with behavior Win7 and Vista uses with it's firewall when it have Unidentified Network connected to some intereface. Also I had difficulties with the host system, for example - CIFS browsing of the host resources from other PCs won't work due to some firewall policies or computer browsing policies engaged.

When *NdisDeviceType is set to "1", all is working like a charm.

Also, I think, that setting it to "1" doesn't influence the VirtualBox "Internal Network" VM networking mode.

kengaru wrote:VMs have difficulties communicating with network both in Bridging and NAT mode

I can't see how either feature could be affected by this registry option. Both use the same host network port as any other app uses, albeit with redirection at one level or another. The Host-Only adapter is a different story and I could see it having an affect there.

Hi,
I had the same problem with the host-only network adapter of VirtualBox. It was annoying, because it inhibited any network activity between the host and the guest system - particularly file sharing (CIFS) - due to Windows' network/firewall policy for unidentified networks.

- to be continued due to forum policy restrictions -

- continuation -

The link to Microsoft's knowledge base article given by Hans and kengura is the solution and there is an easy-to-understand how to at www . brokenwire . net/bw/Various/120/fix-virtualbox-causes-unidentified-network-on-vista-and-windows-7 (simply delete the redundant blanks).

However, you should be careful and use this flag only for such internal virtual network devices as one can concluded from the Microsoft article.

Best regards,
fuggi

I usually have some suspicious software in my VMs and I wonder if changing *NdisDeviceType to 1 increases the risk of viruses from the VM to my host OS. What do you think?

No. The problem is that a Win7 host sees the simulated host only ethernet NIC as an unknown network connection. Setting this flag makes it a known network connection - on a par with the other (real) NIC in the host PC. The host firewall is still in place.

mpack wrote:No. The problem is that a Win7 host sees the simulated host only ethernet NIC as an unknown network connection. Setting this flag makes it a known network connection - on a par with the other (real) NIC in the host PC. The host firewall is still in place.

Thank you! This is such a relief.