pppd connects and route set up, but cannot resolve

detly · 07-22-2005, 11:47 PM

Computer: NEC Versa M540 (laptop)
Modem: Intel Corp 8280 AC'97 Modem Controller (on /dev/ttySL0)
Distro: Debian GNU/Linux
Kernel: 2.6.8 (with mppe support)
pppd: 2.4.3
chat: 1.22

This is a follow-on from a previous problem:
http://www.linuxquestions.org/questi...hreadid=341151

Essentially, I can connect to my isp via ppp, I can ping, say, www.google.com as long as I use the IP address; but attempting to see anything by name fails, despite the nameservers seeming to be configured correctly. I use the same laptop to connect to the network at uni with no such problems (via eth0, not ppp0).

/etc/ppp/peers/isp-name:

Code:

# This optionfile was generated by pppconfig 2.3.10.
#
#
/dev/ttySL0
name <<username>>
remotename isp-name
ipparam isp-name
noauth
hide-password
connect "/usr/sbin/chat -v -t 180 -f /etc/chatscripts/isp-name"
debug
115200
defaultroute
# replacedefaultroute
noipdefault
user "<<username>>"
domain isp-name.com.au
usepeerdns

Connecting and authentication seem fine:

Output of plog -f after "pon isp-name":

Code:

Jul 23 11:51:13 localhost chat[4398]: CONNECT
Jul 23 11:51:13 localhost chat[4398]:  -- got it
Jul 23 11:51:13 localhost chat[4398]: send (\d)
Jul 23 11:51:14 localhost pppd[4397]: Serial connection established.
Jul 23 11:51:14 localhost pppd[4397]: using channel 1
Jul 23 11:51:14 localhost pppd[4397]: Using interface ppp0
Jul 23 11:51:14 localhost pppd[4397]: Connect: ppp0 <--> /dev/ttySL0
[...]
Jul 23 11:51:37 localhost pppd[4397]: PAP authentication succeeded
[...]
Jul 23 11:51:38 localhost pppd[4397]: Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
[...]
Jul 23 11:51:38 localhost pppd[4397]: Cannot determine ethernet address for proxy ARP
Jul 23 11:51:38 localhost pppd[4397]: local  IP address <<local-ip>>
Jul 23 11:51:38 localhost pppd[4397]: remote IP address <<remote-ip>>
Jul 23 11:51:38 localhost pppd[4397]: primary   DNS address <<dns-1>>
Jul 23 11:51:38 localhost pppd[4397]: secondary DNS address <<dns-2>>
Jul 23 11:51:38 localhost pppd[4397]: Script /etc/ppp/ip-up started (pid 4425)
Jul 23 11:51:39 localhost pppd[4397]: Script /etc/ppp/ip-up finished (pid 4425), status = 0x0

Debian doesn't like replacing the default route for some arcane reason, so:

Code:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<<remote-ip>>  0.0.0.0         255.255.255.255 UH    0      0        0 isp-name
# ip route add default via <<remote-ip>>
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<<remote-ip>>  0.0.0.0         255.255.255.255 UH    0      0        0 isp-name
0.0.0.0         <<remote-ip>>  0.0.0.0         UG    0      0        0 isp-name

Before adding default route:

Code:

$ ping 66.102.7.147
connect: Network is unreachable

After:

Code:

$ ping 66.102.7.147
PING 66.102.7.147 (66.102.7.147) 56(84) bytes of data.
64 bytes from 66.102.7.147: icmp_seq=1 ttl=244 time=2593 ms
[...]

Nameservers are replaced by pppd:

/etc/resolv.conf:

Code:

# cat /etc/resolv.conf
# resolv.conf created by pppconfig for isp-name

nameserver <<dns-1>>

nameserver <<dns-2>>

(I've verified that these are correct.)

But attempting to resolve the name doesn't work:

Code:

$ host www.google.com
;; connection timed out; no servers could be reached
$ host 66.102.7.147
;; connection timed out; no servers could be reached
$ ping www.google.com
ping: unknown host www.google.com

Some other notes:

1. "plog" shows nothing (new) during this process

2. Running "nscd -i" hosts does nothing

3. The only files in which the old nameserver (from my uni connection) appears are the backup files created by pppd

4. I cannot ping the nameservers, but I can't do that either on my desktop, which has no problems

I would very much appreciate some help on this. :)

TigerOC · 07-24-2005, 03:04 AM

Have you actually entered the dns addresses given by your isp in /etc/resolv.conf? If you haven't, do so.

cdealer · 07-24-2005, 04:44 AM

after doing all this try

#ifconfig eth0 up
#dhcpcd eth0

whats the output of #cat /etc/hosts and /etc/networks ?

detly · 08-04-2005, 09:24 PM

After connecting and adding gateway, but before anything else (note - "alice" is the laptop's name, "strnat" is a uni ftp server):

Code:

# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost alice

130.95.157.9 strnat.pd.uwa.edu.au

# The following lines are desirable for IPv6 capable hosts
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

There's no /etc/networks. If I try

Code:

#ifconfig eth0 up

Then /etc/hosts doesn't change at all, and neither does the resolution problem.

Code:

alice:~# dhcpcd eth0
bash: dhcpcd: command not found

Apparently the "dhcpcd" package conflicts with the one for "dhcp-client," which is installed.

primo · 08-05-2005, 02:14 AM

There must be an uncommented line in /etc/nsswitch.conf like this:
"hosts: files dns"

For the default route problem, run "ps auxw | grep pppd" to see how pppd is being called (sometimes, arguments to pppd override /etc/ppp/options)

Run "iptables -L -v -n" to see if you're blocking DNS requests and/or replies (ie, some paranoid firewall scripts accept DNS replies only from nameservers listed in /etc/resolv.conf at the time the script is run)

Quote:

4. I cannot ping the nameservers, but I can't do that either on my desktop, which has no problems

Try traceroute on these nameservers (one time with the -I option, and another without it) to see if some intermediate router is dropping ICMP's (-I option), and to see how many hops away are they (and which one is nearest you). Use the -n option on both to avoid name resolution)

Currently, I'm running a caching-nameserver on my box. I don't rely on my ISP's nameservers anymore. Bind just talks to the root servers on the Internet and caching makes it really fast

detly · 08-06-2005, 06:36 AM

Quote:

Run "iptables -L -v -n" to see if you're blocking DNS requests and/or replies (ie, some paranoid firewall scripts accept DNS replies only from nameservers listed in /etc/resolv.conf at the time the script is run)

Brilliant! It was an overzealous firewall problem. I intend to learn a little more about that when I have time...

But it's all fixed now. Thank you very much

Quote:

For the default route problem, run "ps auxw | grep pppd" to see how pppd is being called (sometimes, arguments to pppd override /etc/ppp/options)

This shows the call to be simply "/usr/sbin/pppd call isp-name". A link in the thread I referenced above seems to indicate it's a vagarity of the release of Debian I'm using (to ignore requests to set the default route), so I'll just set up a script in /etc/ppp/ip-up.d(.)

SureYouDo · 08-24-2005, 10:10 AM

Quote:

Originally posted by TigerOC
Have you actually entered the dns addresses given by your isp in /etc/resolv.conf? If you haven't, do so.

could you please clarify for me?

I have a similiar connection problem. With SuSE 9.3 recently installed on a new (Samsung 80GB) laptop (Dell Inspiron 8000 :Pent III, 848 MHz),
I had an error message about resolving. I have specified the dial-up service I use as per its user notes for Linux users in
the /etc/ppp/resolv.conf file.

When I looked at the contents of the /etc/resolv.conf file I found (and left unaltered) lines of what I guess is machine code.

I am able to establish a connection (pppd) with the remote dial-up server, but every attempt to open a URL fails.

By the way, at boot up, my dmesg reads that some problem with the IPv6 tables (are not matched ?) results in
"IPv6 disabled" in the boot process. Can you advise on whether this is a matter for concern and if so, how it can be
remedied?

Thanks.

TigerOC · 08-24-2005, 11:17 AM

Your isp should provide DNS addresses. These are then entered in /etc/resolv.conf. These allow domain name resolution. You can also list these in /etc/ppp/resolv.conf as well. The format is;
nameserver <dns_address>
ipv6 can be troublesome with some servers. If you continue to have problems with it then disable ipv6 as it is not mainstream yet.

SureYouDo · 08-24-2005, 11:26 AM

" Your isp should provide DNS addresses. These are then entered in /etc/resolv.conf. These allow domain name resolution. You can also list these in /etc/ppp/resolv.conf as well. The format is;
nameserver <dns_address> ... "

Thanks,

but that much (that about the /etc/ppp/resolv.conf file above) is already done; As for making the connection to the ISP's dial-up server, I'm able to do that.

My immediate difficulty is that once a dial-up connection is established (it continues without trouble, too.) I can't succeed in getting any
web sites to open up in the browser window. In each case, the error is "not found". These are well-established sites which are "found" regularly.

As for disabling the IPv6 routine, it is disabled automatically in the process, though that isn't by _my_ choice; the error message (read in the dmesg file) indicates some sort of incompatibility. What I was wondering is if this poses any security risks and whether I can enable the IPv6 process somehow?

By the way, these queries are made from a cybercafe since I don't yet have other working access to the web.

If I recall, the /etc/resolv.conf file is a binary file. It's _there_ (where, exactly? at the start of line one, separated from the original file contents by a new line?) that I put in this nameserver information?

That's the part that I'm unsure of and don't want to do incorrectly.

primo · 08-24-2005, 07:14 PM

Try adding "usepeerdns" to /etc/ppp/options and then try to connect.

What exactly contains your /etc/resolv.conf ?

SureYouDo · 08-27-2005, 11:10 AM

I think Tiger's reply was the solution to _that_ problem.
Now for the follow-up one : in reading the /var/log/warn file

(and this is after just a few successful internet connections),
I find scores of lines which read that

"all amavisd scans failed!"

That worries me. Should it? Is there a way to confirm prior to re-connection (I have avoided
reconnecting since reading the /var/log /warn file) that my virus scan programs :

are running properly?

and have not been corrupted?
I have looked for the "tripwire" program, apparently never installed, and not found it among the
available packages in my distribution (store-bought original SuSE 9.3) though the administrator's (print copy)
manual says it is a part of this distribution.

Any suggestions ?

Thanks again, Tiger.

SureYouDo · 08-27-2005, 11:52 AM

well, later that same day,

I see from some forum posts that adding tripwire after the
suspicious activity has occurred is like closing the gate after the
livestock have all wandered out.

You know what would have been _really_ nice of the programmers,
documentation writers to have done? To mention the existence and helpfulness of a tripwire-like program somewhere PROMINENTLY _BEFORE_ the user completes the install.

I did my install; then, a day or so later read about the importance of tripwire on about page 600-and-something of the administrator's manual.

I don't think it's entirely unreasonable to expect that new users may NOT read the entire admin manual before they begin an initial installation. IF such is a necessary precondition, then I think that THAT ought to be stated prominently somewhere the new user will see it before it's too late.

Perhaps it isn't a popular thing to say but, in my experience as a not-at-all-expert sometime user of slack-ware, Red Hat and, now, SuSE (with which I remain fairly favorably impressed despite a few minor problems), Linux distributions in general are neither very well nor very clearly documented. That's true, it seems to me, whether you turn to published manuals or the documentation contained on the installation software and provided by the distributors themselves.

Yes, people routinely turn to web forums for guidance and that's all well and good, but user's-documentation writers shouldn't expect that the existence of such forums means that their explanations need not be clear and thorough.

fhleung · 02-25-2008, 10:16 PM

For the dynamic IP (remote-ip) which assigned by ISP, how to add this entry to the kernel routing table?

Code:

# route add default via <<remote-ip>>

Anyone can kindly help please =)