| mvBase
Tech Tip: |
#
mv131 |
| Release(s): |
1.1
onwards |
| Windows
O/S: |
NT4.0/Windows
9X |
Telnet
connections to an mvBase mvTELNET server appear slow to establish.
There
are reported instances of Telnet connections to an mvBase mvTELNET
server being slow to establish. This is manifested as the length
of time between these two events:
- When
the user's telnet client establishes a telnet connection
with an mvBase mvTELNET server.
(On
some telnet clients, when the telnet connection itself is
established, the title bar of the telnet client window changes
to show the name of the system connected to.)
- When
the mvBase mvTELNET telnet server connects to a line
on an mvBase server. When the mvTELNET server connects to
a line on the mvBase server the following message is displayed
on the screen:
Welcome
to the mvBase telnet server.
You are connected to line 1 on \\some_system_name
This
time delay between these two points has been seen to be as long
as 15 seconds to over 45 seconds, however, once the connection
to the mvBase server has been established, then communication
and response speed is satisfactory.
Cause
The
problem occurs when the mvBase mvTELNET telnet server attempts
to find the name of the system on which the telnet client is
running.
Here,
we are trying to get the name of the client given its IP
address. The name is one part of what is called 'host information'.
To
look up the host information corresponding to a network address
the networking support in the Windows NT operating system will
do the following:
- If
an entry for a DNS server address exists in the system's TCP/IP
networking configuration, then NT will attempt a reverse DNS
lookup.
The
reverse look-up is done after the Telnet client connects
to the mvTELNET telnet server and before mvTELNET connects
to a line on an mvBase server. The delay is the result of
the network timeout when a DNS server is defined but unreachable,
or non-existent.
- If
there is no DNS defined, or the DNS lookup fails then the
'NetBIOS cache' on the local system will be consulted. This
is originally established from the HOSTS file (if any).
(The
HOSTS file must be on the system that is running the mvBase
workstation-on NT it lives in %SYSTEMROOT%\System32\Drivers\Etc
)
Regardless
of whether the attempt to get the Telnet client name from a
'HOSTS' file was successful or not, the delay has already been
caused by the failed attempt of the reverse DNS lookup.
Resolution:
You
need to ensure that the TCP/IP settings for the network card
being accessed has its DNS settings correctly configured.
If
the DNS search order is pointing to a DNS server that cannot
be reached or does not exist then you will experience delays
until the DNS request times out.
To
verify the DNS settings you need to go into Control Panel, Networks,
Protocols, TCP/IP (for that adapter), DNS. If you have a DNS
server in the DNS search order listbox then you will need to
ensure that it exists and is reachable on your currently connected
network. If the DNS Server does not exist then remove that entry.
If
there are multiple entries in the DNS lookup search order, then
check that each one exists and is reachable.
Notes
- One
common mistake that is made on laptop computers is to connect
the laptop to the network and configure the network card to
use static IP address's and specific DNS, WINS settings etc.
When
the laptop is not connected to the network then these addresses
are still being used, but the DNS/WINS components are no
longer reachable. Trying to telnet to an mvBase mvTELNET
telnet server on the laptop itself, will then encounter
the problem above.
- We
recommend that you avoid setting up client computers using
static IP addresses and settings and go to a Microsoft DHCP
(Dynamic Host Configuration Protocol) environment for the
network settings.
- This
problem with unreachable or non-existent DNS's may also occur
on a client computer (instead of the NT system where the mvBase
workstation is running). In this case, it is the TCP/IP DNS
settings on the client which need to be fixed.
In
this case, the problem will manifest itself as the length
of time between the telnet client being instructed to connect
to a system by name, (rather than by direct IP address)
and the name resolution completing (or failing totally).
| The
networking support in the Windows NT operating system will
always resolve system names to IP addresses as below.
This is what the Telnet client may have had to do (unless
it was given an IP address to connect to instead of a name)
and is the opposite of what we are doing here on the Telnet
Server. If
the name is not a Fully Qualified Domain Name (FQDN)
like 'mordac.misp.com' and is just a system name like
'mordac' then the name will be looked up as follows:
- If
a HOSTS file exists then it will be consulted first.
- If
there is no HOST file, or it does nor contain the required
entry, then the LMHOSTS file will be consulted.
- If
a WINS (Windows Internet Naming Service) server is configured
on the network then NT will try to resolve the NetBIOS
name to an IP address.
- If
no WINS is available, or it does not contain the desired
entry, then a DNS lookup will be done.
If
the name is a Fully Qualified Domain Name (FQDN)
like mordac.misp.com then only a DNS lookup will be done. |
|
|
