Can not get terminal line

Hi,

Post by Christopher Fowler
Here is an interesting problem. I've got mgetty running on a serial
port providing me console to a Linux box. I've got my laptop with a USB
serial adapter. These adapters are dumb and unfortunately this one
seems to not provide anything other than Tx,Rx,SG. I've got mgetty set
to direct but it still requires DCD to see something attached.

"ignore-carrier yes" might work.

gert

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christopher Fowler

2006-06-20 21:51:56 UTC

Post by Gert Doering
"ignore-carrier yes" might work.

The only problem with this is when the cable is unplugged the shell
could still be running. By using carrier the process gets a HUP which
places the port back to a login.

Post by Gert Doering
gert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Gert Doering

2006-06-20 21:57:26 UTC

Hi,

Post by Gert Doering
"ignore-carrier yes" might work.

The only problem with this is when the cable is unplugged the shell
could still be running. By using carrier the process gets a HUP which
places the port back to a login.

Well. What about "using a reasonable USB/Serial adaptor"?

It's hard to argue for full functionality based on dysfunctional hardware.

It *might* work if you use "toggle-dtr no".

gert

Christopher Fowler

2006-06-20 23:29:41 UTC

Post by Gert Doering
"ignore-carrier yes" might work.

The only problem with this is when the cable is unplugged the shell
could still be running. By using carrier the process gets a HUP which
places the port back to a login.

Well. What about "using a reasonable USB/Serial adaptor"?
It's hard to argue for full functionality based on dysfunctional hardware.
It *might* work if you use "toggle-dtr no".

Here is where I may not agree. I should use a good adapter but forget
about the crappy hardware.

If I would have created a "3-wire" cable only then it still would not
work. I might would try this:

Db9

---- Tx ------ 2
---- Rx ------ 3
---- Sg ------ 5

-DCD - 1
+
-DTR - 4

-RTS - 8
+
-CTS - 7

I may have my signals crossed but you should get the idea. I should be
able to create a "3-wire" cable and connect mgetty's DCD/DTR and RTS/CTS
and get a login. This is supposed to work. It may not be mgetty's
fault. It may be something in the serial driver of Linux that causes an
input/output error when I create a cable that looks like that.

The only way to find out is to try and open() the port with my own code
and see if it dies.

Post by Gert Doering
gert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christopher Fowler

2006-06-21 00:37:46 UTC

I've got some notes on where this was happening about 2 years ago. What
I found out was that if I jumpered ports 7,8 and 1,4 on the DB9 of the
serial port then this would fail

if ( tcsetattr( fd, TCSANOW, t ) < 0 )
{
lprintf( L_ERROR, "tcsetattr failed" ); return ERROR;
}

I'm using a 2.4.24 kernel so it may be driver related.

Post by Gert Doering
"ignore-carrier yes" might work.

The only problem with this is when the cable is unplugged the shell
could still be running. By using carrier the process gets a HUP which
places the port back to a login.

Well. What about "using a reasonable USB/Serial adaptor"?
It's hard to argue for full functionality based on dysfunctional hardware.
It *might* work if you use "toggle-dtr no".
gert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christopher Fowler

2006-06-21 00:40:18 UTC

Sorry for all the emails. Here is an image from the bug tracking system
we use that shows what I did to make mgetty spit out those errors

Loading Image...

Post by Gert Doering
"ignore-carrier yes" might work.

The only problem with this is when the cable is unplugged the shell
could still be running. By using carrier the process gets a HUP which
places the port back to a login.

Well. What about "using a reasonable USB/Serial adaptor"?
It's hard to argue for full functionality based on dysfunctional hardware.
It *might* work if you use "toggle-dtr no".
gert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Gert Doering

2006-06-21 07:39:49 UTC

Hi,

Post by Gert Doering
It *might* work if you use "toggle-dtr no".

Here is where I may not agree.

So did you try it, and it didn't work, or are you disagreeing that it
might work?

The problem you're experiencing could be related to the fact that mgetty
is toggling the DTR line upon startup, and with a looped-back DTR->DCD
line, is hanging up upon itself.

[..]

Post by Christopher Fowler
If I would have created a "3-wire" cable only then it still would not

You need to make sure that you don't use hardware flow control then
(because input flow control and output flow control will suddenly
interact) and to set "ignore-carrier" might be the decent thing to do.

[..]

Post by Christopher Fowler
I may have my signals crossed but you should get the idea. I should be
able to create a "3-wire" cable and connect mgetty's DCD/DTR and RTS/CTS
and get a login. This is supposed to work.

If you do *not* meddle with DCD, you should get a login. If you make
the machine hangup on itself, funny things will happen.

gert

Christopher Fowler

2006-06-21 11:24:45 UTC

Maybe this is causing it?

2.8 Why the occasional "tcsetattr failed: I/O error" message?
From: ***@greenie.muc.de

Q: Occasionally, mainly after "clean" user logouts (that is, the user
typed "exit" instead of just hanging up), I get the message 09/08
21:26:26 yS2 lowering DTR to reset Modem 09/08 21:26:27 yS2 tcsetattr
failed: I/O error in the mgetty log file, and a similar I/O error
message in the syslog file.

A: Well, this is a Linux and SunOS specific problem: if the modem is
still connected to the other end when mgetty starts, mgetty will force
it to hangup by lowering DTR (and sending +++ATH, in case DTR drop won't
suffice). This will make the modem lower the DCD (carrier detect) line.
Unfortunately, this will trigger a security mechanism in the Linux
kernel, which will prevent all further access via that file descriptor.
This is done to prevent one well-known password hack (I won't that
explain in detail).

Mgetty knows about that problem, and, upon noticing an error at this
point during modem initialization, will simply reopen the port and redo
all modem / port setup stuff.

Because suppressing that error message would be messy, it keeps
appearing, but it is harmless (... "trying again").

Post by Gert Doering
It *might* work if you use "toggle-dtr no".

Here is where I may not agree.

So did you try it, and it didn't work, or are you disagreeing that it
might work?
The problem you're experiencing could be related to the fact that mgetty
is toggling the DTR line upon startup, and with a looped-back DTR->DCD
line, is hanging up upon itself.
[..]

Post by Christopher Fowler
If I would have created a "3-wire" cable only then it still would not

If you do *not* meddle with DCD, you should get a login. If you make
the machine hangup on itself, funny things will happen.
gert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Gert Doering

2006-06-22 21:46:36 UTC