Dial-up ISP DNS problems...HELP

Hey! I am new to linux...very new,so help me plz. My name is Rohan.

I am in India and my ISP is Reliance.Well after a long hog through
net-help pages, i finally setup the pppd connection (thanks to "How to
hook up PPP in Linux" by W.G. Unruh)...
but well i cannot access sites by their NAMES.
Though I did PING the ISP server and got a response so my connections
fine i hope.I directed the output of pppd to ppplog and lifted the DNS
IPs from there...but they dont work - i get an unkown host message.


Grateful if you could help me...thanks


Here's some of the ppplog file: (i put ####=where i lifted the DNS
from)


Jul 2 03:20:36 localhost pppd[4183]: pppd 2.4.1 started by root, uid
0
Jul 2 03:20:37 localhost pppd[4183]: Serial connection established.
Jul 2 03:20:37 localhost pppd[4183]: using channel 12
Jul 2 03:20:37 localhost pppd[4183]: Using interface ppp0
Jul 2 03:20:37 localhost pppd[4183]: Connect: ppp0 <-->
/dev/input/ttyACM0
Jul 2 03:20:38 localhost pppd[4183]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0xeee3b33f> <pcomp> <accomp>]
Jul 2 03:20:41 localhost pppd[4183]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0xeee3b33f> <pcomp> <accomp>]
Jul 2 03:20:42 localhost pppd[4183]: rcvd [LCP ConfReq id=0x1 <mru
1514> <asyncmap 0x0> <auth pap> <magic 0xc7ba836d> <pcomp> <accomp>]
Jul 2 03:20:42 localhost pppd[4183]: sent [LCP ConfAck id=0x1 <mru
1514> <asyncmap 0x0> <auth pap> <magic 0xc7ba836d> <pcomp> <accomp>]
Jul 2 03:20:42 localhost pppd[4183]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0xeee3b33f> <pcomp> <accomp>]
Jul 2 03:20:42 localhost pppd[4183]: sent [PAP AuthReq id=0x1
user=<hidden> password=<hidden>]
Jul 2 03:20:42 localhost pppd[4183]: rcvd [LCP ConfAck id=0x1
<asyncmap 0x0> <magic 0xeee3b33f> <pcomp> <accomp>]
Jul 2 03:20:43 localhost pppd[4183]: rcvd [PAP AuthAck id=0x1 ""]
Jul 2 03:20:43 localhost pppd[4183]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x1 <deflate

15> <deflate(old#) 15> <bsd v1 15>]
Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfReq id=0x2
<compress VJ 0f 00> <addr 97.236.2.16>]
Jul 2 03:20:43 localhost pppd[4183]: sent [IPCP ConfAck id=0x2
<compress VJ 0f 00> <addr 97.236.2.16>]


####### Here's the DNS


Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfNak id=0x1 <addr
220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
202.138.96.2>]
Jul 2 03:20:43 localhost pppd[4183]: sent [IPCP ConfReq id=0x2 <addr
220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
202.138.96.2>]
Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfRej id=0x1 <deflate

15> <deflate(old#) 15> <bsd v1 15>]
Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x2]
Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfAck id=0x2 <addr
220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
202.138.96.2>]


##### The DNS, IP.


Jul 2 03:20:43 localhost pppd[4183]: local IP address 220.226.56.170
Jul 2 03:20:43 localhost pppd[4183]: remote IP address 97.236.2.16
Jul 2 03:20:43 localhost pppd[4183]: primary DNS address
202.138.103.100
Jul 2 03:20:43 localhost pppd[4183]: secondary DNS address
202.138.96.2


##### And the rest of it (greek to me :-) )


Jul 2 03:20:43 localhost pppd[4183]: Script /etc/ppp/ip-up started
(pid 4213)
Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfNak id=0x2 < 12 06
00 00 00 01>]
Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x3]
Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x3 < 12 06
00 00 00 01>]
Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x4]
Jul 2 03:20:44 localhost pppd[4183]: Script /etc/ppp/ip-up finished
(pid 4213), status = 0x0
Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x4 < 12 06
00 00 00 01>]
Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x5]
Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x5 < 12 06
00 00 00 01>]
Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x6]
Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x6 < 12 06
00 00 00 01>]
Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x7]
Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfRej id=0x7 < 12 06
00 00 00 01>]
Jul 2 03:20:44 localhost pppd[4183]: Received bad configure-nak/rej:
12 06 00 00 00 01
Jul 2 03:20:47 localhost pppd[4183]: sent [CCP ConfReq id=0x7]
Jul 2 03:20:47 localhost pppd[4183]: rcvd [LCP ProtRej id=0x3 80 fd 01

07 00 04]
Jul 2 03:20:53 localhost pppd[4183]: rcvd [CCP ConfReq id=0x4 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:20:56 localhost pppd[4183]: rcvd [CCP ConfReq id=0x5 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:20:59 localhost pppd[4183]: rcvd [CCP ConfReq id=0x6 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:02 localhost pppd[4183]: rcvd [CCP ConfReq id=0x7 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:05 localhost pppd[4183]: rcvd [CCP ConfReq id=0x8 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:08 localhost pppd[4183]: rcvd [CCP ConfReq id=0x9 < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:11 localhost pppd[4183]: rcvd [CCP ConfReq id=0xa < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:14 localhost pppd[4183]: rcvd [CCP ConfReq id=0xb < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:17 localhost pppd[4183]: rcvd [CCP ConfReq id=0xc < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:21:20 localhost pppd[4183]: rcvd [CCP ConfReq id=0xd < 12 06
00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]
Jul 2 03:25:29 localhost pppd[4183]: Terminating on signal 15.
Jul 2 03:25:29 localhost pppd[4183]: Script /etc/ppp/ip-down started
(pid 4249)
Jul 2 03:25:29 localhost pppd[4183]: sent [LCP TermReq id=0x2 "User
request"]
Jul 2 03:25:29 localhost pppd[4183]: Script /etc/ppp/ip-down finished
(pid 4249), status = 0x0
Jul 2 03:25:29 localhost pppd[4183]: rcvd [LCP TermAck id=0x2]
Jul 2 03:25:29 localhost pppd[4183]: Connection terminated.
Jul 2 03:25:29 localhost pppd[4183]: Connect time 4.9 minutes.
Jul 2 03:25:29 localhost pppd[4183]: Sent 9655 bytes, received 7992
bytes.
Jul 2 03:25:29 localhost pppd[4183]: Serial link disconnected.
Jul 2 03:25:30 localhost pppd[4183]: Exit.

(E-Mail Removed) wrote:
> Hey! I am new to linux...very new,so help me plz. My name is Rohan.

> I am in India and my ISP is Reliance.Well after a long hog through
> net-help pages, i finally setup the pppd connection (thanks to "How to
> hook up PPP in Linux" by W.G. Unruh)...
> but well i cannot access sites by their NAMES.
> Though I did PING the ISP server and got a response so my connections
> fine i hope.I directed the output of pppd to ppplog and lifted the DNS
> IPs from there...but they dont work - i get an unkown host message.


> Grateful if you could help me...thanks


> Here's some of the ppplog file: (i put ####=where i lifted the DNS
> from)


> Jul 2 03:20:36 localhost pppd[4183]: pppd 2.4.1 started by root, uid
> 0
> Jul 2 03:20:37 localhost pppd[4183]: Serial connection established.
> Jul 2 03:20:37 localhost pppd[4183]: using channel 12
> Jul 2 03:20:37 localhost pppd[4183]: Using interface ppp0
> Jul 2 03:20:37 localhost pppd[4183]: Connect: ppp0 <-->
> /dev/input/ttyACM0

LCP negotiation and PAP authentication looked okay.
<snip>

> ####### Here's the DNS


> Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfNak id=0x1 <addr
> 220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
> 202.138.96.2>]
> Jul 2 03:20:43 localhost pppd[4183]: sent [IPCP ConfReq id=0x2 <addr
> 220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
> 202.138.96.2>]
> Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfRej id=0x1 <deflate
> 15> <deflate(old#) 15> <bsd v1 15>]

The ISP rejects all CCP algorithms requested by pppd, very common.

> Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x2]

So pppd proposes opening CCP without any compression.

> Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfAck id=0x2 <addr
> 220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
> 202.138.96.2>]

Just in case you don't know, DNS name server IP addresses need to be
configured this way in /etc/resolv.conf:

nameserver <IP address>

See man 5 resolver for other things that can be set in resolv.conf.
The existing resolv.conf may also have examples in it.

> ##### The DNS, IP.


> Jul 2 03:20:43 localhost pppd[4183]: local IP address 220.226.56.170
> Jul 2 03:20:43 localhost pppd[4183]: remote IP address 97.236.2.16
> Jul 2 03:20:43 localhost pppd[4183]: primary DNS address
> 202.138.103.100
> Jul 2 03:20:43 localhost pppd[4183]: secondary DNS address
> 202.138.96.2


> ##### And the rest of it (greek to me :-) )


> Jul 2 03:20:43 localhost pppd[4183]: Script /etc/ppp/ip-up started
> (pid 4213)
> Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfNak id=0x2 < 12 06
> 00 00 00 01>]
^^
> Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x3]
> Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x3 < 12 06
> 00 00 00 01>]
^^
This isn't good. The peer Naks the pppd requests to open CCP without any
compression and suggests that pppd send data using the MS-PPC (Microsoft
Point to Point Compression, aka MPPC) CCP (Compression Control Protocol)
algorithm in which compression and/or Microsoft Point to Point Encryption
(MPPE) can be requested. Technically both are optional but in practice
a request (or suggestion as above) to send MPPC compressed data must be
accepted by the peer in almost all cases. See RFC 2118.

The problem is that MPPC compression is patented and requires a license
so the standard pppd doesn't implement it, although it does implement
most of the variations of MPPE. The 01 tagged with "^^" at the end of
the ConfNak lines above shows the peer wants compression, so pppd cannot
accept the suggestion in the Conf-Naks. Not accepting it is almost sure
to cause the PPP link negotiations to fail or the link not to be viable.

Confusing? Yes, but the bottom line is that even though IP addresses
are negotiated it's very doubtful that the PPP link is viable (with
the probable exception of ICMP messages, notably ping echo-requests
and echo replies).

There may be sites where a pppd modified to use MPPC compression,
or a pppd patch for MPPC compression, is freely available. Just be
aware that, at least in the U.S., it's not legal to implement MPPC
compression without a license.

> Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x4]
> Jul 2 03:20:44 localhost pppd[4183]: Script /etc/ppp/ip-up finished
> (pid 4213), status = 0x0
> Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x4 < 12 06
> 00 00 00 01>]

Here pppd sends yet another request to open CCP without any compression
(in order to complete CCP negotiations). But the peer NAKs the request,
suggesting MPPC again. More of this nonsense follows.

> Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x5]
> Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x5 < 12 06
> 00 00 00 01>]
> Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x6]
> Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfNak id=0x6 < 12 06
> 00 00 00 01>]
> Jul 2 03:20:44 localhost pppd[4183]: sent [CCP ConfReq id=0x7]
> Jul 2 03:20:44 localhost pppd[4183]: rcvd [CCP ConfRej id=0x7 < 12 06
> 00 00 00 01>]
> Jul 2 03:20:44 localhost pppd[4183]: Received bad configure-nak/rej:
> 12 06 00 00 00 01

A ConfRej cannot also contain a suggestion for a particular CCP.

> Jul 2 03:20:47 localhost pppd[4183]: sent [CCP ConfReq id=0x7]
> Jul 2 03:20:47 localhost pppd[4183]: rcvd [LCP ProtRej id=0x3 80 fd 01
> 07 00 04]

Here the ISP rejects the CCP _protocol_ and then, inexplicably, continues
trying to negotiate with it. Note that pppd now stops CCP negotiation
since the peer rejected CCP.

> Jul 2 03:20:53 localhost pppd[4183]: rcvd [CCP ConfReq id=0x4 < 12 06
> 00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]

At this point the ISP should have stopped CCP negotiation but instead
it begins sending CCP requests for pppd to use either MPPC compression
or one of three varieties of STAC compression. STAC compression is also
patented and is not implemented in the standard pppd.

> Jul 2 03:20:56 localhost pppd[4183]: rcvd [CCP ConfReq id=0x5 < 12 06
> 00 00 00 01> < 11 05 00 01 04> < 11 05 00 01 03> < 11 06 00 01 01 01>]

Ect.
<snip>

These seem to be your choices: Change to another ISP or convince the
present ISP to not use CCP, find a PPP implementation that runs under
Linux and includes MPPC compression, find a MPPC compression patch for
pppd, or use an OS whose PPP implementation includes MPPC compression,
e.g., Microsoft. :/

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, (E-Mail Removed)
wrote:

>I am in India and my ISP is Reliance.

except we don't know who they are. Hang on:

>NNTP-Posting-Host: 220.226.19.109

[compton ~]$ host 220.226.19.109
Host not found.
[compton ~]$

They're also incompetent.

[compton ~]$ whois -h whois.apnic.net 220.226.19.109

netnum: 220.224.0.0 - 220.227.255.255
netname: RelianceInfocom
descr: Reliance Infocom Ltd.
country: IN

[compton ~]$

Ah, OK.

>but well i cannot access sites by their NAMES.

What is in /etc/resolv.conf ?

>I directed the output of pppd to ppplog and lifted the DNS IPs from
>there...but they dont work - i get an unkown host message.

>Jul 2 03:20:43 localhost pppd[4183]: rcvd [IPCP ConfNak id=0x1 <addr
>220.226.56.170> <compress VJ 0f 00> <ms-dns1 202.138.103.100> <ms-dns3
>202.138.96.2>]

[compton ~]$ host 202.138.103.100
100.103.138.202.IN-ADDR.ARPA domain name pointer ns2.rilinfo.net
[compton ~]$ host 202.138.96.2
2.96.138.202.IN-ADDR.ARPA domain name pointer ns1.rilinfo.net
[compton ~]$ host ns2.rilinfo.net 202.138.96.2
Using domain server 202.138.96.2:
ns2.rilinfo.net has address 202.138.103.100
[compton ~]$ host ns1rilinfo.net 202.138.103.100
Using domain server 202.138.103.100
ns1.rilinfo.net has address 202.138.96.2
[compton ~]$

Well, they work for me. Are those IP addresses in /etc/resolv.conf?
Read the man page for pppd, under the 'usepeerdns' option. pppd does
not change /etc/resolv.conf for you.

>Jul 2 03:20:43 localhost pppd[4183]: remote IP address 97.236.2.16

Stupid idiots. That address does NOT belong to them. The whole 97/8 is
reserved by IANA.

>##### And the rest of it (greek to me :-) )
>
>Jul 2 03:20:43 localhost pppd[4183]: Script /etc/ppp/ip-up started
>(pid 4213)

The script /etc/ppp/ip-up was started. See the SCRIPTS section of the
pppd man page.

>Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfNak id=0x2 < 12 06
>00 00 00 01>]
>Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x3]

The idiots are running a microsoft server, and it doesn't understand
why you don't want to use 'Microsoft PPC' data compression. Add the
option 'noccp' to your pppd command, or to /etc/ppp/options

The rest of your post looks normal, but what you show indicates a really
stupid ISP. Even the spam haven at VSNL isn't as incompetent.

I see you also multiposted this to "alt.comp.linux.isp" and 'alt.os.linux".
Please don't do that. You are just wasting bandwidth.

Old guy

Moe Trin <(E-Mail Removed)> wrote:

>>Jul 2 03:20:43 localhost pppd[4183]: remote IP address 97.236.2.16

> Stupid idiots. That address does NOT belong to them. The whole 97/8 is
> reserved by IANA.

Even so it really doesn't matter as far as the PPP link is concerned.

>>##### And the rest of it (greek to me :-) )
>>
>>Jul 2 03:20:43 localhost pppd[4183]: Script /etc/ppp/ip-up started
>>(pid 4213)

> The script /etc/ppp/ip-up was started. See the SCRIPTS section of the
> pppd man page.

>>Jul 2 03:20:43 localhost pppd[4183]: rcvd [CCP ConfNak id=0x2 < 12 06
>>00 00 00 01>]
>>Jul 2 03:20:43 localhost pppd[4183]: sent [CCP ConfReq id=0x3]

> The idiots are running a microsoft server, and it doesn't understand
> why you don't want to use 'Microsoft PPC' data compression. Add the
> option 'noccp' to your pppd command, or to /etc/ppp/options

Moe, while noccp may be worth a try it's not likely to work. Years of
participating in comp.protocols.ppp have convinced me that, despite
the wording of RFC 2118 [1], if the peer requests data sent to it be
compressed with MPPC then refusing to do so almost always results in
link termination by the peer or a non-viable link.

To the OP: I forgot to say that MPPC isn't implemented at all in pppd
2.4.1, you'll need 2.4.2 or higher to even get the MPPE part. And MPPC
compression is, of course, still not included in the higher versions.

[1] 2. Configuration Option Format

The CCP Configuration Option negotiates the use of MPPC on the
link. By default or ultimate disagreement, no compression is
used.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"

Hi Clifford - Happy 4th of July!

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Clifford Kite wrote:
>Moe Trin <(E-Mail Removed)> wrote:

>>>Jul 2 03:20:43 localhost pppd[4183]: remote IP address 97.236.2.16
>
>> Stupid idiots. That address does NOT belong to them. The whole 97/8 is
>> reserved by IANA.
>
>Even so it really doesn't matter as far as the PPP link is concerned.

That's true, but the whole setup shows that the ISP has no understanding
of the business. The reverse address lookup - that's a requirement by
the RIR as well as RFCs. This use of an address pulled out of mid air
says they don't understand the concept of addresses. Using an RFC1918
address (there's only 17.9 million of them) or even one of the special
use addresses in RFC3330 would avoid wasting one of their "real"
addresses, if that's what they're after. The thing is, they're not a
small ISP - the block the O/P was posting from is part of a /14 and the
name servers are in a different /19.

>Moe, while noccp may be worth a try it's not likely to work.

Yeah, I was mixing protocols there. My bad. I have to agree with
your suggestion to the O/P - get another ISP.

Now, I've got to find out what happened with my posting. The posting
date is about 14 hours after I hit the 'Post' key. Same for four other
posts made at about the same time. (Saturday was a bit hectic.)

Just back from Sunsite - Clifford, you may want to glance at

-rw-rw-r-- 1 gferg ldp 22266 Jun 28 09:46 Reliance-HOWTO

which is apparently connecting to Reliance using a special phone. While
the HOWTO doesn't have 'debug' information, the logfile shows what appears
to be a working connection. The setup looks normal.

Old guy