VMware Communities
beseezy
Contributor
Contributor
‎02-03-2023 12:14 AM

Wireless bridge mode not working on Linux VMs when running VMware Workstation 17.0.1 on Windows 11

Wireless bridge mode not working with Linux VMs

Host is running Windows 11 22H2 x64 build 22621.1194
Wireless adapter is Intel® Wi-Fi 6E AX210 160MHz running driver 22.190.0.4

I've selected "restore defaults" in virtual network editor, unselected unnecessary adapters in "automatic bridging", specifically selected the wireless adapter and nothing works.

Interestingly enough, uninstalling VMWare Workstation 17.0.1 and reverting back to VMWare Workstation 17.0.0 fixes the issue. I've tested this multiple times. I checked the MD5 and SHA1 hash of the VMWare Workstation 17.0.1 installer file and it matches what is shown in the VMWare download portal.

Reply
21 Replies
Arno_00
Enthusiast
Enthusiast
‎02-06-2023 07:19 PM

Same here, and I found this thread on reddit, citing the same issue: https://www.reddit.com/r/vmware/comments/10sn47w/network_no_longer_working_in_workstation_pro_1701/

Clearly there is something broken in 17.0.1. Reverting to 17.0.0 fixes the problem. Or switching to using NAT works too, if you don't mind using NAT that is. 

I really hope they fix this ASAP and more importantly how could they let this slip by? Don't they test their software, this seems like a pretty basic use case... Very disappointed in VMWare...

Reply
0 Kudos
sebama
Contributor
Contributor
‎02-07-2023 03:40 AM

Same problem here with linux guest Kali 2022.3 and host:

Windows 11 22H2 x64 build 22621.1194
Wireless adapter Intel(R) Wi-Fi 6E AX211 160MHz running driver 22.170.0.3

The problem is only with the dhcp configuration, i set manually the IP and network worked, I've upgraded dhcp-client, open-vm-tools packages but didn't solved.
Rolling back to 17.0.0 solved the dhcp problem, obviously.

Reply
Arno_00
Enthusiast
Enthusiast
‎04-29-2023 12:23 AM

Just FYI, the issue is still not resolved in 17.0.2 -- I am so disappointed in VMWare. Networking is a key part of their product, they break it without noticing in 17.0.1, and they don't even bother to fix it in 17.0.2... -1000 points!

Reply
odhiambo
Contributor
Contributor
‎04-30-2023 02:17 AM

I was hoping that 17.0.2 would fix this issue, but no. It did not.

Reply
0 Kudos
FaryadK
Contributor
Contributor
‎04-30-2023 06:45 AM

Same problem. Killed 2 days of my valuable time and I am still looking for a solution. Downgrade is also not possible. Extremely disappointing. I am switching to HyperV. 

Reply
0 Kudos
Arno_00
Enthusiast
Enthusiast
‎04-30-2023 05:53 PM

Just FYI, if you switch to NAT instead of bridged, then it will work fine. It is just the bridged network that is broken.

Reply
beseezy
Contributor
Contributor
‎04-30-2023 09:09 PM

If you use Workstation 17.0.0 it should work fine.

Tags (1)
Reply
RDPetruska
Leadership
Leadership
‎05-01-2023 05:02 AM

@FaryadK wrote:

Same problem. Killed 2 days of my valuable time and I am still looking for a solution. Downgrade is also not possible. Extremely disappointing. I am switching to HyperV. 

Why is downgrade not possible?

Reply
picapzz
Contributor
Contributor
‎05-01-2023 07:03 AM

Just registered here to add my feedback. I also have the same issue with the latest Workstation version 17.0.2. I uninstalled and reinstalled the version 17.0.0.0 which fixed my problem. I am using an Intel® Wi-Fi 6E AX211 160MHz set in Bridge mode on Windows 11.

Reply
0 Kudos
Br_Silva
Enthusiast
Enthusiast
‎05-04-2023 06:58 AM

Good morning everybody!

Using wireshark I found the reason for the problem.

In version 17.0.1 update the network packet requesting IP is being sent in unicast, in version 17.0.0 the network packet requesting IP goes in broadcast, this is the problem of not receiving IP and not being able to navigate, I am using version 17.0.0 until they fix this flaw.

Reply
ymgh96
Contributor
Contributor
‎05-14-2023 01:33 AM

Unfortunately it's right! I had same problem on windows 11 with vmware workstation 17.0.1 and 17.0.2. Bridge network mode doesn't connect just in kali (probability debian-based system) and I didn't have any problem in the windows and ubuntu VMs (!). With reverting to version 17.0.0 from this link problem is solved.

Reply
JScutt
Contributor
Contributor
‎06-10-2023 11:53 PM

Can confirm this is also an issue with the Realtek RTL8852AE WiFi 6 802.11ax WiFi card, Windows 10 host, Debian linux guest

Downgrading to 17.0.0 fixed the issue for me

Reply
isticusi
Contributor
Contributor
‎06-24-2023 04:18 AM

May I ask -- do you just install the version above or do you need first to deinstall 7.0.2. 
Thanks a lot for your help. In my opinion, this is a critical feature, that vmware should
fix soon. Hope that they are  working on an update. Kind regards, Stephan

Reply
0 Kudos
gbohn
Enthusiast
Enthusiast
‎06-27-2023 12:10 PM

This problem seems to have been reported for some time now and I've been holding off switching to version 17 until this is fixed.

But at this point it seems unclear when (or if) this will ever get fixed.

Has VMWare acknowledged this as an issue anywhere?

Reply
0 Kudos
Arno_00
Enthusiast
Enthusiast
‎06-27-2023 03:09 PM

Since when does VMWare staff even look look at the forums :rolling_on_the_floor_laughing:.

Seriously I agree with you this is ridiculous, a bug like this is so basic, you would think it would not even have gone through a QA cycle in the first place, but it went through two releases already and there doesn't seem to be any acknowledgement on VMWare side... laughable, it says a lot about how broken their QA process is IMHO.

Reply
0 Kudos
zeustm
Contributor
Contributor
‎06-29-2023 01:28 AM

This is my experience:

Using cisco WLAN Infrastructure and specific config to allow this bridging (enabled passive client), and using VMWare Player 17.0.2 I can see DHCP Offers coming to Host on the wireless adapter with the DHCP Id from the Guest (and client MAC from the guest as well), but I cannnot see the Offers on the Guest.

After downgrading to VMWare Player 17.0.0 build-20800274 I cannot even see any DHCP Offer coming to the Host, so definitely not working for me.

Can you validate your working 17.0.0 build please?

Any recommendation would be highly appreciated.

Reply
0 Kudos
JScutt
Contributor
Contributor
‎06-29-2023 02:00 AM

I'm on build 20800274

Do you have another guest OS to test with?

Reply
0 Kudos
shixudong
Contributor
Contributor
‎08-13-2023 07:14 PM

There is a better solution than reverting to version 17.0.0. By using the Win10 Host bridge, the wireless bridge becomes a "wired" bridge for Vmware, and the "Bootp flag" conversion from unicast to broadcast is completed by the host network bridge, which also perfectly circumvents the bug of 17.0.1. Extra tip: The Host network bridge must use Hyper-v to bind the wireless network card and cannot be generated in a conventional way (if you do not want to use Hyper-v in the future, you can uninstall Hyper-v after generating the bridge). The conventionally generated bridge driver has a defect in handling the guest's DHCP request (automatically converting the chaddr field to the host wireless network adapter MAC, and the guest is assigned the exact same IP address as the host wireless network adapter), resulting in an IP conflict between the guest and host.

See: https://blog.csdn.net/sxd2001/article/details/128009805

Reply
0 Kudos