Bridged networking fails to reconnect when cable unplugged and plugged back in (#15308)

[arQon]

i have no idea if this still works or not: bridged was so buggy for so long that i just gave up on it. but, give it a try and see. gl.

Code: Select all

rem  see https://www.virtualbox.org/ticket/14374 as well as my thread on the forums

rem  since 5.xx, virtualbox has had a bug where guests using bridged networking
rem  permanently lose connectivity when the host sleeps.
rem  this hopefully restores it by reinitialising the guest NIC's "physical" connection.

VBoxManage controlvm <vmname> setlinkstate1 off
timeout /T 1
VBoxManage controlvm <vmname> setlinkstate1 on

[bmd2020]

The solution given in comment#14 of the ticket (link in previous post) worked for me. I'm VERY relieved as I was having to do the NAT<>Bridged change to resolve each time too!

[igx31]

Hello everyone,

We have the same issue here with VirtualBox 6.1.28.
We send to our users a virtual machine that contains several tools to monitor, manage and configure the appliances we provide them with.
Depending on the host's Ethernet card (or, more accurately, on its driver), the guest fails to receive ARP answers (WhoHas are sent though the host, IsAt are received by the host, but not forwarded to the guest).

Oddly, the solution given above didn't work for us. Instead, we had to modify the status of nictrace1, which lead to the following batch file :

Code: Select all

@echo off
VBoxManage controlvm <vmname> nictrace1 on
VBoxManage controlvm <vmname> nictrace1 off

(The "timeout" command was not necessary for us)

Our installer makes a shortcut on the host's desktop that runs this file, and names it "Appliance change", and that's it

I wondered if there was a way to detect, on a given host, whether this problem is going to happen or not. Maybe a missing entry point / feature of the Ethernet driver ?
... so that we may detect a functioning driver and not install this shortcut on the user's desktop.

Many thanks to anyone who would have a clue on this question

[loopy12345]

I had this same problem on VB6 and now VB7. I finally figured out that if you change the Guest's

Settings->Network->Adapter1->Advanced->Adapter Type to "Intel PRO/1000 T Server"

the problem goes away!

The default for the Bridged Adapter of "Intel PRO/1000 MT Desktop" probably has a bug.