I think I've almost got pppd 2.3.x demand dial working, but I'm fuzzy on
the details.
I found the following on Deja News, and I'm wondering if someone can
clarify exactly where the call to /usr/sbin/pppd is supposed to go. I tried
sticking it in /etc/rd.c/rc.local but chat chokes on the '-f' option (I've
since put this in a seperate script so I can play with it.) Also, the
author used 192.168.1.2:192.168.1.1 for local and remote. Is this kosher?
These IPs belong to a LAN box and the gateway machine, respectively.
If I can figure this out and get it working reliably, I swear on the Linux
Encyclopedia and Dr. Linux that I will write a mini-HOWTO on pppd demand
dial. Really.
---- begin quoted Deja News article ----
>>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 quoted Deja News article ----
--
David Wollmann
[EMAIL PROTECTED]
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
