Re: Slow telnet/pop3 connection

On Sun, 27 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <kdo914l0nqkg78ca2bv6hh19ggbvn5jhq8@xxxxxxx>, 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
.

Relevant Pages

  • RE: Firewall Rule Set not allowing access to DNS servers?
    ... I changed the DNS rules as you suggested, and the firewall works perfectly - ... > # Allow out access to my ISP's Domain name server. ... > so your udp packets never match this rule and default to ...
    (freebsd-questions)
  • Windows 9X clients can change password in Windows 2003 PDC Emulator
    ... I've desinstalled the WINS Server of the Windows 2000 and now, ... The DNS, WINS and AD replication are OK (Windows 2003 is Primary DNS+WINS ... Gathering NetBT configuration information. ... Packets Received: 36169 ...
    (microsoft.public.windows.server.migration)
  • Re: DNS Configuration Problem
    ... > With a network sniffer I sniff my network and when I configure IP address ... > server for the server destination, ... > on the nic interface you do not get out anymore this kind of DNS request, ... How many total packets did I capture on the ...
    (microsoft.public.windows.server.sbs)
  • Re: DNS forwarding
    ... >> the ISP's DNS server, external connectivity worked fine with no ... >> packets whatsoever during testing. ... > cause external DNS resolution to fail. ...
    (microsoft.public.win2000.dns)
  • Re: 2003 DNS Server issue that isnt present using 2000 DNS Server
    ... >> did nslookup on these domains on the DNS servers, ... >> Exchange server can't get the mail server IP for those domains. ... packets. ...
    (microsoft.public.win2000.dns)