SCO 5 - Telnet is incredibly slow . . . what to do?

[gaea]

I'm stuck with this one, and would appreciate any ideas you can offer . . . the bean counters need their data.

We have two offices, and each office has a SCO Unix server which hosts our Cobol-based, character-driven accounting software. Right now we are connecting from the main office to a branch via telnet. (Locally we also connect to our own server via telnet, but of course to an internal IP.)

We used to dial in, but I went to the branch office, networked their machines, and obtained broadband access for them. I had to go with a wireless service because of its lower cost and speed of installation (we couldn't wait 3-5 weeks for DSL or a T1), but I still thought it would be faster than dial-up. Right now it CRAWLS--at times it seems to lock up. The connection is 1 Meg, symmetrical. On both ends we connect through basic LinkSys routers with a Cisco switch on this end and an AOpen switch at the remote branch. However, I have tried connecting directly and bypassing all hardware on this end to no avail.

The broadband providers say they have tested everything and that our speeds are indeed symmetrical at about .85 Meg. What can I do? Is this just an issue of trying to telnet over a wireless connection? Is there something I can do to router configuration at the remote branch? Is there another protocol by which we can connect to the remote machine?

Oh--we currently use AnzioWin to connect, but I've tried everything from Putty to Mocha but with no better results.

I hope I've given enough information. I really appreciate y'all's time and any help you can offer!

Gaea

 

[stanhubble]

What part of the telnet session is slow?
Just the initial connection?

from the clients and from server to server:
What are the ping times like?
what is the output of netstat -nr?
is routed running at either end?
what is the output of traceroute?

 

[gaea]

[tt]
Hi--thanks for your reply! I'm sorry for the length of this post--I've learned a lot about networking lately, but I'm still pretty green. If I included the wrong information or not enough or too much, let me know.

The whole session seems to be slow, but only from our clients (see below--I can connect with relatively good speed from home). On both ends, the remote and local servers are listed in /etc/hosts, and a w -X shows the connection by name rather than by IP.


From client to server:

Pinging 66.135.20.206 with 32 bytes of data:

Reply from 66.135.20.206: bytes=32 time=75ms TTL=131
Reply from 66.135.20.206: bytes=32 time=82ms TTL=131
Reply from 66.135.20.206: bytes=32 time=84ms TTL=131
Reply from 66.135.20.206: bytes=32 time=82ms TTL=131

Ping statistics for 66.135.20.206:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 75ms, Maximum = 84ms, Average = 80ms

Netstat:

Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 0b db 94 14 92 ...... Broadcom 440x 10/100 Integrated Controller
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.222 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.222 192.168.0.222 20
192.168.0.222 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.222 192.168.0.222 20
224.0.0.0 240.0.0.0 192.168.0.222 192.168.0.222 20
255.255.255.255 255.255.255.255 192.168.0.222 192.168.0.222 1
Default Gateway: 192.168.0.1
===========================================================================
Persistent Routes:
None



From local server to remote server:

PING 66.135.20.206 (66.135.20.206): 56 data bytes
64 bytes from ward (66.135.20.206): icmp_seq=0 ttl=131 time=108.675 ms
64 bytes from ward (66.135.20.206): icmp_seq=1 ttl=131 time=85.972 ms
64 bytes from ward (66.135.20.206): icmp_seq=2 ttl=131 time=115.091 ms
64 bytes from ward (66.135.20.206): icmp_seq=3 ttl=131 time=81.287 ms
64 bytes from ward (66.135.20.206): icmp_seq=4 ttl=131 time=100.882 ms
64 bytes from ward (66.135.20.206): icmp_seq=5 ttl=131 time=103.252 ms
64 bytes from ward (66.135.20.206): icmp_seq=6 ttl=131 time=103.076 ms
64 bytes from ward (66.135.20.206): icmp_seq=7 ttl=131 time=96.508 ms
64 bytes from ward (66.135.20.206): icmp_seq=8 ttl=131 time=83.304 ms
64 bytes from ward (66.135.20.206): icmp_seq=9 ttl=131 time=104.682 ms
64 bytes from ward (66.135.20.206): icmp_seq=10 ttl=131 time=89.530 ms
64 bytes from ward (66.135.20.206): icmp_seq=11 ttl=131 time=98.141 ms
64 bytes from ward (66.135.20.206): icmp_seq=12 ttl=131 time=230.332 ms
64 bytes from ward (66.135.20.206): icmp_seq=13 ttl=131 time=95.867 ms

--- 66.135.20.206 ping statistics ---
14 packets transmitted, 14 packets received, 0% packet loss
round-trip min/avg/max = 81.287/106.900/230.332 ms


Netstat:

# netstat -nr 66.135.20.206
input (net0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
4461090 94 2962727 0 2931 4468116 94 2969753 0 2931


As for routed, I *think* it is not running at either end. I'm new to this, but a ps -ef | grep route turns up nothing while a ps -ef | telnet, for example, gets connection results.


And, finally, traceroute, which may be the most telling piece of information . . . If I trace from a client, tracert times out repeatedly:

Tracing route to c66-135-20-206.btr.broadbandip.net [66.135.20.206]
over a maximum of 30 hops:

1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
[snip]

And the same thing happens with a unix traceroute:

traceroute to 66.135.20.206 (66.135.20.206), 30 hops max, 40 byte packets
1 * * *
2 * * *
[snip]

However, if I do a remote traceroute:

traceroute to 66.135.20.206 (66.135.20.206), 30 hops max, 40 byte packets
1 manny.Firewall.Opus1.COM (192.245.12.95) 18.553 ms
2 Opus-GW (207.182.35.49) 18.553 ms
3 Login-Opus-T1-1.Opus1.NET (207.182.63.102) 24.412 ms
4 165.64.254.49 (165.64.254.49) 24.412 ms
5 fa1-0.tus1.Login.COM (204.17.35.81) 24.412 ms
6 66-162-41-17.gen.twtelecom.net (66.162.41.17) 24.412 ms
7 66-162-41-5.gen.twtelecom.net (66.162.41.5) 18.553 ms
8 216-136-127-9.gen.twtelecom.net (216.136.127.9) 18.553 ms
9 core-02-so-0-0-0-0.lsag.twtelecom.net (168.215.53.73) 22.459 ms
10 168.215.55.80 (168.215.55.80) 31.248 ms
11 peer-01-ge-0-3-0-0.snfr.twtelecom.net (66.192.250.34) 32.225 ms
12 at-0.mae-west.snjsca03.us.bb.verio.net (198.32.200.80) 34.178 ms
13 p16-0-1-0.r20.snjsca04.us.bb.verio.net (129.250.3.86) 36.131 ms
14 p64-0-0-0.r20.plalca01.us.bb.verio.net (129.250.2.70) 37.107 ms
15 p16-1-1-3.r20.dllstx01.us.bb.verio.net (129.250.4.104) 58.590 ms
16 p16-6-0-0.r02.hstntx01.us.bb.verio.net (129.250.4.25) 61.520 ms
17 ge-0-2-0.a03.hstntx01.us.ra.verio.net (129.250.29.89) 61.520 ms
18 d1-12-0-0-27.a02.hstntx01.us.ce.verio.net (128.241.2.130) 78.120 ms
19 ge-1-2.a04.mlpsca01.us.da.verio.net (129.250.25.197) 78.120 ms
20 d3-1-1.a01.btrgla00.broadbandip.net (66.135.0.138) 160.146 ms
21 * * *
22 * * *
23 * * *
24 * * *
25 c66-135-20-206.btr.broadbandip.net (66.135.20.206) 197.253 ms

All is well. Also, if I telnet from home (Time Warner Cable, no router) it's fairly speedy. One other thing: If I telnet to the remote server, then try to ping the local server within that session, I get no output--it just hangs until I end the process:

PING 209.209.214.9 (209.209.214.9): 56 data bytes

--- 209.209.214.9 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

That isn't normal, is it?

Thank you thank you--
Gaea
[/tt]

 

[sixtoedsloth]

im guessing you have a vpn tunnel between 66.135.20.206 and 209.209.214.9, which are the external ip's of the routers at each end of the link.if not you are sending traffic that isnt secure!

assuming the above
do your servers have internal ip's like 192.168.1.1? this is the ip you should be connecting to.

Russ

 

[gaea]

Hey, thanks for the reply. I'm kind of holding off on things because the whole environment is about to change. I applied the 506a patch, which I'd read had a slight chance of improving telnet communications . . . but also found that the wireless IP we were using resulted in enormous packet loss. At the time it seemed like a good idea--installation was fast, it was relatively cheap for the speed, et cetera. But apparently dropped packets with a wireless IP are like rat hairs in peanut butter--a certain amount is acceptable and even expected.

So . . . for right now, yes, we are breaking all the telnet rules and basically have our arses hanging out for the world. But we have VPN on the 214 end (a Cisco 2500 with VPN configuration) and will have DSL and VPN on the 66 end (Cisco 827 with VPN configuration) within the week.

I'm hoping that the combination of no more packet loss and a more secure bridge will alleviate some of our problems, but I worry that the only real plus in the new setup is DSL instead of wireless on the 66 end. The encryption/decryption on each end is just going to slow things down. On the other hand, our problem seems to be more of latency than of actual speed (It's fast when it's working--it just freezes frequently. When I'm using it, it recovers well, but when the end-users are online, they start hitting keys in frustration so that when it does finally recover, all those keystrokes are processed, usually resulting in connection death ), so I'm hoping we're just having sluggish lockup-type behavior because of the wireless connection.

We do connect to the 66 server's internal address--there's just a line in their current config that routes port 23 requests to the server's internal address.

Thanks, and I'll update when things are stable again. Apparently slow or otherwise problematic telnet is a big topic, and ultimately I'd like to discover and post "what worked for me" for some other lost networking newbie.

Gaea