mgetty and a DEC VT320

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

Ruediger Back wrote:
> I tried to mail to mgetty@muc.de. This is what I found in my maillogs
> after the message went undelivered for some time:
> 
> Feb 13 02:24:17 kunou sendmail[22996]: AAA22673: to=mgetty@muc.de, ctladdr=back (500/100), delay=01:24:59, xdelay=00:00:09, mailer=smtp, relay=vogon.muc.de. [193.174.4.4], stat=Deferred: 451 Put ,E=\r\n at the end of Mether, Mtcp, or Msmtp in sendmail.cf if you are using Solar...I cannot accept messages with stray newlines. Many SMTP servers will time out waiting for \r\n.\r\n.

This is qmail's wording for "your SMTP sender is *BROKEN*".

> Now, that's what a egrep -2 Msmtp /etc/sendmail.cf gives:
> ##### @(#)smtp.m4	8.32 (Berkeley) 11/20/95 #####

Hmmm, I have no idea what exactly to do about it -- please check with
www.qmail.org. There you'll find docs about about everything, I'd say.

[..]
> So here comes the original message:
> ===================================
> To: mgetty@muc.de
> Subject: mgetty on VT320 Terminal
> Reply-to: back@picard.mathematik.uni-wuerzburg.de
> FCC: ~/mail/sent-mail
> --text follows this line--
> Hi,
> 
> I'm trying to use a VT320 with mgetty (using Linux on a serial port). 
> I've tried the following:
> 
> /usr/local/sbin/getty ttyS0 -x 9 -r VT320 vt320-k311 

What on earth are these "vt320"-things supposed to be? Mgetty doesn't
take its terminal type via command line, and it should not be compiled
with gettydef either...

> where /usr/local/sbin/getty is linked to /usr/local/sbin/mgetty
> Have also tried mgetty in the command line with and without the -b
> option.
> I know that getty works perfectly with:
> 
> getty ttyS0 VT320 vt320-k311

So why do you want to use mgetty, if getty works?!


But let's see whether we can find out why mgetty is not working...

> 02/12 20:14:26 yS0 key: 'blocking', type=3, flags=2, data=TRUE

Good.

> 02/12 20:14:26 yS0 key: 'modem-check-time', type=0, flags=1, data=3600

Hmmm.

> 02/12 20:14:26 yS0 check for lockfiles
> 02/12 20:14:26 yS0 checklock: stat failed, no file
> 02/12 20:14:26 yS0 locking the line
> 02/12 20:14:26 yS0 makelock(ttyS0) called
> 02/12 20:14:26 yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
> 02/12 20:14:26 yS0 lock made
> 02/12 20:19:33 ##### failed dev=ttyS0, pid=21283, got signal 15, exiting

Someone killed mgetty...

> 02/12 20:19:33 yS0 removing lock file
> 
> It just hangs there forever until killed. 

Well - that's what "blocking TRUE" means: do a blocking open(). It will
continue the moment your serial port receives a DCD signal (for example,
because you have switched the terminal to ON -- assuming a reasonable
cable, wiring terminal's DTR output signal to the PC's "DCD" input).

> I also tried with toggle-dtr. All to no avail.

Try without "blocking". Just use "mgetty -r" (do not call it as
"getty").

> The reason I'm trying this is because I want to use the Rs232 Modem
> control setting with the VT320 as opposed to the RS232 data leads only
> mode it's using right now. This should allow hard flow control instead
> of the Xon/Xoff. 

This could be achieved by logging in via getty, and then setting
 
 $ stty crtscts

afterwards.

> And mgetty usually provides a more detailed account
> of what is going on. I'm not positive whether the cable I'm using is
> sufficient for what I want; it works perfectly with getty, but not
> when I'm trying the modem control mode (presumably because that was
> intended for a direct connection of a modem to the terminal, but that
> is a wild guess). 
> So is there anyone who can comment on this ?

I think the problem is that the cable doesn't assert the DCD signal -> the
port blocks infinitely.

gert
-- 
USENET is *not* the non-clickable part of WWW!
           //www.muc.de/~gert/
Gert Doering - Munich, Germany      gert@greenie.muc.de
fax: +49-89-35655025    gert.doering@physik.tu-muenchen.de

.