Hello all,

I have several clients that use telnet to connect to an application server. If the clients are on the same subnet as the server, everything is ok. If I move the clients to a different subnet and route them through a Linux server (different network cards or same network card with virtual eth's, it makes no different), there are intermittent hick-ups, when the cursor seems to stall for a quarter or a half of second. The situation is not singular to one server, we use this setup in many headquarters and it's always the same. The servers are Slackware, but vary from 10.2 to 12.1, iptables varies from 1.3.5 to 1.4.0 and iproute2 varies from ss050330 to ss060323, with different hardware configurations.
For example, if I connect and then keep a key pressed (let's say "a"), it outputs: 15 a's, half second pause, 20 a's, quarter second pause, 10 a's, half second pause, a.s.o.
I really don't know how to handle this problem or even where to start with it. Any pointers would really be appreciated.

This situation might happen with other connection types, not only telnet, but this is where it's most pressing and easy to verify.

Thanks

Have you tried using secure shell, aka ssh ? Telnet is very unsecure!

What does that have to do with my question? I gave telnet as an example, because it's easier to check. This is an application which actually uses telnet. It's not my choice, it's the builder's.

hi saf,

were these an intranet over WAN connections?
do you have any PBR/traffic classification implemented - because i saw that you have those iproute2 policies - perhaps on your core router or something?

Not at all, everything happens over the LAN and no prioritization is made on any packet/connection. I'm starting to think I should investigate CPU/IRQ utilization on the router, but this is happening in all locations that I tested and no two hardware configurations are the same.
Can you suggest any other test I could run to try to find the probable cause?

Thanks

When I read your post last night, I was to tired to respond, but I thought of compression, MTU mismatches, packet reassembly or other buffering issues on the routing station.

Run tcpdump and capture some telnet traffic to see if any obvious anomalies appear at the packet level.

hi saf,

OK then. a high port utilization (netstat) or CPU bottleneck (top) could be a problem. PING or pathping could measure how fast an information can be processed/gathered by any network devices. and do check remote target (like remote servers or any remote subnet that traverse the router/firewall).

or perhaps you have any firewall --limit implemented? routing alone is not a heavy application - but firewalling is - so it can saturate your network traffic flow.

and duplex? speed?