Date: Mon, 26 Mar 2001 22:39:22 -0500 From: The Babbler <bts@babbleon.org> To: scotty@klement.dstorm.net Cc: The Babbler <bts@babbleon.org>, freebsd-emulation@FreeBSD.ORG Subject: Re: VMware networking (was: Slooow VMware on RELENG_4 SMP) Message-ID: <3AC00B6A.54C2B0D7@babbleon.org> References: <Pine.BSF.4.21.0103261836280.1691-100000@klement.dstorm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AC00B6A.54C2B0D7>