UNIX for Dummies Questions & Answers

Hey All,

I am trying to find something similar to minicom, but it needs the ability to be ran during a remote dialup session on the remote
device's side.

If I dial into the remote server (*using minicom) and then try to run minicom on the remote server I get the following:

Code:

# minicom cisco_console
No cursor motion capability (cm)

Basically, I will be connecting to a remote PC using a dialup USB Modem (*remote PC also has USB Modem, which I dial-in to),
and then once connected I need the ability to connect to ttyUSB0 (*which is attached to a Cisco router's Management port). When
I'm physically at the router device I use minicom, but I've just found out that you get an error if you try to use it during a remote dialup
session, which is initiated through minicom by dialing the remote PC/Server...

Since it seems that I CAN run minicom if I connected to the remote server using SSH, I was wondering if there was either a
different program I can dialup to the remote PC with other then minicom, OR if there was another program I could use once I've
dialed into the other PC (*after using minicom to connect to the remote server)..? Does that make sense?

Any thoughts or suggestions would be greatly appreciated!

EDIT: I also just tried to use the screen command and got an error as well...

Code:

# screen /dev/ttyUSB0
Clear screen capability required.

Thanks in Advance,
Matt

What is TERM set to when you get these warnings? Setting something like TERM="vt100" on the remote end before you run anything else may allow it to run, but whether it'll work properly or not I can't say.

Hey Corona, thanks for the reply, much appreciated!

When I'm connected through dialup (*which is when I get that error) I see this below, for TERM:

Code:

# env | grep TERM
TERM=dumb

Ok, so I set TERM="vt100" and then re-ran minicom. This time it loaded without any errors, but the behavior is very erratic.
Re-writing over text on the same line, half cut-off words, weird spacing, etc... And eventually it just stopped either excepting my
input altogether or I just can't see what I'm typing anymore...

So I then tried screen (*after having to re-dial into the server because minicom killed my session) and screen works ALOT
better then minicom does in this instance. Screen also isn't perfectly formatting the terminal window, but it is definitely usable...
So it seems that the screen command is my best option so far (*after first setting TERM="vt100" of course)... Awesome!

This kind of reminds me when I was writing a script that I wanted to use the top command in and was having issues because top
wanted to update the terminal screen constantly and all that, but I think I remember there being an option that made it simply
reprint out the output continuing on down the terminal window, instead of just updating that terminal window by re-writing over
what was already on-screen... I was kind thinking that maybe there was something like that out there which would just continue
printing on down the terminal window instead of updating the terminal window and moving the cursor around the screen, but
I didn't see any options in the minicom or screen commands like that...

But if I don't find something other then screen in this instance, I think it could suffice...

Thanks AGAIN for your reply, you definitely got me pointed in the right direction!!

Thanks,
Matt

It's set to the wrong kind of terminal, then. What terminal are you using?

On what side? I thought it was vt100 since that is what we set TERM to?

If I go over to the other PC that I'm dialing into (*I have the remote PC that I'm dialing into physically with me while
I'm testing trying to figure this out) and if I open a terminal window and check TERM I get:

Code:

# env | grep TERM
xterm

Is that what you were looking for?

Thanks Again,
Matt

The "thing" you are typing in, I see, is an XTERM.

VT100 is an old Sun terminal which ended up being a de-facto standard. XTERM, Linux VGA consoles, and lots of others emulate its basic features. It was as good a guess as any.

You are forwarding one terminal (i.e. serial port) through another, that's going to be unavoidably glitchy I think. The farthest terminal will catch some things, the nearer terminal will catch others... If you could make a PPP link instead, you could ssh into your server then run minicom just as if you were really there.

Hey Corona, thanks again for the reply!

Hummm... Ok, that stinks....

My only "requirement" for this is that I have to use dialup. Just quickly reading the intro at this link http://www.tldp.org/HOWTO/text/PPP-HOWTO
I can see that Point-to-Point Protocol can be used with modems/phone lines, etc, so that is good... Since I haven't ever used PPP before I guess
I'll have to try and find a good tutorial for using ppp. Is there any command's MAN pages I should take a look at that you know of off the top
of your head?

If I check in my PATH variable for anything ppp related I see the following:
*FYI, "findPath" is a simple script I wrote a while back that searches env's PATH variable for anything matching the REGEX/Argument...

Code:

# findPath ppp

    Command: findPath
Search Type: REGEX

    Searching in: /usr/lib/mpi/gcc/openmpi/bin
        *NO MATCHES FOUND!

    Searching in: /sbin
        *NO MATCHES FOUND!

    Searching in: /usr/sbin
        *FOUND MATCHES!
            ▪ pppd
            ▪ pppdump
            ▪ pppoe-discovery
            ▪ pppstats
            ▪ rcsmpppd
            ▪ smpppd
            ▪ smpppd-dhcp
            ▪ smpppd-ifcfg

    Searching in: /usr/local/sbin
        *NO MATCHES FOUND!

    ....more output from other dirs with no matches.....

Maybe something not in the output above that I could download?

Thanks Again,
Matt