Win XP SP3 in fusion can surf the net through the mac's airport in either bridged or nat mode fine. the mac has a static ip. the windows is set to dhcp. ifconfig on the mac shows en1: inet 192.168.1.43 netmask 0xffffff00 broadcast 192.168.1.255 vmnet1: inet 172.16.193.1 netmask 0xffffff00 broadcast 172.16.193.255 vmnet8: inet 172.16.143.1 netmask 0xffffff00 broadcast 172.16.143.255 ipconfig on windows shows when the network adapter settings in fusion are changed to NAT and the ipconfig is released and renewed, then ipconfig shows This shows that the virtual machine is now going through the subnet of vmnet8 Wireshark however does not reveal vmnet8, just en0 and en1-and en1 is getting all the traffic. Why no vmnet8? Why is vmnet8 getting a routable address? shouldn't it be one of those non-routeable 192.xxx.xxx.xxx or 10.xxx.xxx.xxx numbers? And even if windows is bridged and using 192.168.1.42, little snitch on the mac keeps asking if vmnet-natd can talk to the net so i know it's active. I can see packets going to the windows ip but it's mixed in with traffic going to the mac (as I'd expect since they are both using the same airport) but it's all going over en1. ( btw, i dont understand why the gateway in windows is not 172.16.143.1 but rather .2 - after all doesnt the windows box have to talk to vmnet8?) asked 24 Jul '11, 07:30  bwanaaa |
2 Answers:
First of all lets get the idea of "non-routable" addresses straight. The ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are reserved for private use. This means they are not routed on the Internet, but they are perfectly routable in private networks (like your VM fusion setup). See also RFC 1918 for more information on these IP ranges. The addresses assigned to vmnet1 and vmnet8 are within these private address ranges. The reason your XP guest has 172.16.143.2 as gateway and not 172.16.143.1, is that the NAT deamon used by VMware Fusion has it's own address (.2), that's just the way VMware has implemented it. Unfortunately the vmnet interfaces are not visible to libpcap (which is used by Wireshark to capture packets), so you can't use Wireshark to capture on these (virtual) interfaces. However, VMware has provided the tool "vmnet-sniffer", which makes it possible to capture on these interfaces. See http://communities.vmware.com/thread/177416 for more info on using "vmnet-sniffer". answered 24 Jul '11, 08:17  SYN-bit ♦♦ |
tnx. i learned that the w option doesnt work on a mac, rather one needs to do sudo vmnet-sniffer -e vmnet8 >outputfile.pcap answered 27 Jul '11, 05:12 bwanaaa That must be something on "your" Mac then, cause VMware fusion is a Mac Application, also the -w option does indeed work on "my" Mac. Maybe you could check the VMware forums or create a case with VMware? (27 Jul '11, 11:01) SYN-bit ♦♦ that was what the vmware moderator suggested actually. and this does not work when in the vmware directory sudo vmnet-sniffer -e vmnet8 >./tmp/outputfile.pcap permission denied but this does work sudo vmnet-sniffer -e vmnet8 >/tmp/outputfile.pcap but that's a vmware question too. (27 Jul '11, 15:13) bwanaaa |
thank you for that. dunno why i forgot bout 172.xxx.xxx.xxx.
i tried the vmnet-sniffer
dumbuser$ vmnet-sniffer -e vmnet8 -w testdump
and it gave a blank line-no prompt or anything so i assumed the process was capturing. i did stuff but then did not know how to stop the capture. I hit ctrl C but no capture file was saved. I guess this is a vmware question from here. But just to let you know, i tried the same experiment with parallels 6, and wireshark can see those virtual adapters , vNIC0 and vNIC1. But guess what, no traffic is seen on them when wireshark is running on the host.
(converted your "answer" to a "comment", please see the FAQ for details)
I just tried the vmnet-sniffer command on my own MacbookPro with Fusion and it does work as expected. Did you use"sudo"?
yes i can get it to start but how do you stop it, save the fle, and gracefully exit from terminal?
The "-w <file>" option makes the output go to file in libpcap format so that you can read the file in Wireshark.
There are no options to stop the capture automatically, so manually pressing "<ctrl>+C" is the right way to go.
After that, you can close the terminal window and open the file in Wireshark.