Re: [9fans] ip resolving

Re: [9fans] ip resolving

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 87 bytes --]

You need to start the dns client after ipconfig:

	ip/ipconfig
	ndb/dns -r

-Steve

[-- Attachment #2: Type: message/rfc822, Size: 794 bytes --]

From: 9fans@cse.psu.edu
To: 9fans@cse.psu.edu
Subject: [9fans] ip resolving
Date: Wed, 19 Feb 2003 15:31:06 +0000
Message-ID: <3291755392@snellwilcox.com>


Hi,
I have a problem with the ip resolving. I am using vmware 3.2 and I get my 
IP and DNS address via DHCP. 

cat /net/ndb shows me that I have dns and ip 

I can see other machines but only with IP addresses. I tried also 
ndb/csquery but nothing. I can resolve nothing. 

Nikolay

[9fans] Re: ip resolving

[Nikolay Paskov]

Steve Simon writes:

> You need to start the dns client after ipconfig:
>
> 	ip/ipconfig
> 	ndb/dns -r
>
> -Steve


I did it!

[9fans] Re: ip resolving

[Nikolay Paskov]

Russ Cox writes:

>> No, 132.187.1.1 is not a router I'm using it as DNS server on my linux box.
>> I changed it manually of course. But may be you are right about blocking
>> from vmware side. I have to check this. BTW now I have a problem with the
>> DHCP server. Nothing is changed in configuration only rebooted and now I
>> have no response from the DHCP server.
>
> reboot again.  there appears to be a bug in the
> new ip drop-if-no-default-route code.

I did but nothing still the same mistake.

Nikolay

Re: [9fans] Re: ip resolving

[Russ Cox]

> No, 132.187.1.1 is not a router I'm using it as DNS server on my linux box.
> I changed it manually of course. But may be you are right about blocking
> from vmware side. I have to check this. BTW now I have a problem with the
> DHCP server. Nothing is changed in configuration only rebooted and now I
> have no response from the DHCP server.

reboot again.  there appears to be a bug in the
new ip drop-if-no-default-route code.

russ

[9fans] Re: ip resolving

[Nikolay Paskov]

Russ Cox writes:

>> Now it works. Why I can't use 132.187.1.1 instead 192.168.79.2 ?
>> I have nat what is the problem?
>
> did you change it manually to 132.187.1.1?
> i have a hard time believing vmware set it to that.
> how did it get set to 132.187.1.1 in the first place?
>
> first of all, 132.187.1.1 is likely to be a router
> rather than a dns server.  vmware may be blocking
> dns packets except the ones to itself.  i don't know.
> just use the vmware ones.
>

No, 132.187.1.1 is not a router I'm using it as DNS server on my linux box.
I changed it manually of course. But may be you are right about blocking
from vmware side. I have to check this. BTW now I have a problem with the
DHCP server. Nothing is changed in configuration only rebooted and now I
have no response from the DHCP server.

Re: [9fans] Re: ip resolving

[Russ Cox]

> Now it works. Why I can't use 132.187.1.1 instead 192.168.79.2 ?
> I have nat what is the problem?

did you change it manually to 132.187.1.1?
i have a hard time believing vmware set it to that.
how did it get set to 132.187.1.1 in the first place?

first of all, 132.187.1.1 is likely to be a router
rather than a dns server.  vmware may be blocking
dns packets except the ones to itself.  i don't know.
just use the vmware ones.

Re: [9fans] Re: ip resolving

[andrey mirtchovski]

On Wed, 19 Feb 2003, Russ Cox wrote:

> it's possible that windows vmware dns is different
> from linux vmware dns, if you are running linux.
>

my linux vmware has the following for dns (straight boot, haven't touched
anything in the configuration except uncomment ip/ipconfig in termrc):

term% cat /net/ndb
ip=192.168.215.128 ipmask=255.255.255.0 ipgw=192.168.215.2
	dom=.localdomain
	dns=192.168.215.2
term%

at least 2.0 asks the user whether they want to bridge the interface or use
NAT. my ethernet setting is NAT...

[9fans] Re: ip resolving

[Nikolay Paskov]

Now it works. Why I can't use 132.187.1.1 instead 192.168.79.2 ?
I have nat what is the problem?

Nikolay

Russ Cox writes:

> how did those dns servers get there?
> at least under my vmware, dns is served
> by a vmware interface at .2, so i'd expect
> to see
>
> 	dns=192.168.79.2


>
> it's possible that windows vmware dns is different
> from linux vmware dns, if you are running linux.
>
> plan 9's ndb/dnsdebug is like unix's dig.
> try this:
>
> g% ndb/dnsdebug
>> @192.168.233.2 www.google.com
> 1.1: sending to 192.168.233.2/192.168.233.2 www.google.com ip
> 1: rcvd OK from 192.168.233.2 (authoritative recurse can_recurse)
> 	Q:    www.google.com ip
> 	Ans:  www.google.com                   5 min           ip   	216.239.37.101
> 	Auth: google.com                       3 day 13 hr 21  ns   	ns1.google.com
> 	      google.com                       3 day 13 hr 21  ns   	ns2.google.com
> 	      google.com                       3 day 13 hr 21  ns   	ns3.google.com
> 	      google.com                       3 day 13 hr 21  ns   	ns4.google.com
> 	Hint: ns1.google.com                   1 day 12 hr 52  ip   	216.239.32.10
> 	      ns2.google.com                   1 day 12 hr 37  ip   	216.239.34.10
> 	      ns3.google.com                   1 day 12 hr 37  ip   	216.239.36.10
> 	      ns4.google.com                   1 day 12 hr 52  ip   	216.239.38.10
> ----------------------------
> answer www.google.com                   5 min           ip   	216.239.37.101
> ----------------------------
>>
>
> but use 192.168.79.2 instead of 192.168.233.2.
> then try with the dns servers listed in your /net/ndb.
>
> if the 192.168 dns server works but the two you
> have don't, then we can try to figure out how
> they got there.
>
> russ
>

Re: [9fans] Re: ip resolving

[Russ Cox]

how did those dns servers get there?
at least under my vmware, dns is served
by a vmware interface at .2, so i'd expect
to see

	dns=192.168.79.2

it's possible that windows vmware dns is different
from linux vmware dns, if you are running linux.

plan 9's ndb/dnsdebug is like unix's dig.
try this:

g% ndb/dnsdebug
> @192.168.233.2 www.google.com
1.1: sending to 192.168.233.2/192.168.233.2 www.google.com ip
1: rcvd OK from 192.168.233.2 (authoritative recurse can_recurse)
	Q:    www.google.com ip
	Ans:  www.google.com                   5 min           ip   	216.239.37.101
	Auth: google.com                       3 day 13 hr 21  ns   	ns1.google.com
	      google.com                       3 day 13 hr 21  ns   	ns2.google.com
	      google.com                       3 day 13 hr 21  ns   	ns3.google.com
	      google.com                       3 day 13 hr 21  ns   	ns4.google.com
	Hint: ns1.google.com                   1 day 12 hr 52  ip   	216.239.32.10
	      ns2.google.com                   1 day 12 hr 37  ip   	216.239.34.10
	      ns3.google.com                   1 day 12 hr 37  ip   	216.239.36.10
	      ns4.google.com                   1 day 12 hr 52  ip   	216.239.38.10
----------------------------
answer www.google.com                   5 min           ip   	216.239.37.101
----------------------------
>

but use 192.168.79.2 instead of 192.168.233.2.
then try with the dns servers listed in your /net/ndb.

if the 192.168 dns server works but the two you
have don't, then we can try to figure out how
they got there.

russ

[9fans] Re: ip resolving

[Nikolay Paskov]

Russ Cox writes:

> what does cat /net/ndb show you?
>

ip=192.168.79.128 ipmask=255.255.255.0 ipgw=192.168.79.2
    dns=132.187.1.1
    dns=132.187.1.3

Is that not enough ?