Bug 19110 - ppp connects, but I can't do anything with it
ppp connects, but I can't do anything with it
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ppp (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-14 13:50 EDT by Need Real Name
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-13 05:25:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-10-14 13:50:06 EDT
After having a fully working ppp connection using kppp (or the Gnome 
dialler) under Redhat 6.2, everything seems to have gone pear-shaped with 
my new 7.0 installation.

Basically, whatever dialler I am using, Kppp or the Gnome one, dials and 
connects correctly.  However, when I run Netscape or any other browsing 
component, such as the KDE browser, they refuse to connect, with host-
names unrecognised.  They seem to be ignoring the fact that I have an open 
connection with ppp.  I know my settings are correct, as they are exactly 
the same as those which worked under 6.2.
Comment 1 Alan Cox 2000-10-14 17:48:03 EDT
hostname unrecognized problems are almost certainly incorrect nameserver
configuration. You probably want to doublecheck your /etc/resolv.conf. It might
be a bug where pppd is now failing to negotiate names or something however.

Also try ping -n 195.92.249.252. If that works then the connection is made and
it is just the nameserver that is a problem.
Comment 2 Need Real Name 2000-10-19 03:58:53 EDT
Due to this, and other problems I was having (posted elsewhere) I've re-
installed 6.2 until more updates to 7.0 are available.  Therefore, I can't 
confirm my /etc/resolv.conf settings, nor the result of using ping -n 
195.92.249.252.  What I can say, however, is that I used exactly the same 
settings for kppp and the Gnome dialler on my re-installed 6.2 (i.e. the ones 
causing the problems on 7.0) and everything once more worked perfectly.

Could this be anything to do with the default gateway/route problem posted 
against the new Mandrake 7.1 release?  You see, I had the same problems with 
Mandrake, and their support pages suggested something about settings for the 
default gateway, and how the "route" command should note return "0.0" values, 
but does.  The symptoms of this defect were the same as posted here - i.e. ppp 
connects fine, but then you can't use it for anything.
Comment 3 Need Real Name 2000-10-22 14:13:27 EDT
When (if?) you upgrade to RH 7 again, and encounter the same problem - run
/sbin/ifconfig.
If You have two or more ppp-links, then edit chap-secrets or pap-secrets.
Actually - I had to run chmod u=r chap-secrets and chattr +i chap-secrets to
stop something (the RedHat dialer ???) to mess with the files; but I don't know
what I'm doing....
Comment 4 Nalin Dahyabhai 2000-10-24 15:45:30 EDT
WvDial edits the secrets file to add secrets which it has successfully
authenticated with.  I'm not sure how this would translate to multiple links
appearing, though.
Comment 5 Nandor Elud Fekete 2000-11-14 19:57:20 EST
I'm having the same problem (the pppd connects but I can not access anything on 
the internet). After some digging in I've found that the problem is that pppd 
doesn't sets the default gateway to the remote ppp server because it founds 
that you already have a gateway set up and it doesn't want to destroy it in the 
route table. You can actually see what kind of gateways you have by 
typing 'route' being root. If you want to delete your default gateway (you 
probably have one set up by the installation program - or by netconfig) take a 
look at your routing table and delete all the gateways you have.
It will be something like this:

route del default gw 192.168.1.254

After that make the ppp connection and look what happens. It should add a 
default gateway for interface ppp0 with the hostname or ipaddress of your isp-s 
server name.
I've also take a look at the source codes of pppd and found the routine called 
sifdefaultroute which meant to set the default route for the interface and I 
think it has a logical error in the first 'if' condition.
Comment 6 Need Real Name 2000-11-24 16:47:03 EST
OK...I've re-installed Redhat 7.0 and have tried all of the suggestions
that have so far been given.  I still haven't got a working ppp
connection, but here are the results anyway -


(1) Check ontents of /etc/resolv.conf :

/etc/resolv.conf is empty...


(2) Result of issuing PING -n 195.92.249.252 :

PING 195.92.249.252 (195.92.249.252) from 62.136.147.57 : 56(84) bytes of 
data.64 bytes from 195.92.249.252: icmp_seq=0 ttl=248 time=163.756 msec
64 bytes from 195.92.249.252: icmp_seq=1 ttl=248 time=159.973 msec
64 bytes from 195.92.249.252: icmp_seq=2 ttl=248 time=179.972 msec
64 bytes from 195.92.249.252: icmp_seq=3 ttl=248 time=139.973 msec
64 bytes from 195.92.249.252: icmp_seq=4 ttl=248 time=139.991 msec
64 bytes from 195.92.249.252: icmp_seq=5 ttl=248 time=149.967 msec
64 bytes from 195.92.249.252: icmp_seq=6 ttl=248 time=129.984 msec
64 bytes from 195.92.249.252: icmp_seq=7 ttl=248 time=139.986 msec
64 bytes from 195.92.249.252: icmp_seq=8 ttl=248 time=129.968 msec
64 bytes from 195.92.249.252: icmp_seq=9 ttl=248 time=119.975 msec
64 bytes from 195.92.249.252: icmp_seq=10 ttl=248 time=129.972 msec
64 bytes from 195.92.249.252: icmp_seq=11 ttl=248 time=119.979 msec
64 bytes from 195.92.249.252: icmp_seq=12 ttl=248 time=159.971 msec
64 bytes from 195.92.249.252: icmp_seq=13 ttl=248 time=139.983 msec
64 bytes from 195.92.249.252: icmp_seq=14 ttl=248 time=129.981 msec
64 bytes from 195.92.249.252: icmp_seq=15 ttl=248 time=129.972 msec
64 bytes from 195.92.249.252: icmp_seq=16 ttl=248 time=139.986 msec
64 bytes from 195.92.249.252: icmp_seq=17 ttl=248 time=129.972 msec
64 bytes from 195.92.249.252: icmp_seq=18 ttl=248 time=119.972 msec
64 bytes from 195.92.249.252: icmp_seq=19 ttl=248 time=129.966 msec
64 bytes from 195.92.249.252: icmp_seq=20 ttl=248 time=119.971 msec
64 bytes from 195.92.249.252: icmp_seq=21 ttl=248 time=129.966 msec
64 bytes from 195.92.249.252: icmp_seq=22 ttl=248 time=159.970 msec
64 bytes from 195.92.249.252: icmp_seq=23 ttl=248 time=139.966 msec
64 bytes from 195.92.249.252: icmp_seq=24 ttl=248 time=129.982 msec
64 bytes from 195.92.249.252: icmp_seq=25 ttl=248 time=139.965 msec
64 bytes from 195.92.249.252: icmp_seq=26 ttl=248 time=129.939 msec
64 bytes from 195.92.249.252: icmp_seq=27 ttl=248 time=129.938 msec
64 bytes from 195.92.249.252: icmp_seq=28 ttl=248 time=129.987 msec
64 bytes from 195.92.249.252: icmp_seq=29 ttl=248 time=139.736 msec
64 bytes from 195.92.249.252: icmp_seq=30 ttl=248 time=129.970 msec
64 bytes from 195.92.249.252: icmp_seq=31 ttl=248 time=139.974 msec
64 bytes from 195.92.249.252: icmp_seq=32 ttl=248 time=169.968 msec
64 bytes from 195.92.249.252: icmp_seq=33 ttl=248 time=149.966 msec
64 bytes from 195.92.249.252: icmp_seq=34 ttl=248 time=129.968 msec
64 bytes from 195.92.249.252: icmp_seq=35 ttl=248 time=129.973 msec
64 bytes from 195.92.249.252: icmp_seq=36 ttl=248 time=139.968 msec
64 bytes from 195.92.249.252: icmp_seq=37 ttl=248 time=129.988 msec
64 bytes from 195.92.249.252: icmp_seq=38 ttl=248 time=139.986 msec
64 bytes from 195.92.249.252: icmp_seq=39 ttl=248 time=129.969 msec
64 bytes from 195.92.249.252: icmp_seq=40 ttl=248 time=119.986 msec
64 bytes from 195.92.249.252: icmp_seq=41 ttl=248 time=129.950 msec
64 bytes from 195.92.249.252: icmp_seq=42 ttl=248 time=159.986 msec
64 bytes from 195.92.249.252: icmp_seq=43 ttl=248 time=139.960 msec
64 bytes from 195.92.249.252: icmp_seq=44 ttl=248 time=119.985 msec
64 bytes from 195.92.249.252: icmp_seq=45 ttl=248 time=139.932 msec
64 bytes from 195.92.249.252: icmp_seq=46 ttl=248 time=129.987 msec
64 bytes from 195.92.249.252: icmp_seq=47 ttl=248 time=139.985 msec
64 bytes from 195.92.249.252: icmp_seq=48 ttl=248 time=119.982 msec
64 bytes from 195.92.249.252: icmp_seq=49 ttl=248 time=129.979 msec
64 bytes from 195.92.249.252: icmp_seq=50 ttl=248 time=139.983 msec
64 bytes from 195.92.249.252: icmp_seq=51 ttl=248 time=139.975 msec
64 bytes from 195.92.249.252: icmp_seq=52 ttl=248 time=149.969 msec
64 bytes from 195.92.249.252: icmp_seq=53 ttl=248 time=139.970 msec
64 bytes from 195.92.249.252: icmp_seq=54 ttl=248 time=129.983 msec
64 bytes from 195.92.249.252: icmp_seq=55 ttl=248 time=139.993 msec
64 bytes from 195.92.249.252: icmp_seq=56 ttl=248 time=129.947 msec
 
--- 195.92.249.252 ping statistics ---
59 packets transmitted, 57 packets received, 3% packet loss
round-trip min/avg/max/mdev = 119.971/137.228/179.972/12.935 ms


(3) Result of running /sbin/route at start-up :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       *               255.0.0.0       U     0      0        0 lo      


(4) Result of running /sbin/route after connecting to ISP with ppp (via kppp) :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
195.92.65.107   *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         195.92.65.107   0.0.0.0         UG    0      0        0 ppp0    



I still cannot use my connection, I still get "Hostname unrecognized/not found".

Any ideas?

		
Comment 7 Nandor Elud Fekete 2000-11-25 10:55:12 EST
If you've got a 'Hostname unrecognized/not found' error message it is possible 
that you don't have set up at least one DNS server. When pppd is making a 
connection it's talkink with the ISP's ppp server and asks it for two DNS 
server addresses and when pppd gets them it will store in a 
file /etc/ppp/resolv.conf . I don't know how can I tell the system to use this 
file... it seems that it's not used at all. You should try to append these 
addresses to the /etc/resolv.conf manually and try again.
Comment 8 Thomas Woerner 2004-08-13 05:25:17 EDT
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora
Core and reopen it against the new version if it still occurs.

Closing as "not a bug" for now.

Note You need to log in before you can comment on or make changes to this bug.