Bug 10605 - pppd connects but the link is "dead"
pppd connects but the link is "dead"
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ppp (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-05 16:00 EDT by Cristi Prundeanu
Modified: 2007-04-18 12:26 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:00:51 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 Cristi Prundeanu 2000-04-05 16:00:50 EDT
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.
Comment 1 Nalin Dahyabhai 2000-04-06 16:18:59 EDT
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).
Comment 2 Cristi Prundeanu 2000-04-07 16:54:59 EDT
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...
Comment 3 Cristi Prundeanu 2000-04-08 20:13:59 EDT
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.
Comment 4 Cristi Prundeanu 2000-04-10 02:27:59 EDT
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.
Comment 5 Nalin Dahyabhai 2000-04-10 11:08:59 EDT
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.
Comment 6 dkaplan 2000-05-04 13:34:59 EDT
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.
Comment 7 Sergey D 2001-02-14 12:14:52 EST
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....

Comment 8 Aleksey Nogin 2001-02-14 13:52:00 EST
I want to add some additional information to what dusha@dnttm.ru 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.
Comment 9 Thomas Woerner 2004-08-13 05:00:51 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.