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.
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.
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.
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....
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.
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.
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?
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.
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.