On 01/16/2018 03:38 AM, Peter Corlett via cctalk wrote:
I do this routinely, albeit with a terminal emulator and ssh session
rather than a physical terminal and modem.
Agreed.
My "small device" is a Debian Linux box in Germany on which I read mail
and Usenet, do IRC, etc. I wrote a trivial Perl script called "google"
that inspects its arguments, and constructs a search URL which it passes
to elinks, a text-mode web browser. A similarly-trivial "wikipedia"
script could be written. Some web sites such as Twitter recognize the
elinks User-Agent and switch to a non-JavaScript "mobile" site. Facebook
doesn't work, but there's nothing of value there anyway.
Nice.
A physical serial connection is simpler than a pair of modems, so start
with that. Run a null modem cable between your terminal and COM1 on
the Linux box, edit the inittab to add a getty for /dev/ttyS0 with the
appropriate terminal type (there's usually a commented-out example)
and reload init. A similar principle applies to USB-serial dongles,
but they're a bit unreliable so try to use a proper on board serial port
if possible.
I'm curious what sort of issues you've had with USB based serial ports.
Is it the fact that USB devices can change names? Or is it a race
condition between driver load and getty launching? Or something else?
Linux's "vt100" terminal type differs somewhat from DEC's in that it
includes command sequences that an original VT100 does not and some
full-screen applications will render incorrectly,
That surprises me.
Is it actually the VT100 definition in termcap / terminfo? Or are you
referring to the fact that Linux uses the "linux" (?) term type in lieu
of the "vt100" term type?
but a VT220 worked OK when I last tried, back in 2003-ish. If the
render is occasionally off-by-one -- you'll know it when you see it --
it means that the terminal is configured for 24 lines and the Unix box
for 25 lines or vice-versa. Use the terminal's settings menu and/or
tweak $LINES/$COLUMNS on the Linux box.
*nod*
I feel like theses are issues that were prevalent back in the days of
serial terminals. Probably not new. If anything, new variants in an
existing messy soup.
Throw some DEC MMJs and LAT in for good measure. }:-)
Dial up is a refinement of this. You will need to use "mgetty" instead
which understands Hayes commands and other modem control signals, but
it might not be installed by default.
Why is mgetty required? Are you referring to the fact that mgetty can
discern the difference between text / SLIP / PPP / FTN / fax / voice and
hand the connection off to the proper back end?
If the port is dedicated for this, then I don't think mgetty (or any
other fancy getty) is required.
Note that 15 years ago we were running sysvinit, and now we have
the Brave New World of systemd, which is overcomplicated GUI junk and
probably doesn't support serial terminals. If you decide to build this,
find a Linux distribution without systemd, or use something like FreeBSD.
Why will systemd be a blocker? Shouldn't any self proclaimed init
system be able to launch a daemon (what ever it's dependencies /
arguments are) and re-spawn it when it exits? - Why does systemd need
to know anything about the serial port? Why can't systemd just launch
(m)getty which is monitoring the serial port. - Or are you saying that
the (systemd based) login program that (m)getty would call might have
issues.
Note: I am anti-systemd. But I don't see how Master Control Program,
ala Tron, can prevent (m)getty from working on a modern distribution.
Granted, the OP might need to create some custom systemd config files.
But I view that as more of a speed bump than an actual blocker.
--
Grant. . . .
unix || die
--
Grant. . . .
unix || die
