Slow telnet/pop3 connection

I'm transitioning to a new linux server (based on linuxfromscratch) and have noticed a significant deterioration in connection time
for telnet and pop3 connections, but not ssh connections (all using the same "telnet" client on some Windows Vista boxes).

What's weird is that similar connections made to the old linux server -- which is plugged into the same switch -- are still quite
fast.

I've read that this typically involves problems with reverse DNS lookups, but I tried using IP adddresses on the telnet client,
rather than names, and it's just as slow.

Suggestions or references would be most appreciated. This isn't a deal killer...but it is annoying, and quite perplexing.

- Mark

Mark Olbert wrote:
> I'm transitioning to a new linux server (based on linuxfromscratch) and have noticed a significant deterioration in connection time
> for telnet and pop3 connections, but not ssh connections (all using the same "telnet" client on some Windows Vista boxes).
>
> What's weird is that similar connections made to the old linux server -- which is plugged into the same switch -- are still quite
> fast.
>
> I've read that this typically involves problems with reverse DNS lookups, but I tried using IP adddresses on the telnet client,
> rather than names, and it's just as slow.
>
> Suggestions or references would be most appreciated. This isn't a deal killer...but it is annoying, and quite perplexing.
>
> - Mark

there is to things to look

First : perhaps your server try to make ident request ( tcp 113 )

you could try

iptables -A OUTPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with
icmp-port-unreachable

second : if your server is IPV6 enabled try to disable IPV6

hope this help

On Sat, 26 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Mark Olbert wrote:

>I'm transitioning to a new linux server (based on linuxfromscratch) and
>have noticed a significant deterioration in connection time for telnet
>and pop3 connections, but not ssh connections (all using the same
>"telnet" client on some Windows Vista boxes).

Are "all" of the connections slow, or just the initial one (takes a LONG
time to get a login prompt, but once you get that, things are at normal
speed)?

>What's weird is that similar connections made to the old linux server
> -- which is plugged into the same switch -- are still quite fast.

So, what is the difference in the configurations? If the "new" box
is using xinetd to run the effected services, and the "old" box is
running the old inetd, you may be causing the problem by the "Log"
lines in the individual service files (something lacking in inetd).
This could also be caused by the new server attempting to use 'auth'
(RFC1413 using tcp/114) if your clients are "DROP"ing such requests
rather than answering or "REJECT"ing those requests. A packet sniffer
would show this instantly.

>I've read that this typically involves problems with reverse DNS
>lookups, but I tried using IP adddresses on the telnet client, rather
>than names, and it's just as slow.

The DNS lookup occurs on the _server_ not the client. The server wants
to know the name of the system connecting. It does this by attempting a
reverse (PTR) lookup. If your DNS can not resolve the PTR query, you
need to have the individual names/addresses of ALL clients in the
/etc/hosts file on the server.

Old guy

Comments interleaved.

>Are "all" of the connections slow, or just the initial one (takes a LONG
>time to get a login prompt, but once you get that, things are at normal
>speed)?

Just the initial presentation of the login prompt. From that point on everything is fast.

>So, what is the difference in the configurations? If the "new" box
>is using xinetd to run the effected services, and the "old" box is
>running the old inetd, you may be causing the problem by the "Log"
>lines in the individual service files (something lacking in inetd).

Both systems are using xinetd. I'll check the log settings, but I believe they're the same.

>This could also be caused by the new server attempting to use 'auth'
>(RFC1413 using tcp/114) if your clients are "DROP"ing such requests
>rather than answering or "REJECT"ing those requests. A packet sniffer
>would show this instantly.

I ran wireshark and didn't see any auth packets. But I'll check again.

>The DNS lookup occurs on the _server_ not the client. The server wants
>to know the name of the system connecting. It does this by attempting a
>reverse (PTR) lookup. If your DNS can not resolve the PTR query, you
>need to have the individual names/addresses of ALL clients in the
>/etc/hosts file on the server.

Okay. One other piece of data: getting to the login prompt is slow from Windows clients, but not from a linux client. The DNS runs
on a Windows 2003 server.

Some additional info after cruising thru wireshark...

I'm seeing a sequence of ident (port 113) packets coming from the telnet server box. The client (a Windows Vista box) isn't sending
anything back.

Here's the rough timeline:

First ident packet arrives at the start of the connection attempt (after some preliminary stuff)

A second ident packet arrives after no response by the client for 3 seconds

A third ident packet arrives after no response by the client for 6 seconds

A fourth ident packet arrives after no response by the client for 12 seconds

Finally, after another 9 seconds the server "gives up" and initiates a telnet session (at least, there are a lot of packets marked
"telnet data" by wireshark at that point).

When I run wireshark against an attempt to the old telnet server there are no ident packets shown. The sequence jumps immediately
into what wireshark marks as "telnet data".

So obviously I have something configured or built differently between the two machines.

Do you have any thoughts as to why one version of telnet is using ident and the other isn't?

- Mark

On Sun, 27 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Mark Olbert wrote:

>> Are "all" of the connections slow, or just the initial one (takes a
>> LONG time to get a login prompt, but once you get that, things are
>> at normalspeed)?
>
>Just the initial presentation of the login prompt. From that point on
>everything is fast.

Classic - a security "feature" effecting the logging of the connections.

>> So, what is the difference in the configurations? If the "new" box
>> is using xinetd to run the effected services, and the "old" box is
>> running the old inetd, you may be causing the problem by the "Log"
>> lines in the individual service files (something lacking in inetd).
>
>Both systems are using xinetd. I'll check the log settings, but I
>believe they're the same.

log_on_success += USERID
log_on_failure += USERID

You're looking for something like that.

>> The DNS lookup occurs on the _server_ not the client. The server
>> wants to know the name of the system connecting. It does this by
>> attempting a reverse (PTR) lookup. If your DNS can not resolve the
>> PTR query, you need to have the individual names/addresses of ALL
>> clients in the/etc/hosts file on the server.
>
>Okay. One other piece of data: getting to the login prompt is slow
>from Windows clients, but not from a linux client. The DNS runs on
>a Windows 2003 server.

Two possibilities - though your other post suggests it's auth:

1. DNS - this server is able to resolve (either through an /etc/host
entry, or a functioning DNS) the IP address to hostname for the system
that connects with no delay. The other systems don't resolve for some
reason. Two solutions - fix the DNS so everything resolves, OR put
all hosts into the /etc/hosts file on the server, so that it doesn't
need to ask for a DNS 'PTR' lookup.

2. Auth or identd - a lot of people believe Steve Gibson's statements
that "stealth" (dropping unwanted packets, rather than rejecting them)
is the way to go, because that way you can't be seen. Here you see an
example of where that bogus concept is biting you. If the "slow" boxes
were to reject the auth or identd packet to tcp/114, there would be no
delay. As the packet is dropped/ignored, the server is waiting until
the connection attempt times out before continuing. Again, two
solutions - remove the 'log_on_*' lines, OR fix the "firewall" on the
slow box[es] to REJECT packets to tcp/114. A third solution would be
to install an indent server (or enable it if installed) on the slow
clients.

Old guy

On Sun, 27 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Mark Olbert wrote:

>Some additional info after cruising thru wireshark...
>
>I'm seeing a sequence of ident (port 113) packets coming from the
>telnet server box. The client (a Windows Vista box) isn't sending
>anything back.

That's not the default behavior for a windoze box - there is a firewall
running on it trying to 'stealth' the system.

>Here's the rough timeline:
>
>First ident packet arrives at the start of the connection attempt
>(after some preliminary stuff)

That's almost certainly the 'log_on_*' setting in the /etc/xinetd.d/telnet
configuration file.

>A second ident packet arrives after no response by the client for 3
>seconds
>
>A third ident packet arrives after no response by the client for 6
>seconds
>
>A fourth ident packet arrives after no response by the client for 12
>seconds

Standard retransmission delays.

>Finally, after another 9 seconds the server "gives up" and initiates a
>telnet session (at least, there are a lot of packets marked
>"telnet data" by wireshark at that point).

Sounds about right. It could be worse, because there is a configuration
in xinetd to block the connection if an ident/auth query isn't returned
with something resembling a valid user identification. Obviously, this
isn't the setting used here.

>When I run wireshark against an attempt to the old telnet server there
>are no ident packets shown. The sequence jumps immediately into what
>wireshark marks as "telnet data".

Compare the two /etc/xinetd.d/telnet files.

>Do you have any thoughts as to why one version of telnet is using
>ident and the other isn't?

This being 'Linux-from-scratch' I would take it as an option in the
compile. I believe this is the xinetd daemon, rather than the telnet
server.

Old guy

> log_on_success += USERID
> log_on_failure += USERID

And that was the culprit. Who would have thought that such a minor change to a config file could wreak such havoc??

Interestingly, the Vista firewall doesn't seem to have the ability to reject ports that are blocked. You can open them, but you
can't define the behavior (reject or drop) for a blocked port. I think I'll do some more research on that.

Moe, thanks very much for your help. And the education, which I also appreciated.

- Mark

On Mon, 28 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Mark Olbert wrote:

>> log_on_success += USERID
>> log_on_failure += USERID
>
>And that was the culprit. Who would have thought that such a minor
>change to a config file could wreak such havoc??

Trust me - it happens ALL the time! ;-)

>Interestingly, the Vista firewall doesn't seem to have the ability to
>reject ports that are blocked. You can open them, but you can't define
>the behavior (reject or drop) for a blocked port. I think I'll do
>some more research on that.

I don't use vista - I got rid of windoze before microsoft invented the
Internet - but this may not be that unusual. The default means of
blocking stuff in Linux 'iptables' is also to DROP rather than REJECT,
although there is the _capability_ in iptables to "--reject-with"
option. Still, in both operating systems, without a specific block
rule on a port, the networking code itself should provide the REJECT
if there is no server/application listening on that port.

>Moe, thanks very much for your help. And the education, which I also
>appreciated.

My pleasure!

Old guy