PPP Prob - LCP: timeout sending Config-requests

PPP Prob - LCP: timeout sending Config-requests

Post by Jaym » Mon, 27 Jul 1998 04:00:00



Thanks for reading

When trying to make a ppp connection my username, password, and the command
for ppp goes through ok.  I get hosed with a messaging saying LCP: timeout
sending Config-Requests
Here is a some of /var/log/messages with the offending line.

......
.......
Jul 26 07:57:44 localhost chat[483]: ^M
Jul 26 07:57:44 localhost chat[483]: cs237>> -- got it
Jul 26 07:57:44 localhost chat[483]: send (ppp^M)
Jul 26 07:57:44 localhost pppd[482]: Serial connection established.
Jul 26 07:57:45 localhost pppd[482]: Using interface ppp0
Jul 26 07:57:45 localhost pppd[482]: Connect: ppp0 <--> /dev/cua0
Jul 26 07:58:20 localhost pppd[482]: LCP: timeout sending Config-Requests
Jul 26 07:58:20 localhost pppd[482]: Connection terminated.
Jul 26 07:58:20 localhost pppd[482]: Exit.
Jul 26 07:59:43 localhost kernel: PPP: ppp line discipline successfully
unregistered

Any Ideas ???

Thanks

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Tom Yan » Mon, 27 Jul 1998 04:00:00



> Thanks for reading

> When trying to make a ppp connection my username, password, and the command
> for ppp goes through ok.  I get hosed with a messaging saying LCP: timeout
> sending Config-Requests
> Here is a some of /var/log/messages with the offending line.

> ......
> .......
> Jul 26 07:57:44 localhost chat[483]: ^M
> Jul 26 07:57:44 localhost chat[483]: cs237>> -- got it
> Jul 26 07:57:44 localhost chat[483]: send (ppp^M)
> Jul 26 07:57:44 localhost pppd[482]: Serial connection established.
> Jul 26 07:57:45 localhost pppd[482]: Using interface ppp0
> Jul 26 07:57:45 localhost pppd[482]: Connect: ppp0 <--> /dev/cua0
> Jul 26 07:58:20 localhost pppd[482]: LCP: timeout sending Config-Requests
> Jul 26 07:58:20 localhost pppd[482]: Connection terminated.
> Jul 26 07:58:20 localhost pppd[482]: Exit.
> Jul 26 07:59:43 localhost kernel: PPP: ppp line discipline successfully
> unregistered

> Any Ideas ???

> Thanks

                                                -H.P. Lovecraft

Hi, I have the same problem!

My IPS updated its dial-in, I can get connected with Win95 but
not from within my Linex box!  They told me they are using CHAP authentication,
but I've never be able to get in even after I've tried the PAP/CHAP in HOWTO...

Please help,

Jul 26 16:38:39 playgod chat[8428]: ATH0^M^M
Jul 26 16:38:39 playgod chat[8428]: OK -- got it
Jul 26 16:38:39 playgod chat[8428]: send (ATDT4020061^M)
Jul 26 16:38:39 playgod chat[8428]: expect (CONNECT)
Jul 26 16:38:39 playgod chat[8428]: ^M
Jul 26 16:38:59 playgod chat[8428]: ATDT4020061^M^M
Jul 26 16:38:59 playgod chat[8428]: CONNECT -- got it
Jul 26 16:38:59 playgod chat[8428]: send (^M)
Jul 26 16:38:59 playgod pppd[8427]: Serial connection established.
Jul 26 16:39:00 playgod pppd[8427]: Using interface ppp0
Jul 26 16:39:00 playgod pppd[8427]: Connect: ppp0 <--> /dev/cua0
Jul 26 16:39:30 playgod pppd[8427]: LCP: timeout sending Config-Requests
Jul 26 16:39:30 playgod pppd[8427]: Connection terminated.
Jul 26 16:39:30 playgod pppd[8427]: Receive serial link is not 8-bit clean:
Jul 26 16:39:30 playgod pppd[8427]: Problem: all had bit 7 set to 0
Jul 26 16:39:30 playgod pppd[8427]: Exit.

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Bobby D. Bryan » Tue, 28 Jul 1998 04:00:00



> Jul 26 07:57:44 localhost pppd[482]: Serial connection established.
> Jul 26 07:57:45 localhost pppd[482]: Using interface ppp0
> Jul 26 07:57:45 localhost pppd[482]: Connect: ppp0 <--> /dev/cua0
> Jul 26 07:58:20 localhost pppd[482]: LCP: timeout sending Config-Requests
> Jul 26 07:58:20 localhost pppd[482]: Connection terminated.
> Jul 26 07:58:20 localhost pppd[482]: Exit.

I've been fighting this off and on for months as well.  In my case the timeout
is from "ICPC" rather than "LPC", but otherwise everything is the same.

Browsing the newsgroups seems to show that the problem is common, and Alta
Vista turns up mailing list archives that show the same question being asked
over a period of serveral years.  Tentative answers are occasionally given,
but none that I've tried have ever worked.  It sounds like it's a serious
problem for a small minority of users, so if any of you gurus stumble over
this post, please try to help us out on it and we'll try to repay the favor
indirectly by relaying your solution to the next crop of users who stumble
over it.

I have obtained slightly more information on my system by starting pppd with
both the "debug" and the "kdebug 1" options.  Two snippets of my
/var/log/messages follow, one for when I connect OK, and one for when I get
the timeout:

Good:

Jul 26 23:32:12 localhost pppd[3271]: Connect: ppp0 <--> /dev/cua1
Jul 26 23:32:12 localhost kernel: ppp_tty_ioctl: set xmit asyncmap ffffffff
Jul 26 23:32:12 localhost kernel: ppp_tty_ioctl: set flags to 10000
Jul 26 23:32:12 localhost kernel: ppp_tty_ioctl: set mru to 5dc
Jul 26 23:32:12 localhost kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Jul 26 23:32:12 localhost kernel: ppp_tty_ioctl: set flags to 10000
Jul 26 23:32:14 localhost kernel: ppp: successfully queued 22 bytes, flags =
f010000
Jul 26 23:32:15 localhost kernel: ppp: successfully queued 16 bytes, flags =
f010000
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set xmit asyncmap a0000
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set flags to f010003
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set mru to 5dc
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set flags to f010003
Jul 26 23:32:15 localhost kernel: ppp_tty_ioctl: set flags to f010043
Jul 26 23:32:15 localhost kernel: ppp: successfully queued 18 bytes, flags =
f010043
Jul 26 23:32:16 localhost kernel: ppp: successfully queued 12 bytes, flags =
f010043
Jul 26 23:32:16 localhost kernel: ppp: successfully queued 18 bytes, flags =
f010043
Jul 26 23:32:16 localhost kernel: ppp_tty_ioctl: set maxcid to 16
Jul 26 23:32:16 localhost kernel: ppp_tty_ioctl: set flags to f01004f
Jul 26 23:32:16 localhost kernel: ppp: channel ppp0 going up for IP packets!
Jul 26 23:32:16 localhost pppd[3271]: local  IP address 128.<censored>
Jul 26 23:32:16 localhost pppd[3271]: remote IP address 128.<censored>

Bad:

Jul 26 23:34:01 localhost pppd[3376]: Connect: ppp0 <--> /dev/cua1
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set xasyncmap
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set xmit asyncmap ffffffff
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set flags to 10000
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set mru to 5dc
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Jul 26 23:34:01 localhost kernel: ppp_tty_ioctl: set flags to 10000
Jul 26 23:34:03 localhost kernel: ppp: successfully queued 22 bytes, flags =
f010000
Jul 26 23:34:05 localhost kernel: ppp: successfully queued 16 bytes, flags =
f010000
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set xmit asyncmap a0000
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set flags to f010003
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set mru to 5dc
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set flags to f010003
Jul 26 23:34:05 localhost kernel: ppp_tty_ioctl: set flags to f010043
Jul 26 23:34:07 localhost kernel: ppp: frame with bad fcs, excess = faab
Jul 26 23:34:07 localhost kernel: ppp: successfully queued 18 bytes, flags =
f010043
Jul 26 23:34:25 localhost last message repeated 9 times
Jul 26 23:34:35 localhost pppd[3376]: IPCP: timeout sending Config-Requests

Two things stand out in this.  The, uh, second, is the penultimate line in the
"bad" log:

Jul 26 23:34:25 localhost last message repeated 9 times

If this means a *total* of 10 tries were made, I suspect it reflects the
following from the pppd man page:

       ipcp-max-configure n
              Set  the  maximum  number of IPCP configure-request
              transmissions to n (default 10).

I.e., it "timed out" because it made the default 10 tries and then gave up.
It would be easy enough to raise the retry count to a large number, but it is
not clear that that will solve the problem.  For instance, consider the
message two lines earlier in the "bad" log:

Jul 26 23:34:07 localhost kernel: ppp: frame with bad fcs, excess = faab

I haven't found out what this means yet.  Is this the ultimate source of the
problem, so that no number of retried config-requests will ever succeed?  I
get a few hits when searching for "frame with bad fcs" on Alta Vista, but
nothing useful yet.  [Some of the referenced pages are not coming up right now
because the servers are overloaded.  Also, if you speak Portuguese(?) or
Dutch(?), you may be able to help us by doing the Alta Vista search and
translating some of the archived mail messages in those languages.]

Since this message is getting kind of long, I'll pinch it off here and
followup with another post in the same thread on the "bad fcs" problem.
Meanwhile, perhaps some of the others of you who are getting the "timeout
sending Config-Requests" could start pppd with the "debug" and "kdebug 1"
options and try to trap a timeout, just to see whether we're all getting the
same "bad fcs" error, or whether we're getting different errors that happen to
have the same gross result.

Any tips or suggestions will be greatly appreciated.

Bobby Bryant
Austin, Texas

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Bobby D. Bryan » Tue, 28 Jul 1998 04:00:00



> Jul 26 23:34:07 localhost kernel: ppp: frame with bad fcs, excess = faab

> I haven't found out what this means yet.  Is this the ultimate source of the
> problem, so that no number of retried config-requests will ever succeed?  I
> get a few hits when searching for "frame with bad fcs" on Alta Vista, but
> nothing useful yet.  [Some of the referenced pages are not coming up right now
> because the servers are overloaded.  Also, if you speak Portuguese(?) or
> Dutch(?), you may be able to help us by doing the Alta Vista search and
> translating some of the archived mail messages in those languages.]

> Since this message is getting kind of long, I'll pinch it off here and
> followup with another post in the same thread on the "bad fcs" problem.
> Meanwhile, perhaps some of the others of you who are getting the "timeout
> sending Config-Requests" could start pppd with the "debug" and "kdebug 1"
> options and try to trap a timeout, just to see whether we're all getting the
> same "bad fcs" error, or whether we're getting different errors that happen to
> have the same gross result.

Ah, where was I.  Oh, yes: At
http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Jul_97/2005.html, Alta
Vista turns up a July'97 post by a certain Rob Riggs, which includes this juicy
tidbit:

"The symptom for FIFO overflows and flip buffer overflows on a PPP connection is
the same: dropped frames. If kdebug is set in pppd, they both cause the kernel to
report the same error, "ppp: frame with bad fcs". Unless you modify the kernel to
report on both conditions, you cannot tell which problem is culprit."

Just the facts, Ma'am.  It doesn't tell me a thing, but I report it on the chance
it will tip someone else off to the problem.

---
Another hit provides a couple of links to relevant archived messages.  I like
this one, from Brian Candler back in Jan'96
(http://www.uwsg.indiana.edu/hypermail/linux/big-linux/9601/0387.html):

"fcs = Frame Check Sequence, a checksum which PPP puts on the end of each
datagram. If you get errors only for certain users, the most likely cause is that
they have not got hardware handshaking (CTS/RTS) set up properly.

"You should check their modem configuration - USR Sportsters are a common problem
since their factory defaults (AT&F) are for software handshaking (XON/OFF).
Choose the defaults setting for hardware handshaking (look in the manual - AT&F1
or AT&F2 ?) then do AT&W to store the settings.

"It might also be their client software settings. How you do this depends on the
software. For example, Trumpet Winsock needs 'Hardware Handshake' checked in the
Setup screen; a Linux box needs 'crtscts' on the pppd command line."

This is what I was told to do once in the past, long before anyone mentioned
fcs.  It hasn't helped, but I used &F1 and he seems to be undecided between that
and &F2, so maybe I need to look that up and give it a try.  I do have a
USRobotics modem, and I remember that at least one other recent poster did as
well, so if that's what you have you may want to give this a try.  (Let me know
if you try it and it works, because I'll be posting a summary if we ever get to
the bottom of this.)

---
And here's a surprise from my very own department's Web server, a page dated
March'96 (http://www.cs.utexas.edu/users/kharker/linux-tm4000m/ppp.html,
excerpted for brevity):

"On my machine ... I have been experiencing a lot of trouble trying to setup a
reliable PPP connection over a V34 (28.8kb/s) modem. Symptoms were a lot of
"frame with bad fcs" and "frame tossed, reason = 4" messages on the console, and
poor overall throughput. Such problems can of course have many causes including
wrongly configured modems, bad cables, wrongly configured flow control and many
more. After eliminating all those potential reasons, I got help from the Usenet
community....

"Theodore pointed out that ``some other device driver (the IDE disk driver is a
really bad this way) keeps interrupts off too long, and by the time the serial
driver can get control, it's too late. If you can correlate the input overrun
messages to disk activity, then you should take a look at man page for the
"hdparm" program. In particular, take a look the "-u" option, which is documented
for solving the input overrun message, but which causes SEVERE DISK CORRUPTION
for some IDE interfaces. Read the man page, including the part of backing up your
hard disk first, and decide for yourself if you're willing to risk it.''

"I followed their advice by installing the hdparm-2.3 program, BACKING UP MY
WHOLE DISK and trying (as root) "hdparm -q -u 1 /dev/hda". It did make all the
PPP errors disappear. ... It has worked flawlessly since then, and I now enjoy
ftp transfers at 3+ kb/s."

This sounds like a last resort kind of thing for me.

---
That about does it for the Alta Vista hits that I can get to and read.  I
remembered that AV does crude translations, and looked at the Portuguese that
way, but no joy there.  There are still some hits in Dutch and (apparently) a
Slavic language that AV won't even try to translate.

The second item above looks most promising, so I'll study up on the &F2 and
report back on it later.  Meanwhile, I'd be most happy to hear from anyone else
that is working on the same problem.

Bobby Bryant
Austin, Texas

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Brian McCaule » Tue, 28 Jul 1998 04:00:00



> Jul 26 07:57:45 localhost pppd[482]: Connect: ppp0 <--> /dev/cua0
> Jul 26 07:58:20 localhost pppd[482]: LCP: timeout sending Config-Requests

All the interesting stuff happed in the missing 30 seconds.  

Quote:> Any Ideas ???

This question is posted just about every day.  I answer it in the
group at least once a week, as do several other people.

And the answer is "We cannot help you without a level debug log and
config info".

Please look in the group at the answers to similar (or indeed
identical) questions before you post.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Brian McCaule » Tue, 28 Jul 1998 04:00:00



Quote:> I have obtained slightly more information on my system by starting pppd with
> both the "debug" and the "kdebug 1" options.

The output from "kdebug" is, in some very rare cases, extreemly useful.
99% of the time it's just confusing.

The output of "debug" is *far* more valuable - but is not appearing in
your log.  Assuming you really do have "debug" in your PPP options
then check your syslogd.conf to see where your debug info is going.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/

 
 
 

PPP Prob - LCP: timeout sending Config-requests

Post by Bobby D. Bryan » Tue, 28 Jul 1998 04:00:00




> > I have obtained slightly more information on my system by starting pppd with
> > both the "debug" and the "kdebug 1" options.

> The output from "kdebug" is, in some very rare cases, extreemly useful.
> 99% of the time it's just confusing.

> The output of "debug" is *far* more valuable - but is not appearing in
> your log.  Assuming you really do have "debug" in your PPP options
> then check your syslogd.conf to see where your debug info is going.

I do get extra info in /var/log/messages when I enable debug, namely a transcript
of the login negotiations.  It just doesn't show in the snippet that I posted,
because all of that is over with before the section where the error occurs, and I
left it out for brevity.  (Everything goes the same up to the section I posted,
whether I get a good connection or not.)

Bobby Bryant
Austin, Texas

 
 
 

1. ppp prob (LCP:timeout sending config request)

well, here's the scoop, i changed isp's and now i cannot get a ppp
connection. what happens is i dial up, my modem connects, it requests
username and password, accepts my username and password, then it goes
through the frame sending bit and disconnects. the log error message is:
LCP: timeout sending config request. i increased the timeout but it still
does this, any clues?
--
                                             truly,
                                            s. daniel

"After the first glass, you see things as you wish they were. After the
second glass, you see things as they are not. Finally you see things as
they really are, and that is the most horrible thing in the
world." ----oscar wilde

2. dhcp , dns problem??

3. Rehat 4.0 ppp: "LCP: timeout sending Config-Requests"

4. ftpd internals

5. PPP - LCP timeout sending Config-Requests

6. Forcing routine to run at specified interval??

7. LCP: timeout sending Config-Requests (PPP problem?)

8. Avance Logic

9. ppp fails "LCP: timeout sending Config-Requests"

10. PPP error - LCP: timeout sending Config-Requests

11. (PPP) LCP: timeout sending Config-Requests

12. PPP problem : LCP :Timeout sending Config-Request