Bug 7509 - PPP dialing my ISP using PAP is not connecting.
PPP dialing my ISP using PAP is not connecting.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: ppp (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-02 10:15 EST by jshivley
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-24 21:59:24 EST
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 jshivley 1999-12-02 10:15:19 EST
I'm getting an error modeprobe: can't locate char-major-108 when trying to
login to my ISP using PAP.
Comment 1 jshivley 1999-12-02 10:29:59 EST
I'm only using Intel.
Comment 2 Michael K. Johnson 1999-12-02 15:59:59 EST
This is merely pppd's support for the 2.3 kernel -- the fact that you are
getting this message means that pppd will still work if you upgrade.
Comment 3 jshivley 1999-12-02 17:56:59 EST
Upgrade what?  I'm trying to log on and CAN'T.  I only thing I see that
prevents me from logging on is this message.  Could you please be a little more
explicit on a solution.  Maybe the question sould be "can pppd dial into a ISP
that uses PAP"  every thing looks like I can connect fine but I get dropped.
Then is see the message that I reported.
Comment 4 Michael K. Johnson 1999-12-03 09:52:59 EST
Sorry, I didn't notice the part that it wasn't working.  People often
complain about that message and I'm conditioned to seeing that and
explaining that it isn't a bug.  I promise you that message has absolutely
nothing to do with the fact that PPP isn't working for you.  It works
fine with PAP, I have tested it with quite a few providers using PAP
with no problems whatsoever.  So the problem is not PAP.

Make sure that you have the latest initscripts and ppp packages from
our errata.

If you have the latest and still have a problem, please try
echo 'DEBUG=yes' >> /etc/sysconfig/network-scripts/ifcfg-ppp0
and see if that helps.

(The upgrade I was referring to was the kernel -- if you chose to
use the 2.3.x kernels, without that message you are seeing, pppd
could not work.  The message is caused by pppd checking to see
whether a 2.3.x or 2.2.x kernel is there so that it can do the
right thing.  So you can ignore that part.)
Comment 5 jshivley 1999-12-03 12:05:59 EST
Could not find any update to 6.1 redhat for ppp and I edited the script file
and put in echo 'DEBUG=yes' and didn't see any messages that would help nor
using that option help my connection.  All I see is the following:

Serial connection established
Using interface ppp0
Connect: ppp0 <--> /dev/modem
Hangup <SIGHUP>
Modem hangup
Connection terminated
Exit

I assume since this is not a bug you can't assist any further.  Thanks for the
help.

js
Comment 6 Michael K. Johnson 1999-12-03 14:52:59 EST
The message is not a bug.  The SIGHUP is either a bug or the modem
hanging up.

There IS an update for ppp (ppp-2.3.10-3) for Red Hat Linux 6.1.
There is also an update for initscripts.  You want both of them.
Comment 7 jshivley 1999-12-03 16:19:59 EST
I have downloaded and installed the new pppd.  But I have not been able to find
the initscripts unless they are included int the RPM for pppd (ppp-2.3.10-3).
This still has not corrected the problem.  If I still need the initscripts.
Were can I find them?
Comment 8 Michael K. Johnson 1999-12-03 16:44:59 EST
The initscripts update is a security update.  It's on the web page
with everything else.
Comment 9 jshivley 1999-12-03 18:08:59 EST
Installed the update to the initscripts and it did not help.
Comment 10 Michael K. Johnson 1999-12-06 15:38:59 EST
One step at a time, I guess.  The next step is:
rpm -q initscripts
rpm -V initscripts
rpm -q ppp
rpm -V ppp
Comment 11 jshivley 1999-12-07 10:08:59 EST
rpm -q initscripts
initscripts-4.70-1

rpm -V initscripts
..5....T c/etc/inittab
S.5....T c/etc/sysconfig/network-scripts/ifcfg-lo

rpm -q ppp
ppp- 2.3.10-3

rpm -V ppp
..?..... c/etc/ppp/chap-secrets
S.5....T c/etc/ppp/options
S.?....T c/etc/ppp/pap-secrets
missing   /usr/doc/ppp-2.3.10/scripts/chatchat/README
missing   /usr/doc/ppp-2.3.10/scripts/chatchat/chatchat.c
Comment 12 Michael K. Johnson 1999-12-07 11:06:59 EST
Looking back over this, I see that you appear to have added
echo 'DEBUG=yes'
to the file /etc/sysconfig/network-scripts/ifcfg-ppp0.  That wasn't
what I suggested.  I suggested the command
echo 'DEBUG=yes' >> /etc/sysconfig/network-scripts/ifcfg-ppp0
which would add the line
DEBUG=yes
to the file /etc/sysconfig/network-scripts/ifcfg-ppp0

You might want to fix that and try again; we may get some useful
output that helps me figure out where that SIGHUP is coming from.

If that doesn't work, you can strace pppd by editing the file
/etc/sysconfig/network-scripts/ifup-ppp and changing
  exec /usr/sbin/pppd [...]
to
  exec strace -fo /tmp/ppp.$$.st /usr/sbin/pppd [...]
so that we can see precisely what pppd is doing.  You can create
a new attachment (see the link under the Summary line) that
includes the strace output. Note that "$$" in that line will be
replaced with a pid -- that's so that if you do this multiple
times, the strace output files won't overwrite each other.
Comment 13 jshivley 1999-12-07 13:41:59 EST
Here is what my ifcfg-ppp0 file looks like:

PERSIST=yes
DEFROUTE=yes
ONBOOT=no
INITSTRING=ATZ
MODEMPORT=/dev/modem
LINESPEED=115200
ESCAPECHARS=no
DEFABORT=yes
HARDFLOWCTL=yes
DEVICE=ppp0
PPPOPTIONS=
DEBUG=no
PAPNAME='jshivley@alltel.net'
REMIP=
IPADDR=
BOOTPROTO=none
MTU=
MRU=
DISCONNECTTIMEOUT=
RETRYTIMEOUT=
USERCTL=yes
DEBUG=yes

Here is the results I got from it:

Dec  7 12:12:25 localhost modprobe: can't locate module char-major-108
Dec  7 12:12:25 localhost pppd[1350]: pppd 2.3.10 started by root, uid 0
Dec  7 12:12:25 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at
115200
Dec  7 12:12:26 localhost chat[1360]: abort on (BUSY)
Dec  7 12:12:26 localhost chat[1360]: abort on (ERROR)
Dec  7 12:12:26 localhost chat[1360]: abort on (NO CARRIER)
Dec  7 12:12:26 localhost chat[1360]: abort on (NO DIALTONE)
Dec  7 12:12:26 localhost chat[1360]: abort on (Invalid Login)
Dec  7 12:12:26 localhost chat[1360]: abort on (Login incorrect)
Dec  7 12:12:26 localhost chat[1360]: send (ATZ^M)
Dec  7 12:12:26 localhost chat[1360]: expect (OK)
Dec  7 12:12:27 localhost chat[1360]: ATZ^M^M
Dec  7 12:12:27 localhost chat[1360]: OK
Dec  7 12:12:27 localhost chat[1360]:  -- got it
Dec  7 12:12:27 localhost chat[1360]: send (ATDT2205000^M)
Dec  7 12:12:27 localhost chat[1360]: expect (CONNECT)
Dec  7 12:12:27 localhost chat[1360]: ^M
Dec  7 12:12:56 localhost chat[1360]: ATDT2205000^M^M
Dec  7 12:12:56 localhost chat[1360]: CONNECT
Dec  7 12:12:56 localhost chat[1360]:  -- got it
Dec  7 12:12:56 localhost chat[1360]: send (^M)
Dec  7 12:12:56 localhost pppd[1350]: Serial connection established.
Dec  7 12:12:56 localhost pppd[1350]: Using interface ppp0
Dec  7 12:12:56 localhost pppd[1350]: Connect: ppp0 <--> /dev/modem
Dec  7 12:13:00 localhost pppd[1350]: Hangup (SIGHUP)
Dec  7 12:13:00 localhost pppd[1350]: Modem hangup
Dec  7 12:13:00 localhost pppd[1350]: Connection terminated.
Dec  7 12:13:01 localhost pppd[1350]: Exit.
Dec  7 12:13:01 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at
115200
Dec  7 12:13:01 localhost modprobe: can't locate module char-major-108
Dec  7 12:13:01 localhost pppd[1361]: pppd 2.3.10 started by root, uid 0
Dec  7 12:13:02 localhost chat[1371]: abort on (BUSY)
Dec  7 12:13:02 localhost chat[1371]: abort on (ERROR)
Dec  7 12:13:02 localhost chat[1371]: abort on (NO CARRIER)
Dec  7 12:13:02 localhost chat[1371]: abort on (NO DIALTONE)
Dec  7 12:13:02 localhost chat[1371]: abort on (Invalid Login)
Dec  7 12:13:02 localhost chat[1371]: abort on (Login incorrect)
Dec  7 12:13:02 localhost chat[1371]: send (ATZ^M)
Dec  7 12:13:02 localhost chat[1371]: expect (OK)
Dec  7 12:13:02 localhost chat[1371]: ^M
Dec  7 12:13:02 localhost chat[1371]: NO CARRIER
Dec  7 12:13:02 localhost chat[1371]:  -- failed
Dec  7 12:13:02 localhost chat[1371]: Failed (NO CARRIER)
Dec  7 12:13:02 localhost pppd[1361]: Connect script failed
Dec  7 12:13:03 localhost pppd[1361]: Exit.
Dec  7 12:13:03 localhost modprobe: can't locate module char-major-108
Dec  7 12:13:03 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at
115200
Dec  7 12:13:03 localhost pppd[1372]: pppd 2.3.10 started by root, uid 0
Dec  7 12:13:04 localhost chat[1382]: abort on (BUSY)
Dec  7 12:13:04 localhost chat[1382]: abort on (ERROR)
Dec  7 12:13:04 localhost chat[1382]: abort on (NO CARRIER)
Dec  7 12:13:04 localhost chat[1382]: abort on (NO DIALTONE)
Dec  7 12:13:04 localhost chat[1382]: abort on (Invalid Login)
Dec  7 12:13:04 localhost chat[1382]: abort on (Login incorrect)
Dec  7 12:13:04 localhost chat[1382]: send (ATZ^M)
Dec  7 12:13:04 localhost chat[1382]: expect (OK)
Dec  7 12:13:05 localhost chat[1382]: ATZ^M^M
Dec  7 12:13:05 localhost chat[1382]: OK
Dec  7 12:13:05 localhost chat[1382]:  -- got it
Dec  7 12:13:05 localhost chat[1382]: send (ATDT2205000^M)
Dec  7 12:13:05 localhost chat[1382]: expect (CONNECT)
Dec  7 12:13:05 localhost chat[1382]: ^M
Dec  7 12:13:25 localhost pppd[1372]: Terminating on signal 15.
Dec  7 12:13:25 localhost chat[1382]: SIGTERM
Dec  7 12:13:25 localhost pppd[1372]: Connect script failed
Dec  7 12:13:26 localhost pppd[1372]: Exit.

Here is the result of the strace;  It errored and did not connect but this is
what i edited and what I got.  I used strace with -fo and -f -o got same result.

Edited:

if [ -n "$WVDIALSECT" ] ; then
  exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \
    remotename $DEVICE ipparam $DEVICE \
    linkname $DEVICE \
    noauth \
    ${PPPOPTIONS} \
    connect "/usr/bin/wvdial --remotename $DEVICE --chat $WVDIALSECT"
else
  exec strace -f -o /tmp/ppp.$$.st /usr/sbin/pppd -detach $opts $MODEMPORT
$LINESPEED \
    remotename $DEVICE ipparam $DEVICE \
    linkname $DEVICE \
    noauth \
    ${PPPOPTIONS} \
    connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT"
fi


Result :

1446  execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "-
detach", "lock", "modem", "crtscts", "asyncmap", "00000000", "defaultroute", "us
epeerdns", "name", "jshivley@alltel.net", "debug", "/dev/modem", "115200", "remo
tename", "ppp0", "ipparam", "ppp0", "linkname", "ppp0", "noauth", "connect", "/u
sr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"], [/* 31 vars */])
= 0


I Hope this will help.

Thanks for all the help,

John S
Comment 14 Michael K. Johnson 1999-12-07 14:21:59 EST
I need the entire strace output, not the one execve line.  If you do not
want to submit the entire thing here as an attachment, please send it to
me via mail.  Without it, I can't help.
Comment 15 jshivley 1999-12-07 14:40:59 EST
When I ran "/sbin/ifup ppp0" with the trace, I got an error and did not connect
as I stated above.  I will try again but that is all I got.  I what I canged
correct.
Comment 16 jshivley 1999-12-07 16:34:59 EST
Let me try that last part again.  Is what I edited in the ifup-ppp correct?
The ppp0 session fails ans I don't dial or connect with that in there.
Comment 17 jshivley 1999-12-07 17:06:59 EST
The message I get is :
Failed to activate ppp0 with error 1
Comment 18 Michael K. Johnson 1999-12-08 11:49:59 EST
Your editing of ifup-ppp was correct.

Are you saying that the "1446" line was the ONLY line in the
/tmp/ppp.*.st file that was created?
Comment 19 David Lowe 1999-12-08 18:26:59 EST
I have been having exactly the same problem, with identical error messages. ppp
does seem to work fine when invoked directly using wvdial. When called through
rp3 (for example) the SIGHUP occurs, and it goes into an infinite loop of
dialing and hanging up. Likewise I am using the latest versions of ppp, rp3,
initscripts, etc.
Comment 20 Michael K. Johnson 1999-12-08 19:40:59 EST
lowe: can you please rpm -q ppp to make absolutely sure that you have
ppp-2.3.10-3?  This really is typical of ppp-2.3.10-1 and jshivley is
the first to report otherwise.

Assuming that you do have ppp-2.3.10-3, I need the same thing from
you as from jshivley in order to have a ghost of a chance of fixing
it: full strace output from pppd.  See the instructions here for how
to get that output.  Thanks!

------- Email From  David Lowe <lowe@het.brown.edu> 12/08/99 22:03 -------
Attached to Bug # 7509.
Comment 21 jshivley 1999-12-09 10:04:59 EST
What I'm saying is this, ever since I have put in the strace this is what
happens.

When I run ifup ppp0  ---  I get this --- Failed to activate ppp0 with error 1

The ony message I see in the message log is :

Dec  9 08:39:25 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at
115200

and I recieve the following in the trace file:

1446  execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "-
detach", "lock", "modem", "crtscts", "asyncmap", "00000000", "defaultroute", "us
epeerdns", "name", "jshivley@alltel.net", "debug", "/dev/modem", "115200", "remo
tename", "ppp0", "ipparam", "ppp0", "linkname", "ppp0", "noauth", "connect", "/u
sr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"], [/* 31 vars */])
= 0

1. Should I be seeing that error message when I run ifup?
2. Should I at least be able to dial and try to connect while using strace?  If
so I'm not.
3. Should I see only on trace log file per one dial attempt? not just one ifup
run.


------- Email From  "John Shivley" <jshivley@alltel.net> 12/09/99 11:27 -------
Attached to Bug # 7509.
Comment 22 Michael K. Johnson 1999-12-09 16:46:59 EST
1) that error indicates:
       1      An immediately fatal error of some  kind  occurred,
              such  as  an essential system call failing, or run-
              ning out of virtual memory.
   However, your strace doesn't show that.
2) strace should not change your ability to dial.  I'm rather
   confused -- is strace changing the behaviour of your system?
3) You should see one strace attempt per ifup run.
Comment 23 jshivley 1999-12-09 17:04:59 EST
I sent you a e-mail with attachment with a good strace.  I got it to dial and
connect with rp3.
Comment 24 jshivley 1999-12-11 13:17:59 EST
I still have the problem of the hang up.  I hope you didn't think I meant every
thing was fine from my last note.  I only got strace to work.  I hope you got
my attachment.  I have not heard from you and you usally reply back sooner.
Comment 25 Michael K. Johnson 1999-12-13 11:24:59 EST
I did not receive your email.
Comment 26 jshivley 1999-12-13 13:39:59 EST
Did you get it this time??  Sent about 1 hour ago..
Comment 27 Michael K. Johnson 1999-12-13 14:07:59 EST
Yes, thanks.  I'm a bit overloaded at the moment so it may be a few days
before I can look at it... :-(
Comment 28 jshivley 1999-12-28 12:57:59 EST
It has been 15 days and I was wondering what was up?  Thanks
Comment 29 jshivley 2000-01-18 09:39:59 EST
It has been over a month now.  What is the status?  Do you think it's a bug?
Please at least let me know if someone is working on it.  Thanks
Comment 30 seppo 2000-01-25 12:52:59 EST
I have similar problems! And it seems for me that there is lot of people having
...
Comment 31 Nalin Dahyabhai 2000-02-10 10:52:59 EST
Please attach your strace output to this bug report.  I've inherited most of the
PPP-related bugs and have been digging out from under a large pile of bugs for a
couple of weeks now, and I'm just now getting to this one.

Just to be sure, please verify that you have a line in /etc/ppp/pap-secrets of
the form:
jshivley@alltel.net	ppp0	somepassword
Comment 32 Nalin Dahyabhai 2000-02-10 11:48:59 EST
Okay, I've just looked at the strace you'd already sent to bugzilla, and it
looks like the modifications made to ifup-ppp are causing part of the problem
with tracing.  The quoting rules for the "connect" argument bing passed to pppd
are causing pppd to exit immediately.  The only way that will work is if you
create a short script (for example, /etc/sysconfig/network-scripts/call-ppp0)
that just runs a single command:
/usr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0

And modify the line in ifup-ppp that reads:
connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT"
to instead read:
connect "/etc/sysconfig/network-scripts/call-ppp0"

If you've had success invoking pppd with wvdial, I'd suggest updating both rp3
and wvdial from Raw Hide to see if they make a difference.  Until the latest
releases, rp3 would use libraries from a modified wvdial, but the regular wvdial
binary called by rp3 didn't have the correct patches applied.

I'm a bit concerned about the section of the log that looks like this:
668   ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENOSYS (Function not implemented)
668   ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENOSYS (Function not implemented)
668   ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENODEV (No such device)
You're still running the kernel we ship, right?  This looks like a failure
getting information about local interfaces, and a strace on my test machine
succeeds here.
Comment 33 David Lowe 2000-02-11 21:33:59 EST
I have attached a new strace with the most recent versions of rp3-1.0.7-2,
ppp-2.3.11-3, wvdial-1.41-2, initscripts-4.89-1

Also I created a /dev/ppp node which was missing from my system, following
command explained in README.linux in the ppp source. This seems to have fixed
the "Function not implemented" error, but not the modem hangup.

In case it is not clear from the previous messages, this problem occurs with
other X-based dialer programs (kppp, xisp,...).
Comment 34 David Lowe 2000-02-25 08:44:59 EST
It seems I have managed to accidentally fix this bug on my machine. The changes
I made had nothing obvious to do with ppp or rp3, so its rather puzzling
everything should suddenly start working. Are others still having this problem?
Comment 35 Nalin Dahyabhai 2000-02-29 12:23:59 EST
I'm surprised that you were even able to open /dev/ppp while running a 2.2
kernel -- the test for the presence of that device is only in there for support
for the new scheme used in 2.3 kernels, and if the check fails pppd falls back
to doing things the way the 2.2 kernel expects it to.

From looking at the strace log, it looks like the /etc/ppp/pap-secrets file
was empty, and pppd was therefore failing to authenticate via PAP.
Comment 36 Kolar, Petr 2000-09-26 08:48:13 EDT
I had the same problem (SIGHUP just after connecting) with
a machine of my customer. After many hours of work I realized
that the bug disappeared after removing $LINESPEED parameter
from the last line

  exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \

in /etc/sysconfig/network-scripts/ifup-ppp. Then it has been
happy working for half a year, but the bug has returned 14 days 
ago. :-(

If I can remember the computer was a 486 machine, with 16550A
ports and some external Voice/Fax/Modem (Desk Porte?) and RH 6.1
with updates till March or April 2000. Also, there were no 
problems with the same hardware and Internet provider but when 
calling from another town.

Had somebody the same problem which would disappear after
upgrading to RH 6.2?

Now I want to try using chat -t parameter.
Comment 37 Stephen John Smoogen 2003-01-24 21:59:24 EST
Bug 7509 is being closed because most if not all problems were fixed by
upgrading to later versions of Red Hat Linux. The problem does not seem to be in
current releases of RHL.

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