This might look like a route problem... Running RH6.1, kernel 2.2.14, pppd 2.3.10-3 at this ISP. After some time getting restarted for dialup users (on a Cyclades mux), pppd starts acting weird: it connects as usual (no errors logged), but the dialupper can't "get out" of his box, i.e. no request whatsoever is replied, as if the route for him is not properly set up or the link were down. Note the user doesn't get any errors, just endlessly waits for a connection. As for now I haven't found any way out but rebooting. I checked the routes; everything looks ok. From the outer net, the machine is responding ok. Also, the pppd's on leased lines we also have on that machine are working fine (they do not get restarted that often); although sometimes, they keep running even if the modems are disconnected (as if not noticing the line being down). Strangely, pppd seems to work sometimes when started through strace, with kdebug 7.
Try updating to the latest version of the ppp package from Raw Hide (ftp://ftp.redhat.com/pub/rawhide/i386/RedHat/RPMS/)? This fixes some odd tty allocation/freeing problems we had earlier. Also please check that you have the "proxyarp" option set in the relevant options file for the connection (in /etc/ppp).
proxyarp was already there. I upgraded to 2.3.11 with no effect. I also upgraded SysVinit to last version, as init seemed not to restart the pppds properly. Furthermore, as soon as rebooted, the leased lines would not connect at all - error "peer is not authorized to use remote address a.b.c.d". What is this all about? All peers are configured with ipcp-accept-remote, the IPs are given from the server (the one issuing this error). I downgraded to 2.3.7, this error disappeared but the original one is still here. I checked the routes again, it seems they are not deleted when the dialupper hangs up. With only a few dialup lines, the last dialupper got dev ppp29 assigned...
Looked through it again. (Actually, that's about all I've been doing the past nights). Anyway, it looks like the route doesn't get deleted when ppp is disconnected. I ended up with multiple routes to the same IP. No wonder nothing was passing through the line... So I deleted it from ip-down, seems to work until now. Remains the problem with "peer is not authorized to use remote address a.b.c.d". Should I file a separate report for that? Thanks.
OK. Final comment. Sorry for the mess. Solved the "peer is not authorized" thing by adding noauth and allow-ip a.b.c.0/24 to the pppd options (wouldn't work without noauth, although previous versions did). Note that pap-secrets already had a line like '* * "" *'. Wonder if this is a bug. The route problem. Deleting the route manually from ip-down works ok. Again, wonder if this is a bug. I'll leave this as ASSIGNED. Please change it to RESOLVED if this is the way pppd is meant to work.
The route should automatically be removed by the kernel when the interface goes down -- I'm not sure but this sounds like a server-specific problem because I haven't heard about this from any other setups (not even my own dialup setup at home). I'll see if we can get the default ip-down script to remove the route, but it'll be tricky if there are aliased interfaces. Errors having to do with authorization are normal -- newer versions of pppd require the peer to authenticate itself if any other interfaces are present on the machine, under the assumption that the machine will therefore route for its peer. If your peers (the clients) don't authenticate, "noauth" is now required.
I have just upgraded to RedHat 6.2 and am having very similar problems with PPP suddenly. I am not sure if it is exactly the same, but what happens is I make a ppp connection and for a bit the connection works, but then the connection sort of dies - no errors or disconnections, and the rp3 monitor window shows packets coming in, but nothing goes out. I disconnect and reconnect sometimes with luck, sometimes without. I have ppp-2.3.11-4. Thanks.
We have the same problem on oyur RedHat 7.0 system with ppp-2.3.11-7 installed and with all current updates proxyarp otpion is turned on. For some time everything works OK, ppp interfaces going up and down and the corresponding routing table entires added or deleted... But from time to time for some odd reason the ppp interfaces stops closing and the routes from kernel routing table are not deleted anymore. This cause clients who got the IP which has multiple instances in routing table stop working. Everything returns to normal opertaion after clearing multiple entires in routing table by hand or after reboot. Here is the normal routing table sample: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ppp1.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp0 ppp7.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp6 ppp6.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp5 ppp3.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp2 ppp5.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp4 ... Each ppp interface has its own IP address And here is how table looks like when something gets wrong: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ppp1.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp0 ppp7.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp6 ppp6.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp5 ppp5.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp4 ppp5.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp3 ppp5.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp2 ppp3.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp1 ppp3.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp7 ppp3.dialup-2.d * 255.255.255.255 UH 0 0 0 ppp8 Differnet ppp interfaces has the same IP's. Moreover, pppd thinks that this IP is free and can give it out to client....
I want to add some additional information to what dusha wrote - there the problem is that pppd process exited but the pppx interface it created and the routing table entry for that interface is still alive! Our script checks that the pppd process exited and thinks that it's OK to reassign that IP, but if fact it is not OK since there is still a routing entry for that IP. It should be possible to kill the stale entry in ip-up.local, but that would only be treating symptoms, not the problem.
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.