19 Mar
2017
19 Mar
'17
12:37 p.m.
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/vaxub…
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
19 Mar
19 Mar
1:46 p.m.
New subject: 4.3BSD help: getty ignoring modem status
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/vaxub…
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
20 Mar
20 Mar
6:47 a.m.
New subject: 4.3BSD help: getty ignoring modem status
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(a)clock.org>
7:25 a.m.
New subject: 4.3BSD help: getty ignoring modem status
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
8:25 a.m.
New subject: 4.3BSD help: getty ignoring modem status
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(a)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
2834
days inactive
2835
days old
5 comments
5 participants
participants (5)
-
Clem Cole -
Erik E. Fair -
jnc＠mercury.lcs.mit.edu -
Paul Ruizendaal -
Warren Toomey