> For a standard pppd(8), specifying 'usepeerdns' in your /etc/ppp/options
> file is the usual way to get pppd(8) to store the ISP-supplied DNS
> details into /etc/resolv.conf.  There should be an easier way to ensure
> this happens via SuSE's graphical configuration utilities, though.  I'm
> not familiar with SuSE dial-up stuff, so perhaps Volker can fill in the
> details.

Is that a new feature that pppd can modify /etc/resolv.conf? On SuSE
this is handled by the ifup scripts, which first back up the existing
resolv.conf and then write a new one according to the settings obtained
from the ISP, with comments a la "this is auto-created, do not edit;
backup is in ...". The old resolv.conf is restored by the ifdown script.
Whenever I used it it worked perfectly, but I never used demand dial
(and don't use it much, having cable). The graphical config utility only
changes a variable read by the scripts.

It seems obvious that the previously posted ifconfig ppp0 and route -n
were taken at a time before the ISP responded with a client IP number
(some ISPs can be very slow - a minute or so). The 192. IP is used by
the demand dial feature and replaced by the ISP's IP when the connection
goes up. This makes me think that while debugging, the demand dial
should be turned off. The route -n did not show a route for eth0,
therefore I don't think the eth0 interface interferes. Andy, post the
output of route -n again after(!) the IP number of ppp0 has been changed
away from 192.xx.

I still don't see the root cause of the problem. Name resolution will
fail (your screen outputs were very informative Andy) until you can talk
to the ISP's name server. I.e. it will fail while the dial-up is in
waiting-for-demand state (though the name lookup should create the
demand). As the ISP supplies the name server IP via ppp I don't see a
margin for error there. Andy, after the ISP has given you your IP (check
with ifconfig ppp0, it must say something other than your usual 192.xx
for "local"), check whether a /etc/resolv.conf file has been created and
whether it's publicly readable. When the ISP finally shoves over the
local IP, this should also show in kinternet's ppp log. Perhaps the ISP
is faulty. Anyone ever asked which ISP?

Replies are the easiest to read when you only send one email Andy, even
if it takes some copying and pasting, as Nick says. Ruthlessley cut out
everything to which you aren't immediately replying, we've all seen it
before and it's then just noise distracting from the issue. <petpeeve>
Many people on this list seem to have a broken "cut" button, though
they should no better. <smiley> </petpeeve>

Volker

-- 
Volker Kuhlmann                 is possibly list0570 with the domain in header
http://volker.dnsalias.net/             Please do not CC list postings to me.

Reply via email to