From owner-freebsd-emulation Mon Mar 26 19:39:40 2001 Delivered-To: freebsd-emulation@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 9694F37B71A for ; Mon, 26 Mar 2001 19:39:32 -0800 (PST) (envelope-from bts@babbleon.org) Received: from babbleon.org ([66.26.250.181]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 26 Mar 2001 22:39:25 -0500 Message-ID: <3AC00B6A.54C2B0D7@babbleon.org> Date: Mon, 26 Mar 2001 22:39:22 -0500 From: The Babbler Organization: None to speak of X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: scotty@klement.dstorm.net Cc: The Babbler , freebsd-emulation@FreeBSD.ORG Subject: Re: VMware networking (was: Slooow VMware on RELENG_4 SMP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org scotty@klement.dstorm.net wrote: > > I'm far from an expert on this subject, but maybe I can help? I'll type > the thoughts that come to mind, and see if it helps you... > > On Sun, 25 Mar 2001, The Babbler wrote: > > > Well, I've tried a number of things (and posted about some of them > > before). For what it's worth, I am running vmware 2. (It was free for > > me [owing to the date when I purchased my vmware1 license], so it was an > > easy decision. Performance improvements for Win 98 were quite > > noticable.) > > > > I have vmware running a 192.168.242 network ("...242" for short), with > > ..242.2 being the vmware and ...242.1 being the vmnet1 node. > > > > I have another interface on the host, which varies. At home (which is > > what I'm trying to get working first), it's on a 192.158.147 network > > ("...147" for short). ep0 is ...147.4 and its gateway is ...147.1. > > > > I run a local nameserver on the host. All this is so that the guest > > O/Ss can use a simple static setup regardless of where the host is, > > since the host is a laptop and it isn't always in the same place or at > > the same address. The guest is configured with ...242.2 as its IP > > address, ...242.1 as its gateway, and ...242.1 as its nameserver. > > So... just to verify... from the FreeBSD machine, you can type > "ifconfig -a" and see vmnet1 set as ...242.1? Yes? Yes. > This sounds > like you want to do a "routed network", rather than a bridged network. That could well be; I was not at all clear from reading the Handbook whether or not bridging covered this case. I have since had a friend who reported that it covered a similar case for him, but perhaps setting up routes is a more straightforward solution. But shouldn't the IPFIREWALL attempts work in the same way? > > In /etc/rc.conf, do you have 'gateway_enable="YES"' so that it will > route between interfaces? I've tried it both with and without, as detailed towards the bottom of the message. It's been enabled for the attempts to make the gateway work. > Do the other machines on your LAN have routes to access the ...242 subnet > by using your FreeBSD machine as their gateway? (either through a > central router/gateway that routes to your FreeBSD host, or by adding > routes to each machine individually) Otherwise, how will they know > that packets for ...242.2 need to be sent to ...147.4? I don't actually want anybody else to know about the "242" network; that's the whole point of it--to isolate it so that the other machine only know about the host and the guest sort of magically goes along for the ride. In some of the networks I hook up to, I'm only "entitled" to one DHCP address, and I can't do any routing/naming/whatever at the network level. > Or, are you using NAT? That's probably what I want to do. I've tried with and without. > > The primary guest of interest is Windows 98, though I briefly had a > > FreeBSD guest when I was running Linux and would hope to have a Linux > > guest how that I'm running FreeBSD, and perhaps a -CURRENT FreeBSD as > > well. > > I'm running 2.0.3.799_1 with a Win98se guest, no problems. I've done it > both as a routed network, and as a bridged network. Other than the fact > that Windows file sharing doesn't work on a routed network, it works fine. > (Flaw in the design of MS Network protocol) Hmmm . . . I was able to get this working under Linux, using "IP masquarading" (which is NATD, I believe). > > So . . . . > > With the latest vmware2 port (2.0.3.799_1), which is supposed to "just > > work" by using netgraph, I can't even communicate from the guest to the > > host at all. Not even from ...242.1 to ...242.2 or vice versa. > > Actually, it's a little weirder than that. The *first* time I tried > > this after installing that port, it all worked beautifully. But after > > the next time I rebooted my host, it didn't work at all, and it never > > has since then either. > > Strange. The scripts that should be starting these things are in > /usr/local/etc/rc.d/ called "rtc.sh" "linprocfs.sh" "vmware.sh". They > should be running when you boot. Do you see them running? Are there > any errors? Well, I've backed up to 2.0.03.799, so it's hard to say for sure without re-switching ports (which I will do shortly, but you had so many questions I wanted to try answering what I could at one fell swoop). With the port I'm currenlty running I don't have a "linprocfs.sh" but I do have the other two. But I'm not sure if I should have linprocfs.sh with the port I have or not. I'll send followup mail when I have a change to try re-installing that port. > Since you're running a laptop, I have a feeling that maybe these scripts > are running before the pccard code finds your NIC? If thats the problem, > you could probably fix the problem by removing them from > /usr/local/etc/rc.d, and finding a way to run them from /etc/pccard_ether > or perhaps even better would be to have /etc/pccard.conf call a different > script, which in turn calls pccard_ether, followed by the vmware scripts. That can be a problem. I tried re-running vmware.sh by hand, but it was not obvious to me that other scripts would be involved, so I didn't try running them by hand. > If you're using Netgraph briding, you don't want to use > the ...242 subnet for your interfaces... Your guest will be bridged > to appear on the same LAN, so you'll want to pick an IP in the same > subnet as your LAN. (i.e. ...147.x) This is a problem, you see. It means that my guest is on a different network depending on whether I'm at home or at work. To make that work I either have to use DHCP for the guest (which seems to confuse the DHCP server at work for some reason--I never really pursued it since it's dicey whether my employer really *wants* me to do this in first place, and anyway it was easily worked around under Linux); or I have to go in and modify the networking for the guest every time I go back and forth; as it happens, I take it into work every day, so that gets really tired really fast--especially since Windows must reboot to change networking parameters, and rebooting vmware is slow. > On my system (in bridged mode), my vmnet1 is set to "192.168.0.1", which > isn't a valid IP in any of my subnets, but I believe the vmnet1 > IP is irrelevant in a bridged environment. In the Windows guest, I have > an IP that's allocated from my LAN's subnet. (In fact, I'm using DHCP > to assign it, just like all the other IPs on the LAN) Maybe I should try that approach again. I'm not even sure that the DHCP approach is problematic. > And, of course, you don't want to tell vmware that you're in "bridged > mode". Instead, you tell it "host-only" and FreeBSD does the bridging. That much I understood. It's about the only aspect of the entire process I understood, but I did manage to get that much from the notes with the port. > > So I reverted back to the previous vmare2 port (2.0.3.799). From there > > I can ping from the guest (...242.2) to the host vmware (...242.1) as > > well as to the host's "real" addr (...147.4), but I cannot access the > > host's gateway (...147.1). I *can* access the host's nameserver via > > ...242.1, so if from the guest I do something like "ping www.yahoo.com" > > then the numeric IP address to ping will be correctly resolved, but the > > packets won't actually get delivered. > > Possibly its sending the packets out, but your internet gateway doesn't > know that it needs to forward packets to your guest through your FreeBSD > box. Also possible that you don't have gateway_enable set in > /etc/rc.conf. That sounds like a strong possibility. I'd hope that NATD would solve that. > > I tried solving this under 4.2-RELEASE by enabling bridging the in the > > kernel, but that broke my networking with my 3com PCMCIA card > > *completely*--my *host* was no longer able to reach its gateway, so > > obviously my guest couldn't either, and I was pretty much dead in the > > water. I have since solved *that* problem by upgrading to 4.3-BETA, > > where I can enable briding in the kernel, and the host networking works > > just great, but I still can't get the guest packets anyplace. However, > > I will be perfectly frank in confessing that I'm not at all clear on how > > bridging is really supposed to work here. > > I've tried FreeBSD's experimental bridging support, and while it more or > less worked, it was buggy. You should use the Netgraph bridging, it > works a lot better. > > In vmware 2.0.3.799_1 it will automatically load the netgraph bridging > module as FreeBSD boots. Therefore, you want to disable all bridging > in your kernel if you're going to use it. Otherwise there may be > conflicts. (At least, thats what worked for me) I'll double-check on that. > > It's built into the kenel, and sysctl shows that net.link.ether.bridge > > is 1, and I get messages about setting the interfaces into promiscuous > > mode, but the ep0 interface, if I do ifconfig, doesn't actually show > > itself as being in promiscuous mode. This could be the root of the > > problem, or it could be that the bridging is trying to set up too early, > > and PCMCIA intialization is realatively late. But I have tried using > > sysctl to turn the bridging off and back on, and that didn't fix > > anything. > > > > The bridging man page does talk about using bridging whilst enabling IP > > forwarding, which logically might be required since they are two > > separate networks, but I can't figure out how one combines the two > > concepts of bridging and IP forwarding or how to write the rules under > > such a circumstance. Also, the briding man page has a warning that > > having both interfaces have IP addresses is bad, so this might be why > > things are broken for me. > > The whole idea of briding is to make it all look like one, big, network. > Using IP forwarding doesn't really make sense here, does it? However, > turning it on and off should be simple enough to try. > > Well... maybe some of that will help....? :) Thanks. It at least gives me a couple of things to try. -- "Brian, the man from babble-on" bts@babbleon.org Brian T. Schellenberger http://www.babbleon.org Support http://www.eff.org. Support decss defendents. Support http://www.programming-freedom.org. Boycott amazon.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message