Prev: multi-threaded data access
Next: change the address of ld.linux-so in a dynamically linked process
From: Kenny McCormack on 24 Dec 2009 09:53
In article <e9b22a29-444a-4b15-9aeb-ba708d3594e6(a)j24g2000yqa.googlegroups.com>,
Mario Vega <mario.j.vega(a)gmail.com> wrote:
>On Dec 23, 7:43�am, gaze...(a)shell.xmission.com (Kenny McCormack)
>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".
>
>
>http://superuser.com/questions/86956

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).

From: Kenny McCormack on 24 Dec 2009 09:59
In article <barmar-39DE96.21144323122009(a)news.eternal-september.org>,
Barry Margolin <barmar(a)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.

From: Barry Margolin on 24 Dec 2009 10:03
In article <hgvvl7$hai$3(a)news.xmission.com>,
gazelle(a)shell.xmission.com (Kenny McCormack) wrote:

> In article <barmar-39DE96.21144323122009(a)news.eternal-september.org>,
> Barry Margolin <barmar(a)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.

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.

--
Barry Margolin, barmar(a)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 ***
From: Kenny McCormack on 24 Dec 2009 10:29
In article <barmar-5DF592.10030924122009(a)nothing.attdns.com>,
Barry Margolin <barmar(a)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.

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.

From: Golden California Girls on 24 Dec 2009 13:25
Barry Margolin wrote:
> In article <hguue5$hdv$1(a)aioe.org>,
> Golden California Girls <gldncagrls(a)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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: multi-threaded data access
Next: change the address of ld.linux-so in a dynamically linked process