[TUHS] 4.3BSD help: getty ignoring modem status

[TUHS] 4.3BSD help: getty ignoring modem status

[Warren Toomey]

Hi all, over on the uucp project we are struggling with a problem. If a
user is logged in with telnet, and they disconnect the telnet session,
their shell hangs around. The next person that telnets in gets the shell.

SimH, with the -a -m flags on a simulated DZ line, has these modem flags:

Telnet connected:    Modem Bits: DTR RTS DCD CTS DSR
Telnet disconnected: Modem Bits: DTR RTS         DSR

So, DCD and CTS are being dropped, but getty (or something) isn't responding
and (presumably) sending a HUP signal to the shell.

Is there anybody with some modem or getty knowledge that can help?

Thanks, Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/56ab3b16/attachment.sig>

[TUHS] 4.3BSD help: getty ignoring modem status

[Larry McVoy]

This sounds like a setsid() like problem.  As in the server is not 
cleaning up.  BSD didn't have setsid, I think that was a POSIX thing
and it was one of the good things that POSIX added.  That's my 
memory, someone will correct it.

On Sun, Mar 19, 2017 at 03:57:36PM +1000, Warren Toomey wrote:
> Hi all, over on the uucp project we are struggling with a problem. If a
> user is logged in with telnet, and they disconnect the telnet session,
> their shell hangs around. The next person that telnets in gets the shell.
> 
> SimH, with the -a -m flags on a simulated DZ line, has these modem flags:
> 
> Telnet connected:    Modem Bits: DTR RTS DCD CTS DSR
> Telnet disconnected: Modem Bits: DTR RTS         DSR
> 
> So, DCD and CTS are being dropped, but getty (or something) isn't responding
> and (presumably) sending a HUP signal to the shell.
> 
> Is there anybody with some modem or getty knowledge that can help?
> 
> Thanks, Warren



-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] 4.3BSD help: getty ignoring modem status

[Warren Toomey]

On Sun, Mar 19, 2017 at 03:57:36PM +1000, Warren Toomey wrote:
> Hi all, over on the uucp project we are struggling with a problem. If a
> user is logged in with telnet, and they disconnect the telnet session,
> their shell hangs around. The next person that telnets in gets the shell.

Some more data points. Vanilla 32V and 3BSD do HUP the shell when the DCD
drops on a SimH telnet disconnect. Vanilla 4.2BSD and 4.3BSD don't!
Very curious.
	Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/11fb924b/attachment.sig>

[TUHS] 4.3BSD help: getty ignoring modem status

[Jacob Goense]

On 2017-03-19 09:06, Warren Toomey wrote:
> Some more data points. Vanilla 32V and 3BSD do HUP the shell when the 
> DCD
> drops on a SimH telnet disconnect. Vanilla 4.2BSD and 4.3BSD don't!
> Very curious.

Does `exit' log you out there?

[TUHS] 4.3BSD help: getty ignoring modem status

[Warren Toomey]

On Sun, Mar 19, 2017 at 06:06:40PM +1000, Warren Toomey wrote:
> Some more data points. Vanilla 32V and 3BSD do HUP the shell when the DCD
> drops on a SimH telnet disconnect. Vanilla 4.2BSD and 4.3BSD don't!

Found it. In /sys/conf/GENERIC, the dz lines have flags turned on to
ignore DCD:

device    dz0     at uba? csr 0160100 flags 0xff  vector dzrint dzxint

I just turned off the flags and now a Telnet disconnect causes the
shell to be HUP'd and killed. Phew!
	Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/e5ccaace/attachment.sig>

[TUHS] 4.3BSD help: getty ignoring modem status

[Noel Chiappa]

    > From: Warren Toomey

    > So, DCD and CTS are being dropped, but getty (or something) isn't
    > responding and (presumably) sending a HUP signal to the shell.
    > Is there anybody with some modem or getty knowledge that can help?

I know very little of 4.x, but I did write a V6 DZ driver, back in the
Cenozoic or some such time period... :-)

Looking at the 4.3Tahoe (which particular 4.3 version is in question here,
anyway?) DZ driver:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/src/sys/vaxuba/dz.c

I find it hard (without further digging) to figure out how it gets from where
it should discover carrier has gone away (in dzrint(), from dztimer()) to the
rest of the system; they have added some linesw[] thing I don't know about.

Looking at the 4.2 driver:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/vaxuba/dz.c

it seems (in the same routine) to do the right thing:

               gsignal(tp->t_pgrp, SIGHUP);

so in that version, it's sending a SIGHUP to the whole pgroup when the
carrier goes away - which should be the right thing.

	Noel

[TUHS] 4.3BSD help: getty ignoring modem status

[Warren Toomey]

On Sun, Mar 19, 2017 at 02:37:12AM -0400, Noel Chiappa wrote:
> Looking at the 4.3Tahoe (which particular 4.3 version is in question here,
> anyway?) DZ driver:
> 
>   http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/src/sys/vaxuba/dz.c
> 
> I find it hard (without further digging) to figure out how it gets from where
> it should discover carrier has gone away (in dzrint(), from dztimer()) to the
> rest of the system; they have added some linesw[] thing I don't know about.

Thanks for digging Noel. Strangely, I've just installed a vanilla 4.2BSD
and it does the same thing.

The 4.3BSD dz(4) manual does say:

FILES
     /dev/tty[0-9][0-9]
     /dev/ttyd[0-9a-f]        dialups

but /dev/MAKEDEV doesn't seem to have a way to make /dev/ttyd*

Cheers, Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/203cb6ea/attachment.sig>

[TUHS] 4.3BSD help: getty ignoring modem status

[Paul Ruizendaal]

On 19 Mar 2017, at 7:37 , Noel Chiappa wrote:

> rest of the system; they have added some linesw[] thing I don't know about.

I believe this switches the serial interface between the normal tty driver and the SLIP driver.

[TUHS] 4.3BSD help: getty ignoring modem status

[Erik E. Fair]

See gettytab(5) followed by ttys(5).

/etc/gettytab has entries for various types of terminals in a very generic
sense (not in the termcap(5) sense), and /etc/ttys is where the arguments to
getty(8) are placed as part of the configuration of init(8) a.k.a. /etc/init
or in modern BSD /sbin/init

	Erik <fair at clock.org>

[TUHS] 4.3BSD help: getty ignoring modem status

[Erik E. Fair]

One more thing: it's impossible to get an 8-bit clean connection through the
TELNET protocol without speaking the TELNET protocol: even in binary mode,
you have to escape IAC (0377, 0x7F) in transmission, and eat the IAC byte
doubling in reception. See RFC-854.

I wrote an implementation of TELNET specifically for the AppleLink/Internet
E-mail gateway at Apple because we had to speak X.25 (sort of) to the GEIS
network & mainframe, and I didn't want to buy system-specific, proprietary
HDLC/LAPB serial gear that would lock me into a particular hardware platform,
so I used a Cisco protocol translator instead - it could be configured to map
a TELNET server connection to a given X.25/X.3 PAD call (akin to a terminal
server in "milking machine" mode). Worked great, once I had that streaming
TELNET implementation going to get binary data through the connection.

That design left me free to run the gateway on any Unix system I felt like:
it started on a Mac SE/30 (A/UX), moved to an SGI-4D/380 (Irix), and ended
life on a Sun SPARCstation ... 10 or 20 (SunOS 4? Solaris? I forget). So long
as the Unix in question had TCP/IP, Berkeley sockets, a network interface
(preferably Ethernet), sendmail(8) and perl(1), the gateway could be run on
it. Didn't even need to be proximate to the Cisco protocol translator - just
somewhere on the same IP network. Most of the code was actually Perl 3 & 4
because E-mail gatewaying is mostly about string manipulation.

	happy solstice!

	Erik Fair

[TUHS] 4.3BSD help: getty ignoring modem status

[Clem Cole]

Eric you are digging out painful memories... he is absolutely right.

On Sun, Mar 19, 2017 at 9:25 PM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> One more thing: it's impossible to get an 8-bit clean connection through
> the
> TELNET protocol without speaking the TELNET protocol: even in binary mode,
> you have to escape IAC (0377, 0x7F) in transmission, and eat the IAC byte
> doubling in reception. See RFC-854.
>
> I wrote an implementation of TELNET specifically for the AppleLink/Internet
> E-mail gateway at Apple because we had to speak X.25 (sort of) to the GEIS
> network & mainframe, and I didn't want to buy system-specific, proprietary
> HDLC/LAPB serial gear that would lock me into a particular hardware
> platform,
> so I used a Cisco protocol translator instead - it could be configured to
> map
> a TELNET server connection to a given X.25/X.3 PAD call (akin to a terminal
> server in "milking machine" mode). Worked great, once I had that streaming
> TELNET implementation going to get binary data through the connection.
>
> That design left me free to run the gateway on any Unix system I felt like:
> it started on a Mac SE/30 (A/UX), moved to an SGI-4D/380 (Irix), and ended
> life on a Sun SPARCstation ... 10 or 20 (SunOS 4? Solaris? I forget). So
> long
> as the Unix in question had TCP/IP, Berkeley sockets, a network interface
> (preferably Ethernet), sendmail(8) and perl(1), the gateway could be run on
> it. Didn't even need to be proximate to the Cisco protocol translator -
> just
> somewhere on the same IP network. Most of the code was actually Perl 3 & 4
> because E-mail gatewaying is mostly about string manipulation.
>
>         happy solstice!
>
>         Erik Fair
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/cdce6a87/attachment.html>