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?
"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?
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.
Yes, I still have the same problem after the fresh host OS and VMware Workstation installation.
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.
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.
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.
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?
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.
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.
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):
(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.)
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
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.
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:
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.
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!