However, it becomes more likely to be point of inevitability if there's a machine on the network that's trying to contact another that's not responding, because it will keep sending out broadcast packets. In my case, it's my printer that's down for some reason.
I'll submit proposed changes to the kernel driver to fix the problem, and also to VirtualBox to sidestep it.
In the mean time, people experiencing diffulties could try the other network interace types. If all else fails, or if it just seems simpler, I've created a hack to get around it - note LIMITATIONS - which should work unchanged on systemd based systems. Some modification may be required otherwise.
LIMITATIONS: This hack will only work if the guest has manually assigned IP address and default route. If it's configured to use DHCP to get either, or both, of these, then the hack will not work.
Put the following into a file called setup.sh
Code: Select all
#----- Start of setup.h
cat >/etc/vbxhack.sh <<'END'
while true; do
# Wait until a default route appears.
while true; do
ip -o route show | grep default >/tmp/device
if [ -s /tmp/device ]; then break; fi
usleep 100000
done
# Got a default route, so get the gatewake and interface
def=`sed -e "s/^default via \\([^ ]*\\).*/\\1/" /tmp/device`
dev=`sed "-e s/^default via [^ ]* dev \\([^ ]*\\).*/\\1/" /tmp/device`
# If we can ping the gateway, then we're done.
if ping -c 2 ${def} >/dev/null 2>/dev/null; then break; fi
# Save routes, take the interface down and up, and restore routes.
ip route save >/tmp/routesave
ip link set ${dev} down
ip link set ${dev} up
# Restore the routes will always give an error, which does not matter.
ip route restore </tmp/routesave 2>/dev/null
done
END
if [ ! -s /etc/rc.d/rc.local ]; then
echo "#!/bin/bash" >/etc/rc.d/rc.local
fi
chmod +x /etc/rc.d/rc.local
echo "sh /etc/vbxhack.sh &" >>/etc/rc.d/rc.local
#--- End of setup.h
Code: Select all
sudo sh setup.sh