VMTN

Also, I reproduced this problem with new downloads of ubuntu ISOs on newly created virtual machines, as well as doing install/reinstall dances with both Fusion and the VMWare tools on an existing image.

I'm having the same problem with Fusion 4.0.1 on a Mid 2010 MacBook Pro. In my Ubuntu 10.10 VM bridged networking has not worked with Wi-Fi since upgrading to Lion. Bridged works with Ethernet, NAT works for both adapters, and bridged worked with Wi-Fi on 10.6. Bridged also continues to work on my Windows XP VM.

Hi all.

I've got a similar problem. I can't do DHCP on the guest with a network card bridged to the MacBook's wireless card.

I have deeper details about the problem. On a MacBook Pro with Mac OSX 10.7, it works neither with Fusion 3.1.3 nor Fusion 4.

DHCP does not works on if guest is bridged to wireless interface. It works if bridged to the Ethernet (wired) interface. All other network traffic looks OK on wireless and wired bridges (i.e. if I setup a static IP to my guest, networking works well).

After investigation it seems that the issue comes from the firmware of the AirPort Extrem wireless card, and that a stupid endiandness problem.

In briged mode The guest machine send correctly its DHCP-Discover packets to the host. Using wireshark and/or tcpdump I can see DHCP Packets on the interface en1 (the wifi interface of my MacBook) The only unusual things is that the source mac address of the Ethernet layer is the mac address of AirPort Extrem wireless card, and *not* the mac address of VM. This is not the right behavior for a bridge! a bridge must not alter packets.

As I said before, packets that are *not* DHCP work well, thus apparently changing the source mac address is not an issue.

The *real* issue is when the packet left the MacBook's wireless interface. The device change one field in the IP packet: It set the Differentiated Services Code Point (DSCP) to 0. This is not a big issue by itself, apparently it's only related to QoS... and my network is not overloaded. This change makes the IP checksum and UDP checksum to be recomputed. Unfortunately, the checksums are written in the *wrong bits order*, it's written in little endian whereas it should be written in big endian (for example 0xa639 instead of 0x39a6) Thus the DHCP server receives a packet with a wrong checksum and it discard it. Packets are discarded even before they can be processed by the DHCP server, that's the reason why nothing appears in the logs of DHCP server.

Here a simple schema to try to explain.

+--------------+                       +----------------+                    +----------------+

|   Linux VM   |       ok but          |    Mac Book    |   Bad checksum     |    DHCP server |

|              |    src mac of en1     |                |  src mac of en1    |                |

|  iface eth0  |  -------------------->| wifi iface en1 | -----------------> |    Pkt dropped |

+--------------+         (1)           +----------------+        (2)         +----------------+

I also attached, two files where I capture the DHCP packets sent by the I captured in (1) and (2). ( in (2) the packet is truncated but the interesting part is at the beginning )

Sometime (very rare) the DSCP is not changed, thus the checksum is not recomputed and the packets goes throw correctly (and the DHCP server reply, like in normal operations)

Last "detail". It works perfectly in wired mode. The bridge is OK - i.e. the outgoing DHCP packet is left untouched.

I hope this report will helps people to understand/fix the bug/find a workaround.

Best regards

Nice find.

I can confirm I'm experiencing this problem in new VM images in Fusion 3.1.3 and 4.0.  This helps explain why the error count increments when watching ifconfig during a dhcp lease.

I can confirm the same problem with OS X 10.7.1 running VMware 3.1.3 or 4.

The only time I've seen the guest receive an IP address via DHCP while bridged to the Airport Wifi card is with a Windows 7 guest.  None of the other guests I've tested (Windows XP and various Linuxes) work.

If it matters, I'm using a Mid-2011 Macbook Air.

After further tests on linux, DHCP works with another DHCP client: `udhcpc' from `busybox'.

The default client on ubuntu (the one I used to do my tests) is `dhclient' from isc-dhcp.

The reason is udhcpc set the DSCP field of th IP header to 0, whereas the dhclient set it to 0x4 ( flag No_DELAY). The error is because the fireware of the wifi card rewrite the packet to set the DSCP field to 0. While using udhcpc the field is already set to 0, thus there is no reason for rewritting the packet, thus there is no error.

As far as I known udhcpc is the client used at the install stage of ubuntu 11.04 (and some other linux distrib)

If you want to use udhcpc on ubuntu, run the following commands

$ apt-get autoremove dhcp3-client

$ apt-get install udhcpc

Thanks for this info! Is udhcpc a drop-in replacement for isc dhcpc?  Ie, it'll just work out of the box with /etc/init.d/networking ?  I want to make sure before I pass this tip along to some coworkers who then break their NATed networking too

I personally had no problem for replacing isc dhclient by udhcpc, but a friend of mine did have problems.

For more information, you may want to take a look at the manpage interfaces(5), section "The dhcp Method".

Ditto. Wasn't working for me. Set VM network settings to NAT, uninstalled VMWare Tools, reinstalled VMWare Tools, rebooted... success!

Early 2011 MBP, VMWare Fusion 3.1.3. I hope this helps someone else out there.

Hey carreec, your posts are super helpful.

I tried replacing dhclient with dhcpcd as you suggested. I'm using Ubuntu 11.10 (upgraded distro from 11.04) and i used `sudo ps aux | grep dhclient` to confirm that dhclient was infact my dhcp client beforehand. I used your instructions to get dhcpcd installed and then added a line to NetworkManager.conf so it looks like this (I consulted the man pages):

 

[main]

plugins=ifupdown,keyfile

dhcp=dhcpcd

[ifupdown]

managed=false

 

Next I made sure that my /etc/network/interfaces file did not contain the interface I was trying to configure using NetworkManager so it looks like this:

 

auto lo

iface lo inet loopback

 

 

Now when trying either the Brdiged or the NAT network connection in VMware Fusion, I cannot get an IP address. After a couple of seconds I get a message saying 'wired connection disconnected'. It just seems like dhcpcd doesnt work. Any ideas? Using the ps command I can see that dhcpcd is running.

I'm using VMware Fusion 4.0.1 on Mac OS X 10.7.2. Oh and btw, I also tried both the dhcpcd and dhcpcd5 packages. Any insight about how you got the Bridged networking working would be great!

Same problem here: OS X 10.7.2 + Airport Extreme + VMware Fusion 4.0.2 + bridged network = no DHCP

—Andreas

I have just purchased a new MBP (10.7.2)  and re-installed windows XP into Fusion4

Same problem it appears to have an IP address from my TimeCapsule via ethernet, but will not connect to Internet in bridged mode.

IP=10.0.1.9 TC=10.0.1.0 netweok seems to be present.

MBP on 10.0.1.5 works fine

I played and played then it would... now it won't

I have manually added DNS servers but still no good.

Anyone else and ideas how to configure network connections so it always works through a timecapsule?

Steve

carreec,

I used the information you posted to patch dhclient, with good success...  Here's the patch:

diff -purN dhcp-4.2.3/common/packet.c dhcp-4.2.3-new/common/packet.c
--- dhcp-4.2.3/common/packet.c    2011-11-24 15:18:26.329817001 -0600
+++ dhcp-4.2.3-new/common/packet.c    2011-11-24 15:18:04.843274591 -0600
@@ -140,7 +140,7 @@ void assemble_udp_ip_header (interface,
     /* Fill out the IP header */
     IP_V_SET (&ip, 4);
     IP_HL_SET (&ip, 20);
-    ip.ip_tos = IPTOS_LOWDELAY;
+    ip.ip_tos = 0;
     ip.ip_len = htons(sizeof(ip) + sizeof(udp) + len);
     ip.ip_id = 0;
     ip.ip_off = 0;

I'm running Fedora 16 64-bit as the guest. Hope this helps someone. I put the Fedora 16 RPMs here:

http://download.opensource.licor.com/linux/fedora/16/dhcp/

-Kevin

kevin1940, perfect! I patched  dhcp the same and it works now!