VMware Communities
barnys
Enthusiast
Enthusiast

Unable to bridge airport using DHCP.

Hello,

I have posted on this a few times already because I have simply been unable to use bridge networking over the airport and DHCP. It just won't work, and I don't know what else to do.

Following what I have done:

\- Check DHCP server scopes. In the servers that I get logs, I see OFFERs being made to the VM but this never gets it.

\- Bridged using static IPs work perfect.

\- Removed Parallels, removed Fusion, delete all my VMs from the HDD, delete all other network connections and ports, reboot, install Fusion, install new Guest OSs (Windows XP Pro, 2003 Enterprise, Ubuntu, Red Hat 4.0), installed vmware tools, tried again all four and nothing.

\- When I removed everything I also did a search for EVERYTHING and ANYTHING from Vmware and deleted manually Preference directories under the Library.

\- Focused on Windows Pro, and changed the Nic to an "Intel Pro" by adding the following line to the .vmx file, and installing the correct drivers:

ethernet0.virtualDev = "e1000"

\- Tried already 6 different Access Points, from cheap $40 ones to higher end models costing thousands of dollars.

I am simply stomped by this. I don't know what else to do, and if I can post any logs here of whatever I am requested, or who knows. This is the ONLY feature that is stopping me from putting aside my Parallels, because this works perfect under Parallels.

What do I do? Suggestions?

Thank you!

Reply
0 Kudos
45 Replies
barnys
Enthusiast
Enthusiast

I have also tried selecting en1 as the default NIC by editing /Library/Application Support/VMware Fusion/boot.sh and making the following changes:

\# Bridge to host network interface 'en0'.

"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en1

\# Bridge to the primary host network interface (which can change over time).

\# $LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 ''

\- Restarted the VM, reinstalled vmware-tools, turned off/on the airport,... and NOTHING!!!! Smiley Sad

Lastly I tried opening a support ticket at www.vmware.com/support, but once I log and I click on Fusion (or Wokstation 6.0 for another problem), there is a problem resolving to eservice.vmware.com.

I am hitting wall in everything direction...

Reply
0 Kudos
admin
Immortal
Immortal

What's your guest OS? Did you install VMware Tools in the VM?

Is there a firewall running in the host OS, and/or guest OS?

Is our support site still not working for you?

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

My guest OSs are:

\- Windows XP Pro

\- Windows 2003 Enterprise

\- Red Hat 4.0 ES

Firewalls turned off, although i don't see the relevance of this. I should still be able to get IP addresses as I was before and under my workstation and server versions as well.

Support site is working, but no response has been received yet.

Thanks,

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

I am sorry, I guess I hit "send" too quick, but I have turned off the firewalls of both my host and my guest OSs for testing. Nevertheless this worked for me in the past with both host and guest FWs turned on, as it does in the vmware workstation and server versions.

As I mentioned this feature works perfect if bridging over the wire, despite the condition of my firewalls.

Reply
0 Kudos
admin
Immortal
Immortal

Firewalls turned off, although i don't see the relevance of this.

It was a long shot, but a sufficiently aggressive firewall (in either the guest or the host) could block the DHCP responses.

Do you know how to use tcpdump; if so, can you capture the DHCP request/response on the host interface? Assuming your airport interface is en1, something like

sudo tcpdump -i en1 udp and \(dst port 67 or dst port 68\)

should do it.

Assuming we see that response, we'd want to check that it's properly being bridged to vmnet0, and that the guest sees it on its own interface.

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

I am providing the tcpdump output of en1 when negotiating DHCP for 3 NICs in my Mac. One is the Host OS, the following for a Parallels VM doing bridge over en1, and the last Fusion, also doing bridge over en1.

You see the whole interaction, and how en1 sends out requests for fusion, they get to the firewall/AP, then the firewall makes and OFFER but the client never gets the IP. This is the same that I keep on noticing over and over, similarly with other firewalls/APs. In this case the firewall output is of a Juniper SSG5-wifi. I have tested already with a few firewall/APs and whenever the devices permits som

e kind of debuging capability I have looked at it to see similar results.

======================================================

THIS IS FOR THE HOST OS:

en1 tcpdump:

MACFBSD:~ barnys$ sudo tcpdump -i en1 udp and \(dst port 67 or dst port 68\)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes

21:37:08.295161 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from 00:17:f2:ed:fa:c8 (oui Unknown), length: 300

21:37:08.299118 IP gatel.bootps > 10.210.59.35.bootpc: BOOTP/DHCP, Reply, length: 300

firewall debug:

WAP1.ma.issecurity.net-> debug dhcp all

WAP1.ma.issecurity.net-> get db st

\## 2007-06-19 00:37:15 : DHCP: Minute timer is tiggered for Server&Relay

\## 2007-06-19 00:37:15 : DHCP: Client(ethernet0/0) periodic check(1,0)

\## 2007-06-19 00:37:15 : DHCP: Client(bgroup1) periodic check(1,0)

\## 2007-06-19 00:37:15 : DHCP: HA (client) send (Release): (bgroup1)

\## 2007-06-19 00:37:15 : DHCP: send_dhcp_pak enter src_ip: 0x0, dst_ip: dst_ip

\## 2007-06-19 00:37:15 : DHCP: packet send to outif

Reply
0 Kudos
admin
Immortal
Immortal

Thanks, I appreciate that. So it looks like under Fusion, the guest is sending DHCPDISCOVER and never receiving the DHCPOFFER which would provoke it to request a DHCPREQUEST, so the guest keeps sending DHCPDISCOVER over and over and over. That's how I read this, anyway.

Can I ask you for one more set of data? Again, thanks for your time running these tests. We/I haven't seen this problem on all the Airport-enabled Macs we have around, so your data is really useful here. Could you run a sniffer, say ethereal, inside the Windows VM (under Fusion) while it's trying to negotiate DHCP?

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

That's exactly what's happening. From the AP/Firewall side everything looks good. We see a discover come in and we do an offer, but the client won't pick it up. Any other device will work, as exampled in the other outputs.

The guest OS pretty much sees the same. Attached a pcap file for the DHCP negotiation over en0 and over en1. I have filtered to show DHCP specific only. It works with no glitches if I bridge over the cable.

I understand that this is a working function and don't hesitate that it is working in all of your demo systems. It was working for me, and then in one of the BETA upgrades it stopped working. I have found just a handful of people with the same problem and they simply turned over to parallels, because this works well with it, and also the selection of the interface to bridge over is very simple and powerful. Nevertheless I am putting a lot of emphasis in my group at the company to use more Vmware solutions, so this would be great if I could understand what the heck is wrong with it.

If I could WIPE out completely and entirely Fusion and reinstall I would, but I noticed that the uninstall leaves things behind. I am opened to any suggestions, except reinstalling my MBP or crashing other programs Smiley Wink

Thanks,

Reply
0 Kudos
admin
Immortal
Immortal

Thanks again for all the details. It looks like exactly what you said at first -- the DHCP responses are getting lost on the way back. I'm filing a bug in our internal tracker with all the information you've provided. A couple more questions for you:

\- what computer(s) have you seen this on? I'm assuming MacBook Pro, but I don't think I've seen you say that for sure.

\- you do have VMware Tools installed in the guest, right?

\- if it worked on the same host in our earlier betas, do you remember which was the last release where it worked and the first release where it doesn't work?

\- do you have any VPN clients, or other noteworthy optional network components, installed on your host?

DHCP over our wireless bridge is working for lots of people including our internal testing, but I sure would like to get to the bottom of why it's not working for you.

Reply
0 Kudos
admin
Immortal
Immortal

Oh, one more experiment while I've got your attention, please: can you run our vmnet sniffer (/Library/Application Support/VMware Fusion/vmnet-sniffer) on vmnet0? It works a lot like tcpdump though it doesn't accept all the same options; in particular you can't filter the capture. I'd like to know if the incoming DHCPOFFER packets seem to be discarded by our bridge (between en1 and vmnet0) or in the virtual device (between vmnet0 and the VM itself).

If you run vmnet-sniffer -w vmnet0.pcap vmnet0, and could tell me if you see the DHCPOFFER responses there, that would be great. You can send me the .pcap file, or use ethereal or something similar to restrict it to just the DHCP traffic before posting it, or just tell me what you see in it, if you don't want to post the whole thing. Thanks!

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

Hello,

\- I have seen this problem only on MacBook Pros.

\- I have VMware tools installed, and as part of my troubleshooting, I removed, reinstalled... multiple times.

\- It hasn't worked since Beta 3, at least for me.

\- I use VPN clients upside down in ALL of my systems, both IPSEC and SSL. These were removed at some point just "because" to discard conflicts. However do note that the same clients are used and work via the cable, and for all of my other Vmware products, as well as Parallels. A good shot, but don't think this is it.

Thanks for your effort. I influence a lot of people in my organization to purchase VMware products and want to remain loyal to this. Provided that this is affecting my main development mobile system, this is CRITICAL for me to get resolved.

Reply
0 Kudos
fns
Contributor
Contributor

Hi folks,

Same thing on my side. My details:

\- Fusion is Version 1.0b4 (49528)

\- host machine is a 17" CD MacBookPro

\- host OS is Windows XP Pro

\- local DHCP server is a Debian GNU/Linux 3.1

\- ethernet connection is based on MBP's AirPort and an ASUS wireless router

Firewalls turned off for testing on both sides. VMWare tools are installed. Bridging working in Parallels build 3170.

I also checked the entire thing just like barnys - same thing happens. My dhcpd sends DHCPOFFER packets but they all lost in space and Fusion does not pick them up at all. If you need any help to debug this issue just let me know.

Message was edited by:

fns

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

Thanks for sharing your experience. I have been awaiting to hear anything from Vmware's team either through the forum or via their technical support.

I opened a ticket (189927764) on 06/16 (so 11-12 days ago already) and it hasn't even been assigned.

Thanks,

Reply
0 Kudos
fns
Contributor
Contributor

Hi barnys,

In case you will get any info just pls do post them!

Thanks in advance.

Reply
0 Kudos
Pat_Lee
Virtuoso
Virtuoso

Thanks for sharing your experience. I have been

awaiting to hear anything from Vmware's team either

through the forum or via their technical support.

I opened a ticket (189927764) on 06/16 (so 11-12 days

ago already) and it hasn't even been assigned.

Just so you know, I pinged support to see where this stands.

Pat

Reply
0 Kudos
admin
Immortal
Immortal

Hi Barnys,

I'm just now looking at this thread. You've done an awesome job collecting logs and traces to get to the bottom of this so far. I found the debug logs from your AP particularly interesting.

Can you re-run this experiment, this time collecting the following information for me?

1. sudo tcpdump -s 0 -i en1 udp and \(dst port 67 or dst port 68\) -w dhcp-en1.pcap

2. Wireshark/Ethereal capture from the VM

3. The AP logs.

I'm most interested in the first capture file (dhcp-en1.pcap).

Thank you very much!

Reply
0 Kudos
barnys
Enthusiast
Enthusiast

Hello,

Sorry for taking so long. I haven't been using Fusion much at all since my support ticket took over two weeks to get assigned, and has been sitting on "Sub Status: Waiting on Customer".

Parallels has provided me with what I needed these days.

Attached the information requested. I could not write to a file with the tcpdump syntax provided, but I included -vv to the command and copy pasted everything.

Thanks,

Reply
0 Kudos
admin
Immortal
Immortal

Hi Barnys,

Sorry for the really long delay in getting back to this issue! But we're trying really hard to reproduce this in house, and so far no luck. We've tried with 3 generations of MBPs, with 3 different kinds of access points, with and without WPA/WPA2, and every time the VM's can get an IP address from the DHCP server across the wireless interface.

So we started looking carefully at these files you posted back in July. Unfortunately, the ASCII dumps in tcpdump-MBP .txt didn't have the details we needed, like the link-layer header information that you can get from "tcpdump -e". And ideally we would have liked the pcap binary files generated by "tcpdump -w", so we can look at every bit in the packets to understand why the DHCP offer from the Access Point is not making it to the VM.

I was curious, did you capture "dhcp-en1-070707.pcap" from the "en1" interface indeed? I wonder why it only has the 4 DHCP Discover packets, while your ASCII "tcpdump-MBP.txt" has the DHCP Discovers as well as the DHCP Offers back from the Access Point?

None the less, we would really appreciate it if you could provide the following pieces of information, when you see this behaviour again, where the VM is not getting a DHCP assigned IP address from the Access Point:

1. That "tcpdump -s 0 -i en1 -w dhcp-en1.pcap" with all the bits of information

2. The sniffer trace from the "vmnet0" virtual switch:

cd /Library/Application Support/VMware Fusion/

sudo ./vmnet-sniffer -w dhcp-vmnet0.pcap vmnet0

3. Please verify that the VMware Fusion "vmnet" driver is indeed bridging to the "en1" (AirPort) interface:

sudo ps auxwww|egrep bridge

sudo dmesg | egrep bridge

Thank you!

Reply
0 Kudos
mileserickson
Contributor
Contributor

Was this issue ever nailed down?

I just switched from Parallels to Fusion. VMWare obviously has created a superior product, and I love how you've nailed all the details that Parallels gets wrong: dual monitors are handled correctly, I see the correct mouse-over cursors in Windows applications, and everything feels as fast and smooth as running Windows natively. However, I seem to be experiencing the same issue that the original poster described: NAT works fine, but if I select Bridged networking (which worked great in Parallels), Windows is unable to obtain a DHCP lease.

I'd be happy to provide all of the troubleshooting details that you requested from the original poster, if you'd find them useful. I'm thrilled to see that your team took the original report so seriously, and I'd love to work together with you to figure out what's going on... unless you've already figured it out! Please do let me know.

Cheers,

Miles

Hardware: 13" MacBook Core 2 Duo (12/06), Mac OS X 10.5.5 Build 9F33, 2GB RAM

Router/DHCP server: Apple AirPort Express, version 7.3.2, running in 802.11n (5GHz) mode

VM: Windows XP (5.1.2600)

Reply
0 Kudos