Continuation of the MacOS networking thread...
Kenny McCormack
this in the other thread. I have my reasons for starting a new thread.)
OK, so I found the GUI control panel for changing the network settings.
Basically, it gives these options for configuring the device (en0):
1) Manual
2) DHCP
3) DHCP with manual address
4) BOOTP
5) Off
Now, the problem is this: I am running a virtual machine, using VmWare
Fusion, and I want the VM to connect to my cable modem. The point, of
course, is that only one machine can be connected to the cable modem,
and there is a race condition between the VM and the real machine to see
who gets the attention of the cable modem. That is, who gets attention first.
Unfortunately, lately, the Mac seems to be winning the race (before, it
was working correctly -> the VM was winning). Nothing changed to cause
this to change, but obviously something did (if you see what I mean...)
Now, unfortunately, if I set the control panel setting to anything other
than DHCP, then VmWare gets unhappy and decides that the ethernet device
isn't running. You get a weird error message from VmWare about the
bridged device not running. So, what I need (on the Mac side) is either:
1) To leave it as DHCP, but a way to temporarily disable the DHCP
seeking behavior. And then to re-enable it later.
I.e., I want the equivalent of doing "ipconfig /release" in
Windows. And then, of course, "ipconfig /renew".
Or:
2) A way to put it to, say, Manual, and then do the right commands
from the shell prompt to make VmWare happy with the state of the
device.
Help (or pointer to URL) with 1) or 2) above would be greatly
appreciated. Note that option 1) above is preferred.
Moi
> (Meta note: Please, no guff to the effect that I "should" have posted
> this in the other thread. I have my reasons for starting a new thread.)
>
> OK, so I found the GUI control panel for changing the network settings.
> Basically, it gives these options for configuring the device (en0):
> 1) Manual
> 2) DHCP
> 3) DHCP with manual address
> 4) BOOTP
> 5) Off
>
> Now, the problem is this: I am running a virtual machine, using VmWare
> Fusion, and I want the VM to connect to my cable modem. The point, of
> course, is that only one machine can be connected to the cable modem,
> and there is a race condition between the VM and the real machine to see
> who gets the attention of the cable modem. That is, who gets attention
> first.
>
> Unfortunately, lately, the Mac seems to be winning the race (before, it
> was working correctly -> the VM was winning). Nothing changed to cause
> this to change, but obviously something did (if you see what I mean...)
I'd put a router between the computer and the modem.
Routers typically have DHCP servers on board, which would allow each VM to
obtain it's own DHCP lease. Timeout could be a problem. ARP could also be
a probem, but I assume that VMware properly supplies fake MAC addresses
for the VMs.
HTH,
AvK
Kenny McCormack
Moi <ro...@invalid.address.org> wrote:
...
>I'd put a router between the computer and the modem.
>Routers typically have DHCP servers on board, which would allow each VM to
>obtain it's own DHCP lease. Timeout could be a problem. ARP could also be
>a probem, but I assume that VMware properly supplies fake MAC addresses
>for the VMs.
Thank you for your contribution, but not a solution.
Please solve the problem as stated.
Ralph Böhme
Why not let the Mac have the real network interface and put the
VM in NAT mode?
-Ralph
--
s/-nsp// for mail
Kenny McCormack
Ralph Böhme <ralp...@rsrc.de> wrote:
...
>Why not let the Mac have the real network interface and put the
>VM in NAT mode?
Because.
The problem must be solved as stated.
A little bit of reading between the lines will allow the smart reader to
figure out what I'm actually doing, but it is not relevant to the problem.
Golden California Girls
Been a while since 10.4.x, but IIRC the network is brought up via a shell
script. Edit the script might be the answer.
http://osxbook.com/book/bonus/ancient/whatismacosx//arch_startup.html
Scott Lurndal
why? This isn't a classroom. A USD50 router would handle all your
issues without having to fart with OSx configuration.
scott
Kenny McCormack
Thank you for your contribution, but go fuck yourself.
Barry Margolin
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> (Meta note: Please, no guff to the effect that I "should" have posted
> this in the other thread. I have my reasons for starting a new thread.)
>
> OK, so I found the GUI control panel for changing the network settings.
> Basically, it gives these options for configuring the device (en0):
> 1) Manual
> 2) DHCP
> 3) DHCP with manual address
> 4) BOOTP
> 5) Off
>
> Now, the problem is this: I am running a virtual machine, using VmWare
> Fusion, and I want the VM to connect to my cable modem. The point, of
> course, is that only one machine can be connected to the cable modem,
> and there is a race condition between the VM and the real machine to see
> who gets the attention of the cable modem. That is, who gets attention first.
>
> Unfortunately, lately, the Mac seems to be winning the race (before, it
> was working correctly -> the VM was winning). Nothing changed to cause
> this to change, but obviously something did (if you see what I mean...)
I don't understand how the VM ever won the race in the first place.
Doesn't the Mac get its IP while it's booting? But the VM isn't started
up until after the Mac is booted, you login, and then start the VMWare
application. That's probably at least a minute later.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mario Vega
wrote:
> 1) To leave it as DHCP, but a way to temporarily disable the DHCP
> seeking behavior. And then to re-enable it later.
> I.e., I want the equivalent of doing "ipconfig /release" in
> Windows. And then, of course, "ipconfig /renew".
Golden California Girls
>
> I don't understand how the VM ever won the race in the first place.
> Doesn't the Mac get its IP while it's booting? But the VM isn't started
> up until after the Mac is booted, you login, and then start the VMWare
> application. That's probably at least a minute later.
Well, the Mac does get an IP for its netboot. Then it takes the interface down,
powered down I believe, later in the boot. It runs a script to bring it back
up. That's how the race happens. I'm sure he is also starting VM in a script.
Add or subtract a startup item and the order changes. To insure the order he
wants he is going to have to get into the Mac boot scripts and make sure the
interface is powered on and negotiated hardware protocalls, start VM and wait
for it to come up -- this assumes VM can be started here -- then continue the
rest of the Mac script getting the DHCP. A considerable hack.
Golden California Girls
>
> I don't understand how the VM ever won the race in the first place.
> Doesn't the Mac get its IP while it's booting? But the VM isn't started
> up until after the Mac is booted, you login, and then start the VMWare
> application. That's probably at least a minute later.
Well, the Mac does get an IP for its netboot. Then it takes the interface down,
Barry Margolin
Golden California Girls <gldnc...@aol.com.mil> wrote:
> Barry Margolin wrote:
> >
> > I don't understand how the VM ever won the race in the first place.
> > Doesn't the Mac get its IP while it's booting? But the VM isn't started
> > up until after the Mac is booted, you login, and then start the VMWare
> > application. That's probably at least a minute later.
>
> Well, the Mac does get an IP for its netboot.
Did I miss him mentioning that he's using netboot? Was it in the other
thread, which I mostly didn't read?
> Then it takes the interface
> down,
> powered down I believe, later in the boot. It runs a script to bring it back
> up. That's how the race happens. I'm sure he is also starting VM in a
> script.
> Add or subtract a startup item and the order changes. To insure the order
> he
> wants he is going to have to get into the Mac boot scripts and make sure the
> interface is powered on and negotiated hardware protocalls, start VM and wait
> for it to come up -- this assumes VM can be started here -- then continue the
> rest of the Mac script getting the DHCP. A considerable hack.
--
Kenny McCormack
Very interesting. And it looks like the poster there had much the same
sort of issue in mind (including giving the equivalent Windows commands
as illustration).
However, looking at the answer given, it looks to me that it would be
equivalent to using the graphical control panel to (temporarily) set it
to BOOTP. But alas, as I mentioned in the OP, doing that causes the VM
to drop the (virtual) device entirely (i.e., it acts as if the
physical/real device no longer exists).
Kenny McCormack
Barry Margolin <bar...@alum.mit.edu> wrote:
...
>I don't understand how the VM ever won the race in the first place.
>Doesn't the Mac get its IP while it's booting? But the VM isn't started
>up until after the Mac is booted, you login, and then start the VMWare
>application. That's probably at least a minute later.
Good question. At the root of the issue you raise, I'm not sure what
answer I can give - i.e., to "How did it ever work?". All I can say is
"just lucky, I guess".
But do note that it is not just "well it happened at boot and that's
that." In order to get the cable modem to "see" another device, I
power-cycle the modem. This is standard procedure with these sorts of
devices; the assumption is that the cable modem (and similar devices)
locks into the "mac address" of the device it is communicating with.
So, when I power cycle it, then it is again a free-for-all to see who
gets it next.
Barry Margolin
gaz...@shell.xmission.com (Kenny McCormack) wrote:
Since a big piece of the problem seems to be that VMWare doesn't like it
when you change the network configuration out from under it, I think
your question might be more appropriately posted in a VMWare group, or
maybe sent to VMWare tech support. It's not really a generic Unix
issue, but something specific to VMWare.
Kenny McCormack
>when you change the network configuration out from under it, I think
>your question might be more appropriately posted in a VMWare group, or
>maybe sent to VMWare tech support. It's not really a generic Unix
>issue, but something specific to VMWare.
True, on the surface.
However, I can't fix VMWare. Don't argue with that; it is simply a fact.
And most of computing *is* finding workarounds - fixing things where you
*can* fix them, since you often can't fix the real underlying issue.
I'm hoping for a Unix/BSD/MacOS hack/kludge that will get me through
this, while being aware that it would be just that - a hack/kludge.
Believe me: If there was an easy solution, I'd have done it, and not
bothered to post at all.
Golden California Girls
> In article <hguue5$hdv$1...@aioe.org>,
> Golden California Girls <gldnc...@aol.com.mil> wrote:
>
>> Barry Margolin wrote:
>>> I don't understand how the VM ever won the race in the first place.
>>> Doesn't the Mac get its IP while it's booting? But the VM isn't started
>>> up until after the Mac is booted, you login, and then start the VMWare
>>> application. That's probably at least a minute later.
>> Well, the Mac does get an IP for its netboot.
>
> Did I miss him mentioning that he's using netboot? Was it in the other
> thread, which I mostly didn't read?
He isn't. Don't assume because it isn't selected as the first boot method that
the ROM didn't get an IP.
Barry Margolin
gaz...@shell.xmission.com (Kenny McCormack) wrote:
> In article <barmar-5DF592....@nothing.attdns.com>,
> Barry Margolin <bar...@alum.mit.edu> wrote:
> ...
> >Since a big piece of the problem seems to be that VMWare doesn't like it
> >when you change the network configuration out from under it, I think
> >your question might be more appropriately posted in a VMWare group, or
> >maybe sent to VMWare tech support. It's not really a generic Unix
> >issue, but something specific to VMWare.
>
> True, on the surface.
>
> However, I can't fix VMWare. Don't argue with that; it is simply a fact.
But the VMWare tech support people might know how to configure OS X
appropriately for what you're doing.
Kenny McCormack
>
>But the VMWare tech support people might know how to configure OS X
>appropriately for what you're doing.
Don't go there. There is no VMWare tech support. I know their business
model now.
I'm not knocking them or trying to be difficult (seriously). It is just
that their tech support mountain is too difficult to climb nowadays.
Barry Margolin
gaz...@shell.xmission.com (Kenny McCormack) wrote:
OK, then a newsgroup or forum. My point is that other VMWare users are
more likely to know the workaround for this than generic Unix
programmers (BTW, why is this in .programmer rather than .admin?).
Kenny McCormack
>> that their tech support mountain is too difficult to climb nowadays.
>
>OK, then a newsgroup or forum. My point is that other VMWare users are
See above. I consider all of that to be part of the "tech support mountain".
>more likely to know the workaround for this than generic Unix
>programmers (BTW, why is this in .programmer rather than .admin?).
When we start discussing topicality, I think we can safely say that we
are now into "angels on pins" territory.
Barry Margolin
gaz...@shell.xmission.com (Kenny McCormack) wrote:
My basic point is that you need to find experts on using VMWare on Macs,
and I don't think you've found them here. Configuring networking on
Macs is not like generic Unix, and when you throw in your unusual VMWare
constraints it's even further from our bailiwick.
I'm a Mac user (for 25 years), and I don't know how to trick it into
doing what you want.
Kenny McCormack
>doing what you want.
You may be right. It may not be possible (*).
That would be a pity, but not totally unexpected.
(*) Given, as you say, my somewhat strange requirements.
Kenny McCormack
P.S. I should also add that the equivalent thing *does* work under
Windows. That is, if you run VMWare for Windows, you can set things up
so that the VM sees and accesses the ethernet device but the host OS has
it in the "released" state - via doing: ipconfig /release
I have done this and found it useful (under Windows), in a similar situation.
So, it seemed reasonable to expect the same would be possible on the Mac.