[CLUE-Tech] mgetty and ppp troubles on linux dialin server
daniel
daniel at alien2thisworld.net
Mon Apr 19 22:14:51 MDT 2004
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 -------
More information about the clue-tech
mailing list