VMware Communities
mvanwieringen
Contributor
Contributor
Jump to solution

VMware Workstation 12 Bridging problem with vmnet0

Hi Team,

I have an issue with vmnet0, whereby vmnet0 is not showing up in "ifconfig -a". This is my environment:

Host: Ubuntu 14.04

VMware Workstation version 11.1.2

This started happening about 2 weeks ago: when starting a VM that uses the bridged interface, it comes up with the error message "The network bridge on device /dev/vmnet0 is temporarily down because the bridged Ethernet interface is down."

When looking at "vmware-netcfg", all settings are as they have always been. Specifically with respect to the bridged connection: it is bridged to "Automatic" and the "Automatic Settings..." have a tick for each interface on my system. The line item for vmnet0 shows:

Name: vmnet0

Type: bridged

External Connection: auto-bridging

Host Connection: ---

DHCP ---

Subnet IP Address: ---

I have also tried to force the bridging onto a specific interface, by changing the automatic settings to a specific interface. This does not resolve the issue.

I decided to upgrade VMware Workstation to version 12.5.6, hoping the issue would get resolved that way. This did not make a difference.

I then decided to wipe out my hard drive and install Ubuntu 16.04.2. After the installation, I installed VMware Workstation 12.5.6. Doing all this, also did not resolve the issue.

I found that the vmnet-bridge process is running:

$ ps aux  | grep vmnet-bridge

root     21321  0.0  0.0   7004   196 ?        Ss   13:25   0:00 /usr/bin/vmnet-bridge -s 12 -d /var/run/vmnet-bridge-0.pid -n 0

However, while researching this issue, I found that sometimes you have to manually run:

/usr/bin/vmnet-netifup -d /var/run/vmnet-netifup-vmnet0.pid /dev/vmnet0 vmnet0

After running this, I can see the vmnet0 interface listed in the output of "ifconfig -a", however I cannot seem to use it.

BTW, I got the above from this link: networking - Bridged virtual interface is not available or visible to ifconfig - Server Fault

Some other info: /dev/vmnet0 exists.

Not sure what to do anymore at this stage. Any help is greatly appreciated.

Marc.

Reply
0 Kudos
1 Solution

Accepted Solutions
dariusd
VMware Employee
VMware Employee
Jump to solution

Cool, thanks for that.  Your Android phone uses the Microsoft-proprietary RNDIS protocol for implementing network-over-USB.  The way that our network bridge checks for device compatibility is a bit awkward, and doesn't presently allow RNDIS devices to be attached to a network bridge.

Here's a patch which might fix it.  If you're game to do a bit of patching and willing to try out my largely-untested patch, you'll need to:

  • Quit Workstation.
  • Back up /usr/lib/vmware/modules/source/vmnet.tar to a safe place.
  • Unpack that tarfile.
  • Download the patch attached to this post (VMware-Workstation-12.5.7-rndis-bridging.patch).
  • Apply the patch to the contents of the tarfile.
  • Repack the tarfile
  • Put the modified tarfile back in place at /usr/lib/vmware/modules/source/vmnet.tar .
  • Rebuild the modules.
  • Launch Workstation.

It'll look something like this:

   mkdir ~/vmnet-fix

   cd ~/vmnet-fix

   cp /usr/lib/vmware/modules/source/vmnet.tar ./vmnet-12.5.7.tar

   tar xf vmnet-12.5.7.tar

   patch -p0 < ~/Downloads/VMware-Workstation-12.5.7-rndis-bridging.patch

   tar cf vmnet.tar vmnet-only/

   sudo cp vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar

   sudo vmware-modconfig --console --install-all

Hopefully you will then be able to launch Workstation and power on a VM that is tethered to your Android phone.

Cheers,

--

Darius

View solution in original post

Reply
0 Kudos
20 Replies
mvanwieringen
Contributor
Contributor
Jump to solution

Hi Team,

Just a further update on this. I did another re-installation of the host operating system, this time running Ubuntu-gnome 16.04. I did another (obviously fresh) installation of VMware Workstation 12.5.6, accepting all the defaults. Before even running VMware Workstation, I did another "ifconfig -a". The result is that vmnet1 and vmnet8 are there, but there is no trace of vmnet0.

Am I correct to assume that vmnet0 should be present at this stage?

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

"ifconfig -a" will only show interfaces for which there's a "host connection", which by default is only vmnet1 (host-only) and vmnet8 (nat).  It isn't logical for a bridged vmnet to appear in "ifconfig", because the interface to which the connection is bridged should already show up in the interface list.  For the same reason, vmnet-netifup (which implements that "host connection") should not be run against vmnet0.

Let's go back to troubleshooting the original problem...  Are you still seeing the error message ""The network bridge on device /dev/vmnet0 is temporarily down because the bridged Ethernet interface is down." after reinstalling the host OS and upgrading to Workstation 12.5.6?

Cheers,

--

Darius

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Why do you expect to see vmnet0 in ifconfig ?
If you used vmnet0 for a bridged vmnet it should not appear in ifconfig at all.
ANd changing vmnet0 to a "hostonly", "nat" or "guestonly" is a bad idea.


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Darius,

Yes, I still have the same problem after the fresh host OS and VMware Workstation installation.

Marc.

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Continuum,

I wasn't sure if vmnet0 should appear in the output of "ifconfig -a", hence my question. I am not changing vmnet0 at all. I have left it as default.

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Are you by any chance using a custom Linux kernel on your host?  There's a possibly-related issue which was raised in another discussion here a few weeks ago, but we've not seen that happen with any of the standard/default Ubuntu 14.04 or 16.04 kernels.

Otherwise, was there any unusual configuration which you applied on the host after installing Ubuntu 16.04, any saved config files that you reloaded onto the host to reuse, or anything like that?

There should be a /usr/bin/vmnet-bridge process running on the host, with the "-n 0" option in its command line for vmnet0.

And one final interesting thought... What does your host routing table look like?  I could see this failure possibly occurring if your host doesn't have a valid default route and has multiple physical Ethernet ports, at least one of which is disconnected.  I have no idea if that describes your host though.  Smiley Wink

Cheers,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

After doing further research, I am starting to think the problem is related to something completely different. I spend a lot of time away from wired networks and am using my phone to tether. I recently changed from iPhone to Android. I am starting to think that the combination of the Android phone and the bridging may be the cause of the issue.

Tomorrow I should have an opportunity to plug into a wired network. If the bridging works then, I would say the problem is directly related to Android.

I will let you know tomorrow.

Marc.

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

I just plugged into a (wired) corporate network (phone is disconnected) that I know works with bridging. I configured the VM to use bridging, then started it up. Everything works as normal.

The question is then: why does bridging not work when tethered to the Android phone?

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Workstation 12.5.7 has been released, and contains a fix for an issue which may cause unreliable network bridging when run on Linux host kernel version 3.11 and newer.  It may possibly help with bridging to your Android phone... I can't tell for sure and I don't have an Android phone with which to test.  It'd be great if you have the chance to try it out and let us know if your problem is resolved.

VMware Workstation 12 Pro Version 12.5.7 Release Notes

Download VMware Workstation Pro

VMware Workstation 12 Player Version 12.5.7 Release Notes

Download VMware Workstation Player

Cheers,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

I just installed 12.5.7, but it makes no difference. After enabling the USB tethering on the phone, I did see the following in the dmesg output:

[15912.120279] usb 2-1: USB disconnect, device number 9

[15912.120704] cdc_acm 2-1:1.1: failed to set dtr/rts

[15912.466919] usb 2-1: new high-speed USB device number 10 using xhci_hcd

[15912.607949] usb 2-1: New USB device found, idVendor=04e8, idProduct=6864

[15912.607952] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[15912.607954] usb 2-1: Product: SAMSUNG_Android

[15912.607955] usb 2-1: Manufacturer: SAMSUNG

[15912.607956] usb 2-1: SerialNumber: d31e7ed99d31e7ed

[15912.609580] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 22:77:81:d3:13:7e

[15912.623633] rndis_host 2-1:1.0 enp0s20u1: renamed from usb0

[15912.660667] IPv6: ADDRCONF(NETDEV_UP): enp0s20u1: link is not ready

[15912.661616] /dev/vmnet: open called by PID 7405 (vmnet-bridge)

[15912.661624] /dev/vmnet: hub 0 does not exist, allocating memory.

[15912.661646] /dev/vmnet: port on hub 0 successfully opened

[15912.661652] bridge-enp0s20u1: can't bridge with enp0s20u1, bad header length 58

[15912.662192] bridge-enp0s20u1: attached

[15912.662231] bridge-enp0s20u1: detached

[15912.662539] /dev/vmnet: open called by PID 7405 (vmnet-bridge)

[15912.662544] /dev/vmnet: hub 0 does not exist, allocating memory.

[15912.662565] /dev/vmnet: port on hub 0 successfully opened

[15912.662571] bridge-enp0s20u1: can't bridge with enp0s20u1, bad header length 58

[15912.662752] bridge-enp0s20u1: enabling the bridge on dev up

[15912.662753] bridge-enp0s20u1: can't bridge with enp0s20u1, bad header length 58

[15912.662754] bridge-enp0s20u1: interface enp0s20u1 is not a valid Ethernet interface

[15912.662755] bridge-enp0s20u1: attached

[15912.861560] userif-3: sent link down event.

[15912.861564] userif-3: sent link up event.

[15918.156494] userif-3: sent link down event.

[15918.156497] userif-3: sent link up event.

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Interesting.  It doesn't look like a standard Ethernet device, but I suspect I've figured out what's happened.  To verify, could you please provide the output of the following command (with your Android phone attached to the host):

   /sbin/ifconfig enp0s20u1

(I have no idea if the interface will be named differently when the phone reconnects... If so, grab the name from dmesg and adjust the command accordingly.)

Thanks,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Darius,

Here is the output.

$ /sbin/ifconfig enp0s20u1

enp0s20u1 Link encap:Ethernet  HWaddr 02:62:f0:71:61:e4 

          inet addr:192.168.42.206  Bcast:192.168.42.255  Mask:255.255.255.0

          inet6 addr: fe80::3d5f:898f:25d2:21a3/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:2893 errors:1 dropped:0 overruns:0 frame:1

          TX packets:2575 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1569230 (1.5 MB)  TX bytes:1119255 (1.1 MB)

The device seems to be quite stable at enp0s20u1, however I do believe that I once saw it at enp0s20u6. I tried to recreate that by disabling the USB tethering and re-enabling it, however when the connection came back it was again at enp0s20u1.

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Cool, thanks for that.  Your Android phone uses the Microsoft-proprietary RNDIS protocol for implementing network-over-USB.  The way that our network bridge checks for device compatibility is a bit awkward, and doesn't presently allow RNDIS devices to be attached to a network bridge.

Here's a patch which might fix it.  If you're game to do a bit of patching and willing to try out my largely-untested patch, you'll need to:

  • Quit Workstation.
  • Back up /usr/lib/vmware/modules/source/vmnet.tar to a safe place.
  • Unpack that tarfile.
  • Download the patch attached to this post (VMware-Workstation-12.5.7-rndis-bridging.patch).
  • Apply the patch to the contents of the tarfile.
  • Repack the tarfile
  • Put the modified tarfile back in place at /usr/lib/vmware/modules/source/vmnet.tar .
  • Rebuild the modules.
  • Launch Workstation.

It'll look something like this:

   mkdir ~/vmnet-fix

   cd ~/vmnet-fix

   cp /usr/lib/vmware/modules/source/vmnet.tar ./vmnet-12.5.7.tar

   tar xf vmnet-12.5.7.tar

   patch -p0 < ~/Downloads/VMware-Workstation-12.5.7-rndis-bridging.patch

   tar cf vmnet.tar vmnet-only/

   sudo cp vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar

   sudo vmware-modconfig --console --install-all

Hopefully you will then be able to launch Workstation and power on a VM that is tethered to your Android phone.

Cheers,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Darius,

I just applied your patch and it is looking good. I haven't been able to do extensive testing, but I don't get the error message when starting the VM. Also, I have internet connectivity inside the VM! I will be doing some further testing over the next couple of days and get back to you with the results.

Thank you for your efforts!

Marc.

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Darius,

Here are some further findings. When I unplug the phone (go for lunch) and then plug it back in, I enable the USB tethering in the host OS. Once that is established, I go to my VM, but it does not have network connectivity. I then have to disconnect the bridged NIC and connect it again. When the network comes up again, my Windows guest is reporting it found a new network and asks me if it is a public or a private network. It seems to ask me this with every connection.

Please note that both before and after the unplug/replug action the network device is called "enp0s20u1".

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Hmmm... that's odd.

I'm not familiar enough with the way that Windows identifies networks to say with any degree of confidence, but my guess is that the MAC and/or IP address of your phone is changing across a disconnect/reconnect.

Does your phone have a privacy/security option to generate randomized MAC addresses or similar?  If so, you might want to check if you can disable that option in case it also affects the tethering bridge.  I've heard of that feature being used for a phone's wireless client connection, but not for tethering.

You may also be able to see if MAC randomization is somehow causing a problem by running "arp -an | grep enp0s20u" on the host to see what the MAC of your tethered phone appears as.  Maybe also check the line containing "RNDIS device" in dmesg to see if that shows any changes across a disconnect/reconnect.

In order to provide Internet access through that tether, your phone will be providing a DHCP service, and there's plenty of information there which Windows could use to try to uniquely identify the network.  Your Windows guest will display all that information (assigned address, DHCP server, etc.) in the network connection's TCP/IP properties.  Again, check to see if that information changes across a disconnect/reconnect (after restoring connectivity in the Windows guest).

As far as allowing your Windows guest to "know" that the network has been disconnected and reconnected... The virtual network bridge usually does not perform "link state propagation" -- it behaves like a physical network switch, in that if the switch loses connectivity to the outside world (in this case, the tethered device), that does not cause a loss of link on the other switch ports (e.g. the one connecting to the virtual machine), so the VM doesn't know that the link has gone and returned again.  The same problem can occur if you move a physical machine connected to a physical switch between networks without disconnecting the PC from the switch.  For a VM, you can change that behavior with the custom VM config option:

   ethernet0.linkStatePropagation.enable = "TRUE"

Add that to the VM's config file (the .vmx file), and then your VM should start seeing its network link go down/up in accordance with the availability of the tether.

Cheers,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

I had another day of plugging in and unplugging my phone while tethering and recorded some of my findings. I just read my last message in this thread and find that today's experiences are different from what I reported earlier. The difference is that unplugging and replugging the phone no longer results in the Windows VM recognizing a new network. It has "recognized" a new network twice today. The first time was when I first started the VM. The second time was when I restarted the Windows VM.

I have been running the following command after plugging the phone in and enabling USB tethering: $ arp -an | grep enp0s20u ; dmesg | grep 'RNDIS device'

After enabling tethering first thing in the morning. The Windows VM does notify me of a new network:

? (192.168.42.129) at 2e:78:04:44:af:35 [ether] on enp0s20u1

[   25.737766] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 3a:8c:e9:94:cd:f4

After unplugging the phone, plugging it back in and enabling tethering. The Windows VM does not notify me of a new network:

? (192.168.42.129) at 82:ee:08:0e:22:46 [ether] on enp0s20u1

[   25.737766] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 3a:8c:e9:94:cd:f4

[ 4099.507169] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[ 5140.567149] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:63:44:f5:1a:fa

After unplugging the phone, plugging it back in and enabling tethering. The Windows VM does not notify me of a new network:

? (192.168.42.129) at 1a:2c:30:8d:96:4c [ether] on enp0s20u1

[   25.737766] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 3a:8c:e9:94:cd:f4

[ 4099.507169] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[ 5140.567149] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:63:44:f5:1a:fa

[10582.768782] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[12582.830572] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:86:3c:d8:b0:b0

After unplugging the phone, plugging it back in and enabling tethering. The Windows VM does not notify me of a new network:

? (192.168.42.129) at 8e:e5:4c:0f:9e:e2 [ether] on enp0s20u1

[   25.737766] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 3a:8c:e9:94:cd:f4

[ 4099.507169] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[ 5140.567149] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:63:44:f5:1a:fa

[10582.768782] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[12582.830572] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:86:3c:d8:b0:b0

[15806.218274] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[16988.424840] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 0e:24:2e:1d:f1:b8

After logging off from my Linux host and thus restarting the Windows VM. The Windows VM now does notify me of a new network.

? (192.168.42.129) at 8e:e5:4c:0f:9e:e2 [ether] on enp0s20u1

[   25.737766] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 3a:8c:e9:94:cd:f4

[ 4099.507169] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[ 5140.567149] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:63:44:f5:1a:fa

[10582.768782] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[12582.830572] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, c2:86:3c:d8:b0:b0

[15806.218274] rndis_host 2-1:1.0 enp0s20u1: unregister 'rndis_host' usb-0000:00:14.0-1, RNDIS device

[16988.424840] rndis_host 2-1:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-1, RNDIS device, 0e:24:2e:1d:f1:b8

I hope this helps.

Marc.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Yeah, your phone is definitely generating new random MAC addresses each time it reconnects, and that will cause problems as described above.  I can think of two options:

1. Reconfigure your phone to avoid randomizing MAC addresses.  This will reduce your privacy since a phone with Wi-Fi enabled and using a constant hardware MAC address will be more readily trackable than with MAC address randomization enabled.  I don't have a phone with which to test, but you might try looking through your Security, Privacy or Network settings for an option controlling MAC randomization and/or Wi-Fi tracking privacy protection.

2. Reconfigure Windows to stop prompting for each new network.  I don't have much of a clue about how to do this either, I'm afraid.  There might be a setting in the UI in the Network control panel, or there might be a group policy or a registry setting you can set to override that prompt.

In either case, the linkStatePropagation option I mentioned earlier might be useful to inform Windows when the network configuration has changed.

Cheers,

--

Darius

Reply
0 Kudos
mvanwieringen
Contributor
Contributor
Jump to solution

Darius,

I guess the problem resolved itself. There is probably a limited number of MAC addresses the phone uses and I think my Windows VM has now learned them all 🙂

I also had a look at this:

https://superuser.com/questions/729305/prevent-windows-from-creating-new-network-names-when-tetherin...

which seems to provide a solution to instruct Windows not to detect the new network for the tethered phone. I haven't tried this though.

For now, everything is working well.

Thanks again for your help in this matter.

Marc.

Reply
0 Kudos