On Tue, 16 Feb 1999, Wes Morriston wrote:
|Right after I posted the output in /var/log/messages to the list, I
|decided to try the chat script without the 'ABORT "NO CARRIER"' line.
|The problem disappeared completely.
|
|Here's what I think. The "NO CARRIER" returned by the modem after a
|previous disconnect stays in the pipeline and gets recovered by the chat
|script the next time a try to reconnect. That squares with something I
|just remembered - viz., that the first time in the morning that I try to
|connect I don't have this problem. I think the problem appears only
|after a previous disconnect.
Good! I think you are right. This is what I suspected I but wanted to
see an actual log before mentioning it. More below.
|Two questions. (1) Is there any real reason not to eliminate the 'ABORT
|"NO CARRIER"' line from my chat script? (2) What is the best way to
|flush the buffer completely when I disconnect?
No reason that the ABORT "NO CARRIER" shouldn't be omitted - except then it
won't abort, presumably.
This was a problem for someone else and he posted the answer he came up
with. I saved the post because the problem was so unique. He was having
trouble with demand dialing, and this his post in it's entirety:
---Begin Post-----------------------------------------------------------
>From [EMAIL PROTECTED] Tue Feb 16 20:24:11 1999
Date: 11 May 1998 21:08:50 -0500
From: Gregory Travis <[EMAIL PROTECTED]>
Newsgroups: comp.os.linux.networking
Subject: Re: ip masquerading and dial on demand (pppd 2.3.5)
In article <6j89q6$9p8$[EMAIL PROTECTED]>,
Kevin Martin <[EMAIL PROTECTED]> wrote:
>In article <6j85eg$pr4$[EMAIL PROTECTED]>, it says [EMAIL PROTECTED] wrote:
>>A couple of people have told me that IP Masquerade requires a
>>static address. Anybody know whether that's still true?
>
>The pppd man page for 2.3.4 says that demand dialing is "not recommended"
>if you'll be assigned a dynamic address. THAT makes it seem bloody useless
>to me... and I had such hopes for it when I first read about it here.
Here's what I did to FINALLY get demand-dialing to work under Red Hat 5.0
(kernel 2.0.33) using dynamic addresses.
My pppd line, executed at startup, is:
/usr/sbin/pppd -detach lock modem crtscts defaultroute
192.168.1.2:192.168.1.1 /dev/modem 115200 remotename ppp0
ipparam ppp0 demand nopersist idle 1200 ipcp-accept-remote
ipcp-accept-local
connect /usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-pp
(this is executed by RedHat's startup script - I configured all of the above
through the control panel giving most of the demand dial options seen in
the "additional arguments" window. I also set it to automatically
RESTART pppd if it exits)
Note several things that I found:
1. The "persist" option is buggy, at least in pppd 2.3.3. Hence
the explicit "nopersist" on the command-line and the
requirement to restart pppd if it exits.
2. You >should< flush the modem buffer prior to starting pppd. I
was trying to figure out why PPP/Chat would sometimes fail
right after starting. Turns out there was a stale "NO CARRIER"
in the tty buffer left over from the last time the modem line
was dropped. I wrote a little program to flush the buffer
and stuck the program in redhat's ppp script (see below).
It works really well now - we use ipfwadm at home for our other computers
and they spark up the line just fine.
------- Begin change to redhat ppp script
( /etc/sysconfig/network-scripts/ifup-ppp )
.
.
.
while : ; do
(logger -p daemon.info -t ifup-ppp \
"pppd started for $DEVICE on $MODEMPORT at $LINESPEED" &)&
> /var/run/ppp-$DEVICE.dev
+ /usr/local/bin/tcflush < $MODEMPORT
/usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \
remotename $DEVICE ipparam $DEVICE \
${PPPOPTIONS} \
connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT"
.
.
.
------ End change ("+" signifies added line)
------ Begin source to tcflush.c
( compile as cc -O2 tcflush.c -o /usr/local/bin/tcflush )
#include <termios.h>
#include <unistd.h>
main()
{
if(tcflush(0, TCIOFLUSH)) {
perror("tcflush");
}
exit(0);
}
------- End source
--- End Post -----------------------------------------------------------
Cheers
---
Clifford Kite Not a guru. (tm)
[EMAIL PROTECTED] Not even close.
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
