hostonly adapter netmask problem

[it vir]

I am working with Win7 and just upgraded VB to 5.0 and even tried the 5.0.4, found problems on Vagrant 1.7.4 and latest docker-machine 0.4.0 often create new host-only adapter whenever starting up after prior stop/halt. All just did well with VB4.3

It is found that the netmask returned from CLI 'VBoxManage list hostonlyifs' always changed to 255.255.0.0 no matter when created differently like 255.255.255.0. So the application believe there is no matching interface and recreate new network interface again and again.
When check via ipconfig or GUI, the REAL netmask displayed from Windows is 255.255.255.0. Setup of netmask 255.255.255.0 should be successful to change the REAL value with either via the VB GUI preference/network/hostonly or the CLI 'vboxmanage hostonlyif ipconfig --ip x.x.x.x --netmask 255.255.255.0'.
Just the value check by Vboxmanage list hostonlyifs and thus returned in the GUI perference/network will be incorrect.

Are there others with same problem and is there any quick fix on that?!

[noteirak]

Vagrant and docker-machine are not supported here. If you can reproduce a scenario of that issue without having the tools running (or better, uninstalled), then we can investigate.

[it vir]

The problem itself is reproducible by VB alone, CLI or GUI to create hostonly adapter. Say whatever you assign the netmask at the GUI (perference/network/hostonly), it will be changed as 255.255.0.0

It is not Vagrant nor docker-machine problems. They are just the use cases that discover the VB problem.

[it vir]

Finally solved by disabling the APIPA private address generation of Win7.

The VB bug is that whenever there exist the routes 169.254.0.0/16, VB5 will get the netmask here but not the real one. Temporarily use 'route delete 169.254.0.0' will remove these route and 'vboxmanage list hostonlyifs' can show the true netmask. But then Win7 will generate the routes back quickly.

Since that is the default behaviour of win7 to generate these even after deleted the route. So the workaround before VB bug fix is to disable the generation of private address route via Win register

[noteirak]

There is no reason for these address to be generated unless you configured an interface with DHCP but no DHCP server is answering - sounds like a missconfiguration to me.
And if you configured the host-only interfaces with DHCP, then this is a user error - they should not. On the host, only static IP are to be used on them.

[it vir]

For all as reference.

It is found there is the 'Canon IJ Network Scanner Selector' problem make this strange case that no APIPA is used but will cause the building of private subnet/broadcast routes for all interfaces. However, VB side can also consider improve on the netmask selection to avoid similiar cases since no APIPA should be valid anyway.

Thanks all