Bug 14859 - ppp0 manual redialing problems
Summary: ppp0 manual redialing problems
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-30 20:15 UTC by Bryan Reece
Modified: 2014-03-17 02:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-30 20:15:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Bryan Reece 2000-07-30 20:15:02 UTC
If a user issues `ifup ppp0' while the link is already up, the script saya
 ppp0 already up, initiating redial
and starts the advertised redial.  Subsequent `ifdown ppp0' commands fail
due to the absence of /var/run/pppwatch-ppp0.pid, and manual intervention
is required.

Redialing doesn't drop the line for long, so the first redial attempt gets
the `If you'd like to make a call, please hang up and try again' that the
local switch sends if you stay off-hook after the distant party hangs up.

Attempting to force a second redial manually (another `ifup ppp0' shortly
after the failed call attempt) seems to result in dueling chats: 
one chat sends a dial command, then the second sends a dial command that
aborts the first dial, causing someone to see `NO CARRIER' and retry ad
nauseam.

Comment 1 Bill Nottingham 2000-08-07 05:24:49 UTC
This has since been fixed; subsequent ppp-watch calls do
not kill the first ppp-watch's lock file.


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