* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [000804 15:16]:
> How odd. I have never heard of a modem so dumb it had to be told to
> pick up the phone before trying to dial. I guess it takes all kinds.
Guess what? I was wrong about the modem not going off-hook.
The problem was my modem would remember a previous 'NO CARRIER' so
subsequent attempts to go online would fail. ** If I turned the modem off,
and then on again, no problem; the first call of the day (if I shutdown
the night before, no problem. **
Solution: I removed the ABORT 'NO CARRIER' from my dial-up script!
I tried checking to see if geocrawler had another, more appropriate list,
and sure enough linux-ppp had a few hits about this problem. I've listed
one below if anyone's interested :-)
So here's my ppp-on script:
#!/bin/sh
/usr/sbin/pppd modem lock crtscts debug defaultroute \
asyncmap 0 user <login> \
connect /usr/local/bin/dial /dev/modem 115200
And here's my dial-up script:
#!/bin/sh
/usr/sbin/chat -v ABORT BUSY '' ATZ OK ATDT<ispphonenumber> CONNECT
Thanks all, for your help, and I hope this might help someone out there!
(now if I can get my ISP to respond to PAP authenticate-requests... ???
I guess it's just busy... ???)
---------------------from geocrawler archives linux-ppp-----------
Clifford Kite wrote:
>
> 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.
>
>
> On Fri, 4 Aug 2000, Richard Spencer wrote:
>
> > thanks tons! I just put ATH1 after my ATZ and before ATDT...
> > works like a charm!
>
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [000804 12:54]:
> > > >
> > > Get to know your modem. Set up minicom or just use
> > >
> > > cu -l <device name>
> > >
> > > see what it does when you type
> > >
> > > ATZ
> > >
> > > maybe it wants an innocent command that it can do without thinking to
> > > get it into the mood:
> > >
> > > ATH
> > >
> > > is usually a good one.
--
det spelar ingen roll
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
