Re: Serial comm program
On 08/10/2005 06:32:56 AM, Daniel D Jones wrote:
Sorry, don't mean to be all elite about modularization.
This is what I'd do, and do do in similar circumstances.
YMMV
I'm a Cisco tech for a very large organization. Half the time, I'm
connected
to a router console via a serial port. The other half, I'm connecting
remotely.
(Serial connectivity and network connectivity are different
balls of wax. Getting serial right is always a pain.)
Our routers and switches only accept remote access via one
specific server. I SSH into that server, then telnet into the device.
When
I'm working on a device, being able to scroll back to stuff that's
scrolled
off the screen is vital.
I have my terminal windows all set to 1000 lines of
scrollback, YMMV.
We're required to log everything we do to
the
devices, so logging at all times is necessary.
Have your .bash_profile always start 'script'. Have
script append output. Use logrotate to keep your disk
from filling up.
There are a number of
actions
that are highly repetitive. Scripting them makes it much easier and
reduces
the chances of error. I also need to paste in long configs.
I would like to tell you how to use drag and drop to paste
file content, but I don't know if it's even possible. Maybe
somebody else can help with that. Otherwise, there's
select with the left mouse button and paste with the middle
button, and there's always "cat". There's a couple of extra
mouse clicks to open the text file and select the content
before pasting, which is too bad. :-(
As far as scripting goes, the 'expect' language rocks. See "chat"
also. I generally pipe directly to/from the serial devices
in /dev/ with chat but expect is designed to drive other
interactive programs, although you can talk directly to
serial devices too.
If the
info is
pasted in too fast, the router or switch will drop characters, so I
need
something with a configurable delay after pasting characters or lines
from
the clipboard.
This I don't understand. Your net connections should be all TCP,
and so the data should arrive at the destination. The serial
connections need flow control and/or rate limiting. The way
to do this is with the proper wiring and configuraton of the
serial port, either through minicom config or directly on the
port with setserial. (I'd use a minicom config.) If you
can't guarentee the other end of the serial line will have
flow control then you need to reduce the bps on the
serial line to something that won't overflow.
(I'm sure you know all this.) If you're talking to a
unix box that's got the serial line wired into it,
have your script use stty to adjust it's serial line.
Most of the time, I upload new IOS files via TFTP.
If
a
router crashes or the flash memory croaks or for whatever reason it
will only
come up to the rommon> prompt, it may require transfer via xmodem.
etc, etc.
For xmodem etc., we're back to serial lines, either
mincom, which will invoke xmodem for you, or to
an expect script that runs xs. (Heck, expect could
drive minicom too I suppose.)
Evidently, it doesn't exist. Yes, it is certainly possible to
accomplish everything I need via multiple programs. However, if I do
go to
multiple programs, it all has to work together. I have to be able to
log the
xmodem transfer, and I'd really like to be able to script the whole
thing.
I'm well aware of the value of small, sharp tools and the Unix way.
But I'm
also aware of the value of powerful programs that just work.
I think you just need to know what pieces are out there. Expect
might be the key. They do all fit together.
I wasn't slamming minicom or any of the other programs, nor was I
intending to
"get uppity" about the decade it was written in.
Right. There's real value in having everything "in front of your
face".
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Reply to: