[CLUE-Tech] mgetty and ppp troubles on linux dialin server
Jim Ockers
ockers at ockers.net
Tue Apr 20 00:08:50 MDT 2004
Hi Daniel,
I agree with your assessment. The AT&F or AT&F1 commands are intended to
set the modem back to the "factory" defaults so that all previous init
commands are discarded. The AT&W part writes the factory settings back
to NVRAM "just in case."
The modem barf should not be present in a modem that's been set back to
factory defaults - you should get a "CONNECT 9600" or similar message,
and then nothing (until you type some data in the remote terminal window).
I have a whole bunch of modems you could have for free but they are
in Canada so I'd have to ship it. Oh well..
Hope this helps,
Jim
daniel wrote:
>
> Hi Jim,
>
> I got to do this procedure this evening and here is what I found:
>
> for AT&F1S0=0&W
> see RING, typed ATA, normal modem squeeling, then quite a few lines of modem
> barf scroll accross the top 2 lines of minicom, though after about 30 seconds
> the modem hangs up with NO CARRIER. (client sees CONNECT 14400)
>
> for AT&FS0=0&W
> see RING, typed ATA, normal modem squeeling, same scrolling modem barf, 30
> seconds later hangs up NO CARRIER. (client again sees CONNECT 14400, then on
> the next line it sees "minicom 2.1")
>
> for AT&F2S0=0&W (decided to test all 3 inits)
> ERROR right away from my modem.
>
>
> So I guess it looks like my modem may not be functioning correctly. When
> trying to use the 14.4 to make a ppp connection to a dialup isp account I
> have, wvdial connects, authenticates, and the connection works for about 30
> seconds, then pppd dies with error 16 (link terminated by modem hangup) every
> time, so the oldie modem may just be ready for retirement. I'm going to buy a
> new modem tomorrow and go through these steps again to see what happens.
> Thanks for your time.
>
> -Daniel
>
> ---------- Original Message -----------
> From: ockers at ockers.net (Jim Ockers)
> To: daniel at alien2thisworld.net
> Sent: Sun, 18 Apr 2004 15:07:27 -0600 (MDT)
> Subject: Re: [CLUE-Tech] mgetty and ppp troubles on linux dialin server
>
> > Daniel:
> >
> > Your modem is never raising carrier. PPP never starts because your
> > 14.4 modem never raise carrier, so mgetty never thinks the line is
> > connected. (Because the line is never connected.)
> >
> > When mgetty is waiting for a CONNECT message from the modem, please understand
> > that your modem generates a CONNECT whenever carrier is raised.
> > Until carrier is raised, your modem will not say CONNECT.
> >
> > Please do the following:
> >
> > 1. Open the 14.4 modem with minicom or kermit terminal emulator.
> > Set the baud rate to 9600.
> > 2. Use this init string: ATZ
> > 3. Then use this init string: AT&F1S0=0&W If you get an error, try AT&FS0=0&W
> >
> > 4. Then dial the modem using your other system. Use minicom or
> > kermit on the other system.
> > 5. When you observe a RING in the terminal emulator, type this: ATA
> > 6. Observe whether or not you get a CONNECT from the 14.4 modem.
> > 7. Once you get a CONNECT, type some stuff in each terminal window.
> > It should show up in the other window.
> > 8. If that doesn't work you could try AT&F2S0=0&W in step 3. Some
> > modems have a "Macintosh" and "PC" setting. You could also try
> > adding AT&C1&D2 as an additional init string.
> >
> > If you never get a CONNECT then there is something wrong with your hardware.
> > Probably the IRQ is set wrong on the serial port, or you have a pin missing
> > on your cable, or the modem is malfunctioning somehow. Perhaps its modulation
> > protocols are incorrect, say it uses only Bell modulation instead of
> > the ITU-T specifications.
> >
> > Once you've verified that you can get a CONNECT from the modem
> > manually, then use the same init string (and NOTHING else) for
> > mgetty's init string. Then try dialing in again. Your mgetty.log
> > file should indicate that it got a CONNECT instead of timing out.
> >
> > Hope this helps,
> > Jim
> >
> > daniel wrote:
> > >
> > > Hello,
> > >
> > > Here is the message from /var/log/mgetty.log.ttyS0:
> > > ---
> > > 04/15 18:46:50 yS0 waiting...
> > > 04/15 19:40:27 yS0 select returned 1
> > > 04/15 19:40:27 yS0 checking lockfiles, locking the line
> > > 04/15 19:40:27 yS0 makelock(ttyS0) called
> > > 04/15 19:40:27 yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
> > > 04/15 19:40:27 yS0 lock made
> > > 04/15 19:40:27 yS0 wfr: waiting for ``RING''
> > > 04/15 19:40:27 yS0 got: [0a][0d][0a]RING[0d]
> > > 04/15 19:40:27 yS0 CND: RING
> > > 04/15 19:40:27 yS0 wfr: rc=0, drn=0
> > > 04/15 19:40:27 yS0 CND: check no: 'none'
> > > 04/15 19:40:27 yS0 send: ATA[0d]
> > > 04/15 19:40:27 yS0 waiting for ``CONNECT''
> > > 04/15 19:40:27 yS0 got: ATA[0d]
> > > 04/15 19:40:27 yS0 CND: OKATA[0d][0a]DATA[0d]
> > > 04/15 19:40:42 yS0 CND: DATA[0a]
> > > 04/15 19:41:47 yS0 timeout in chat script, waiting for `CONNECT'
> > > 04/15 19:41:47 ##### failed timeout dev=ttyS0, pid=28665, caller='none',
> > > conn='', name=''
> > >
> > > 04/15 19:41:47 yS0 removing lock file
> > > --
> > > 04/15 19:41:47 yS0 mgetty: experimental test release 1.1.30-Dec16
> > > 04/15 19:41:47 yS0 check for lockfiles
> > > 04/15 19:41:47 yS0 checklock: stat failed, no file
> > > 04/15 19:41:47 yS0 locking the line
> > > 04/15 19:41:47 yS0 makelock(ttyS0) called
> > > 04/15 19:41:47 yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
> > > 04/15 19:41:47 yS0 lock made
> > > 04/15 19:41:48 yS0 tio_get_rs232_lines: status: RTS CTS DSR DTR
> > > 04/15 19:41:48 yS0 lowering DTR to reset Modem
> > > 04/15 19:41:48 yS0 tss: set speed to 9600 (015)
> > > 04/15 19:41:48 yS0 tio_set_flow_control( HARD )
> > > 04/15 19:41:48 yS0 waiting for line to clear (VTIME), read:
> > > 04/15 19:41:48 yS0 send: \dATQ0V1H0[0d]
> > > 04/15 19:41:49 yS0 waiting for ``OK''
> > > 04/15 19:41:49 yS0 got: ATQ0V1H0[0d]
> > > 04/15 19:41:49 yS0 CND: ATQ0V1H0[0d][0a]OK ** found **
> > > 04/15 19:41:51 yS0 send: ATS0=0Q0&D3&C1[0d]
> > > 04/15 19:41:51 yS0 waiting for ``OK''
> > > 04/15 19:41:51 yS0 got: [0d]
> > > 04/15 19:41:51 yS0 CND: OK[0a]ATS0=0Q0&D3&C1[0d]
> > > 04/15 19:41:51 yS0 CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
> > > 04/15 19:41:51 yS0 waiting for line to clear (VTIME), read: [0d][0a]
> > > 04/15 19:41:51 yS0 removing lock file
> > > 04/15 19:41:51 yS0 waiting...
> > > ---
> > >
> > > And then unfortunately there were not pppd messages in /var/log/messages :-\,
> > > but there was an mgetty message:
> > > Apr 15 19:52:05 ns1 mgetty [17001]: failed timeout dev=ttyS0, pid=17001,
> > > caller='none', conn='', name=''
> > >
> > > So like you mentioned, pppd doesn't seem to even get started. It seems the
> > > login is stalling at the authentication stage, but I haven't been able to
> > > confirm that. The most important looking lines I've seen so far are:
> > > > > sent [lcpconfREQid=0x1<asyncmap0x0><magic 0x8a8d59fb><pcomp>]
> > > > > terminating on signal 15
> > > though I do not understand the significance of this.
> > >
> > > Thanks for your efforts :)
> > >
> > > ---------- Original Message -----------
> > > From: ockers at ockers.net (Jim Ockers)
> > > To: clue-tech at clue.denver.co.us
> > > Sent: Fri, 16 Apr 2004 22:15:08 -0600 (MDT)
> > > Subject: Re: [CLUE-Tech] mgetty and ppp troubles on linux dialin server
> > >
> > > > Daniel:
> > > >
> > > > daniel wrote:
> > > > >
> > > > > Thank you both Chris and Jim for responding.
> > > > > I made the changes to adjust the port speed down to 9600 from 38400 in my
> > > > > mgetty.config file, and added just "9600" to the top of my
> > > > > /etc/ppp/options.server file.
> > > > >
> > > > > Unfortunately the dialin connection is still not working. Here is the
> output
> > > > > from the
> > > > > Kppp debug window on the client as it calls in:
> > > > > ---
> > > > > pppd 2.4.1 started by carol. uid 501
> > > > > using channel 2
> > > > > connect interface ppp0
> > > > > connect ppp0 < -- > /dev/ttS/0
> > > > > sent [lcpconfREQid=0x1<asyncmap0x0><magic 0x8a8d59fb><pcomp>]
> > > > > terminating on signal 15
> > > > > sent [lcptermREQid=0x2 "user request"]
> > > > > sent [lcptermREQid=0x3 "user request"]
> > > > > connection terminated
> > > > > exit
> > > >
> > > > Actually the server's mgetty log would be much more interesting for
> debugging.
> > > > Take a look at /var/log/mgetty-log.ttyS0 or whatever your logfile is
> > > > called.
> > > >
> > > > > PPPD's exit code of 15 is this:
> > > > > 15 The link was terminated because the peer is not responding
> to echo
> > > > > requests.
> > > >
> > > > The server's pppd debug log would also be interesting, if pppd ever started
> > > > on the server. I doubt that it did...
> > > >
> > > > Take a look at /var/log/messages to see if there are any messages
> > > > from pppd.
> > > >
> > > > --
> > > > Jim Ockers, P.Eng. (ockers at ockers.net)
> > > > Contact info: please see http://www.ockers.net/
> > > > _______________________________________________
> > > > CLUE-Tech mailing list
> > > > Post messages to: CLUE-Tech at clue.denver.co.us
> > > > Unsubscribe or manage your options:
> > > > http://clue.denver.co.us/mailman/listinfo/clue-tech
> > > ------- End of Original Message -------
> > >
> > > _______________________________________________
> > > CLUE-Tech mailing list
> > > Post messages to: CLUE-Tech at clue.denver.co.us
> > > Unsubscribe or manage your options:
> http://clue.denver.co.us/mailman/listinfo/clue-tech
> > >
> ------- End of Original Message -------
>
> _______________________________________________
> CLUE-Tech mailing list
> Post messages to: CLUE-Tech at clue.denver.co.us
> Unsubscribe or manage your options: http://clue.denver.co.us/mailman/listinfo/clue-tech
>
--
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/
More information about the clue-tech
mailing list