I personally have had a hard time even trying to get a traditional
POTS phone line installed over here. The only offerings from atnt and
comcast are voip nonsense. Its kinda redundant and buggy trying to
dial up over a comcast voip line. ive tried it, it drops constantly.
The sales staff do not even know what i am asking for when i ask for a
traditional line over a voip line.
Being as it was so hard to get a phone line set up over here, i looked
into this as an option. Its called a wifi232.
I tried one out on a tandy 1000 and it worked flawlessly. I had set up
linux system and made it remotely accessable via telnet, and was able
to reach it via the dos running tandy 1000. I did not have the correct
adapter at the time, but i dont see anything stopping you from
plugging it into a vt100 directly.
I was looking to use the phone line as a kind of last resort
connection to deliver mail and keep in touch, but ironically, it goes
down more often than any other provider, and is the first thing to go
in a storm. I personally have been looking into getting a cheap cell
phone under the provider "ting" which only bills you for the data
used. Set that up as a wifi hotspot and get it talking to the wifi232
connected to a dumb terminal and i think it would be a good setup. if
you telnet into a linux system that has the lynx web browser
installed, you can view google and wikipedia quite easily.
Let me know if you think that kind of setup would be of any use to you.
On Tue, Jan 16, 2018 at 2:53 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
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