telnet emulation issues with SCO

We are a call center.  We have a dialer that runs on SCO Unix.   For whatever reason this was setup on on a different subnet such that you can't telnet directly to it, instead you telnet to the server our software runs on and then telnet to the dialer from there.  

This server used to be AIX (5.1).  Now we have a linux server.

We always make sure SCO was selected in the options for putty...  and when we telnet through the AIX things work fine...  but when we telnet through linux a particular thing we do on the dialer where we have to press ctrl+s does not... it winds up freezing and not working.  

Any idea how the linux is messing this up or how I could fix it?
XetroximynAsked:
Who is Participating?
 
mikelfritzCommented:
A simple solution would be to put in a simple router that port forwards 23 from subnet A to subnet B for this specific task.


Another, more complicated approach would be to use iptables.

http://serverfault.com/questions/586486/how-to-do-the-port-forwarding-from-one-ip-to-another-ip-in-same-network

The port would need to be 23 unless you make SCO listen on another port, which is easy.

The downside is that you wouldn't be able to telnet directly to the linux server.  The upside is the same, since you shouldn't be telnetting directly to the linux server in the first place.  Or something like that.  Telnet is not secure, but it's an inside network thing, so...

The upshot of this is that you'd use the linux box as a ricochet point to go direct with telnet and avoid the multiple layers of telnets.
0
 
mikelfritzCommented:
It's going to be terminfo and termcap on linux.  I don't think "scoansi" is actually a standard so you may need to change putty as well to something more well defined like a VT emultaion or even TV950 or Wyse60...  SCO had their own derivative of ansi and I've found that bbsansi fails most of the time.

The first step is to get linux loaded up to handle terminal types and then test some emulations.  This might be all you need.
0
 
mikelfritzCommented:
You could also maybe just set putty to vt100, then log into linux and "export TERM=vt100" then telnet to sco and either type the terminal type if it asks or perform the 2 step:

TERM=vt100
export TERM

The vt might need to be VT in the above... I don't recall if case matters.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
XetroximynAuthor Commented:
hmmm... so I noticed on linux we were setting
TERM=linux
where as on the aix we were setting TERM=vt100

However even when I changed to vt100 on linux before connecting to the sco I still get the same freezing.

I noticed the sco uses TERM=ansi so I also tried that on linux before connecting to the sco... still the same freezing...

Not sure what to try next... any ideas?
0
 
mikelfritzCommented:
Try setting them all to vt100...  Just a thought.  ANSI to SCO is not ANSI to linux - they had their own odd ANSI.
0
 
mikelfritzCommented:
Another thought is to do the above, but ssh to linux and then telnet to SCO.
0
 
XetroximynAuthor Commented:
sorry I forgot to mention... I did try setting them all to vt100.  Same thing happened.  (also when SCO was in VT100 the menu interface was all black and white and the F3 key did not work to bring up drop down boxes like it normally does).
0
 
XetroximynAuthor Commented:
FYI... so the dialer techs (who can't figure this out) told us we have to use F3 to select options from drop down as opposed to typing them in... but I typed them in anyway when I tried the all vt100 thing... still... when I press ctrl+s it freezes
0
 
XetroximynAuthor Commented:
I just tried all previous variations while SSH to linux then telnet to SCO.

both vt100
both ansi
linux set to vt100 and SCO set to ansi (this is the combo used on aix that works... aix vt100 and SCO ansi)

Same result in all 3 cases it freezes.  :-/  

Any other ideas?
0
 
XetroximynAuthor Commented:
Thanks!  so I would kind of prefer the router option.  (We use telnet internally for this server, so a bit of an ordeal... we probably need to go through it some time anyway.. but thats another story)

I was actually all set to just plug this into our router and let it route to the other subnet... but then I realized... the subnet used here is 192.1.1.x... which is not private... it's public... not sure how that happened (before I got here) but I am not router saavy enough to know what might happen if I tell my firewall to route some public IP's locally on the LAN side...

Thoughts?
0
 
mikelfritzCommented:
Yuck.
You're fine unless you need to access:

Bolt Beranek and Newman Inc. BBN-WAN (NET-192-1-1-0-1) 192.1.1.0 - 192.1.1.255
BBN Communications BBN-CNETBLK (NET-192-1-0-0-1) 192.1.0.0 - 192.1.255.255

It's only a couple hundred addresses in the end and likely used internally by Raytheon anyway.

I'm guessing you are looking at how to move to private at some point.
0
 
mikelfritzCommented:
nmap scan comes up that 192.1.1.0 is locked up, so you're safe doing the routing internally and won't miss a thing.
0
 
XetroximynAuthor Commented:
you rock - thanks!
0
 
XetroximynAuthor Commented:
So I am likely still going to set up the route but I figured out the problem... in linux ctrl+s suspends output.  ctrl+q will resume output...

stty -ixon
will disable this... so on the linux ctrl+s does not suspend output anymore... but then I login to sco and it does again... even if I try to put stty -ixon into the sco command prompt ctrl+s still suspends output.

Im just curious if that gives anyone any other ideas about how to fix this while still accessing the SCO through linux
0
 
mikelfritzCommented:
You would likely want to put "-ixoff" as well.  This will fix the passthru of start and stop but not odd emulation translation issues with terminal types.  If the screen looks okay when you do the ricochet to SCO then the stty method should be fine.
0
 
XetroximynAuthor Commented:
hey - would you be able to find out who has 199.199.199.x?  Turns out there is yet another public IP range used by this dialer on our network... so I might be routing this instead of 192.1.1.x... curious if you can find out who owns it?  (or show me where you found out who owns 192.1.1.x)
0
 
mikelfritzCommented:
whois

https://www.onvoy.com/

VoIP provider in Mn
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.