Newsgroups: comp.dcom.modems
Path: utzoo!lsuc!dave
From: dave@lsuc.uucp (David Sherman)
Subject: Re: Packet Switching (X.25) and BBS
Date: Thu, 6-Oct-88 12:28:59 EDT
Summary: ioctl, X.29 and PADs
Message-ID: <1988Oct6.122904.8210@lsuc.uucp>
References: <62@csnz.nz> <1988Sep25.001151.6452@lsuc.uucp> <934@mstar.UUCP>
Organization: Law Society of Upper Canada, Toronto

In article <934@mstar.UUCP>, karl@mstar.UUCP (Karl Fox) writes:
> In article <1988Sep25.001151.6452@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes:
> >To avoid ridiculous charges, you do indeed need to operate on a
> >line-by-line basis.  We set up our calls (using X.29 to set the
> >remote PAD when the call comes in) to have a packet transmitted on
> >CR or any control character; that allows interrupt chars such as
> >DEL, ctrl-C or ctrl-\ to send the packet.
> >
> >We make do fine with line-based editors (a souped-up version of
> >"ed", the University of Toronto ed), a line-based version of
> >"notes", etc.
> 
> If you have a directly attached X.25 interface, it can use X.29
> commands to put the remote PAD into character-by-character mode when
> using VI or EMACS and then return it to line mode when you go back to
> your shell.  An external PAD connected via serial lines can't see the
> tty ioctl() commands, and therefore can't detect the user's intent as
> well.  Ioctl() commands can send X.29 commands to set echo, erase and
> kill characters, forwarding characters for ksh or tcsh users, etc.

Sure, but you can simulate this by arranging for ioctl() to send
the PAD the appropriate X.29 triggers.  That's effectively what
we do, but rather than muck with ioctl I just changed getpass(),
which was all I needed. For a more complete solution you'd just
change the ioctl() routine in /lib/libc.a to invoke the real ioctl
code on non-PAD lines and send X.29 trigger sequences on PAD lines,
and recompile all your applications.

Of course, you need to standardize on what trigger sequences will
have your PAD send our X.29 commands, and avoid using sequences that
can occur in your data.  We set up our Memotec PAD to treat ^A^A^A
as "echo on" and ^B^B^B as "echo off".

> Even with a serial-line-connected PAD, however, a knowledgeable user
> can log in, escape back to PAD command mode, change parameters to use
> character-by-character mode, go back to data mode, and run VI.  Not
> convenient, but it is possible.

Sure it's possible.  The problem on any large network such as
Datapac is that the turnaround time will be too slow for echo
to be comfortable. (Read: it would be downright painful.)

David Sherman
Toronto
-- 
{ uunet!attcan  att  pyramid!utai  utzoo } !lsuc!dave