Red Hat Bugzilla – Bug 134480
pppd cannot properly shut down after remote peer refused to authenticate itself
Last modified: 2007-11-30 17:10:50 EST
Description of problem:
pppd is set up to accept only CHAP/MS-CHAP authentication type, and
if remote side cannot authenticate itself using (MS)CHAP, it prints
the following (full session transcript is in Additional Information):
Oct 3 22:29:46 skynets pppoe-server: Session 23 created for
client 00:0d:61:a8:17:90 (192.168.4.32) on eth1 using Service-
Oct 3 22:29:46 skynets pppd: pppd 2.4.2 started by root, uid 0
Oct 3 22:29:46 skynets pppd: Using interface ppp5
Oct 3 22:29:46 skynets pppd: Connect: ppp5 <--> /dev/pts/49
Oct 3 22:29:48 skynets pppd: peer refused to authenticate:
Oct 3 22:29:48 skynets pppd: Connection terminated.
Oct 3 22:29:48 skynets pppoe-server: Sent PADT
Oct 3 22:29:48 skynets pppoe: read (asyncReadFromPPP):
Session 23: Input/output error
Oct 3 22:29:48 skynets pppd: Terminating on signal 15.
Oct 3 22:30:18 skynets last message repeated 242930 times
this excessive logging in accompanied with relevant CPU load.
Version-Release number of selected component (if applicable):
1. For example, in WinXP, uncheck MS-CHAP and CHAP fields and check
2. Try to connect to PPPoE server running at FC machine.
Please verify this with ppp and rp-pppoe from rawhide.
I'm not sure what is rawhide, but after I got ppp and rp-pppoe from
the issue disappeared, so I think the case is closed.