SCOUG-Programming Mailing List Archives

Date:	Sat, 2 Jun 2001 01:50:16 PDT
From:	<leganii@surfree.com >
Reply-To:	scoug-programming@scoug.com
To:	mail2news_nospam-20010602-comp.protocols.kermit.misc@anon.lcs.mit.edu
Subject:	SCOUG-Programming: Smashing through Screen with Kermit

Content Type: text/plain

As an intermediate step to getting them ethernetted,
I finally got my OS/2 and Debian boxes connected over
a Null-modem cable. I figure that being able to twiddle
configuration settings and reboot them sitting at one
console has to simplify the process for one who
has a lot to learn about networking.
Until I have Ethernet going the serial connection provides
a working 'out-of-band' connection.
How hard can it be to network the computers if they are
already networked?
This is more functional than a lot might think
having 'screen', a full screen 'window manager'
running on the Debian box, enabling multiple sessions
with one login, split screens, scrollback, cut and paste,
etc. from a text interface.
There are only two disadvantage to this that I know so far.

1) You can't take advantage of recent releases of Lynx, W3M,
and other text mode browsers to view images with viewers
like zgv.

2) The very first thing brought up in the screen FAQ is
'Why can't I transfer files with Kermit while screen is running?'.
The answer given, that you can't, is true only for the case
where you give up without analyzing the problem and
determining how Kermit transfer has to be configured to work.
Yes, over a simple serial connection you are restricted
to leaving other screen managed sessions to themselves
while the transfer goes on, but for me that is more convienient
than having to shutdown screen.
(I find it so usefull I 'exec screen -R' at the end my
.bash_profile file so that it is always running when I login.)

First add this line to /etc/inittab on the Debian machine
to allow loggin in on port 'com2'/ttyS1:

T1:23:respawn:/sbin/getty -L ttyS1 57600 vt100

(You might also want to experiment with Lilo and/or GRUB,
which allow control of boot-up over serial connections,
but that might be for another write up.)

The following script, run with Kermit/2 from the OS/2
end sets up C-Kermit on the Debian machine into server mode
and sets both so that file transfers happen.
The two external modem connection cables I'm using, spliced
together with gender menders and null modem adaptors is
kind of long (the PCs are in different rooms), and
runs past some wire nests, and I'm not certain about shielding,
so I found setting the allowed errors higher than the default
seemed needed. For a 36K file about 16 errors happened during
transfer, so my setting is excessive, but does the trick.
Without the settings of this script the transfer seemed to
lockup, as the screen FAQ indicated.
(If anyone knows any improvements, feel free to contact me.)

# Screen Smasher
# ( To 'Smash through Screen with file transfers' )
#
# for setting up kermit server
# at the other end to penetrate a
# connection where the UNIX session manager
# 'screen' is also running at the other end,
# without having to shutdown 'screen'.
#
# D.E. Legan 26/05/2001

# set this, last character of the remote prompt,
# in one place, so it can easily be changed for
# different circumstances:
define rprompt {>}

# first do as I *do*, not just as I *say*,
# set these things locally on OS/2 Kermit/2:
set prefixing all
set send timeout 1 fixed
set receive timeout 1
set send start-of-packet 65
set receive start-of-packet 65
set transfer locking-shift on
set retry 500
# .... nothing succeeds like excess!

:bangaway

# First, make an attempt to make sure kermit is actually running
# on the other end. This seems to do no harm if it already is.
# Although I actually have never used it for such, the help
# for C-Kermit indicates that the 'kermit' command issued
# at the kermit prompt serves to set command line switches
# after it has already been started. Here, if the other end
# is still at the shell prompt, it starts kermit.
# If kermit is already running, as already mentioned, it does no harm.
output kermit\13
input 5 \m(rprompt)
if failure goto bangaway

# This next command causes all non-visable, or non-standard
# bytes to be prefixed to be a standard ASCII character.
# While differing in specific details, in essence it can
# be likened to uuencoding or MIME base-64 encoding on
# the fly, allowing only standard, visable ASCII characters
# and carriage returns over the connection.
# Surely these will not interfere with 'screen''s operation! :-)
output set prefixing all\13
input 5 \m(rprompt)
if failure goto bangaway

output set send timeout 1 fixed\13
input 5 \m(rprompt)
if failure goto bangaway

output set receive timeout 1\13
input 5 \m(rprompt)
if failure goto bangaway

# Now set the start of packet character to simply the letter 'A':
output set send start-of-packet 65\13
input 5 \m(rprompt)
if failure goto bangaway

output set receive start-of-packet 65\13
input 5 \m(rprompt)
if failure goto bangaway

# According to 'Using C-Kermit', the following is almost never bad,
# so....
output set transfer locking-shift on\13
input 5 \m(rprompt)
if failure goto bangaway

output set retry 500\13
input 5 \m(rprompt)
if failure goto bangaway

# When developing this script, overlooked that this next one would
# have a different response than just the remote prompt,
# and thought that some how the local OS/2 machine was
# being put into server mode when 'kermit ready to serve...'
# was echoed on the local screen and then it locked up in an
# infinit loop.
output server\13
input 5 kermit ready to serve...
if failure goto bangaway

# now see what you can do:
remote help

Regards,
Dallas E. Legan II / leganii@surfree.com / dallasii@kincyb.com

Powered by......Lynx, the Internet at hyperkinetic speed.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 02 | June | 2001 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.