Troubleshooting TCP/IP Utilities for LAN Manager

Last reviewed: September 30, 1994
Article ID: Q96681
The information in this article applies to:
  • Microsoft LAN Manager version 1.0

SUMMARY

Troubleshooting TCP/IP utilities is actually much easier than it appears. This article contains a logical, step-by-step approach that can help you resolve most problems.

MORE INFORMATION

Verify IP Layer Connectivity with "ping [ipaddr]"

All of the TCP/IP services rely on the ability of the IP layer to transfer datagrams between machines. The test of IP layer connectivity is the "ping" command.

You can execute "Ping" several different ways. The most basic way is "ping x.x.x.x" where x.x.x.x is the IP address of the target machine. Here is a description of what occurs when you do this:

   If [the network portion of the target IP address equals the network
   portion of the IP address of the local machine]:

    - ARP (Address Resolution Protocol) is used to determine the MAC
      address of the target machine from the given IP address. If previous
      contact has been made with the target machine, ARP may supply the
      MAC address from cache. If not, an ARP broadcast is sent out on the
      wire, requesting that the target machine supply its MAC address.

    - An ICMP echo request is sent to the target machine.

    Else

    - ARP is used to determine the MAC address of the default gateway
      (router) instead of the target node. Again, if the IP<->MAC address
      mapping is available from cache, no ARP goes out onto the wire. If
      not, then an ARP broadcast is sent, requesting the MAC address of
      the default gateway. Once the MAC address of the router has been
      determined:

       - An ICMP echo request is sent as follows:

         - destination MAC address = router MAC address
         - destination IP address = target node IP address

      The router then picks the frame up off the wire, looks at the
      network portion of the destination IP address, and forwards the
      packet as necessary. When the packet arrives at a router that is
      directly connected to the destination network, that router must
      resolve the destination IP address to the MAC address of the target
      node, again using the ARP mechanism.

      When the target node receives a "ping", it must respond with an
      "ICMP echo response". The mechanism for getting the response back to
      the originating machine is the same as that described above.

      Note that ping can be used as a loopback mechanism to test the local
      machine. When this is done the ICMP echo request doesn't actually go
      out on the wire. If a machine can't ping itself, then there is a
      software or hardware installation problem.

Verify Name-to-IP Address Resolution

Most people prefer to use a name rather than an IP address to specify a destination machine. This means that the network software must be able to translate names to IP addresses. There are two means for doing this:

   Domain Name Resolver:

   RFCs 1034 and 1035 describe the Internet Domain Name System (DNS).
   Essentially, the DNS is a service available for many TCP/IP platforms
   that maintains a database of name-to-IP address mappings, and responds
   to queries made by clients in a standard format. If a name server is
   configured, then it will be queried for name-to-address mappings before
   local tables will be used.

   Microsoft does not currently offer a DNS name server platform, but
   does provide client software that will interoperate with compliant
   name server implementations from other vendors.

   "Hosts" file:

   The "Hosts" file is similar to the /etc/hosts file that many
   Internet systems use. It is a text table that maps Internet Domain
   Names to IP addresses. LAN Manager stores it in the <lanroot>/etc
   directory. If no name server is configured, then the hosts file is
   checked for mappings.

   Ping can be used to test name-to-address resolution. Just type
   "ping hostname" to invoke it. The DNR tries to resolve the name first,
   and if that fails then the hosts file is consulted. Once the IP address
   for the target machine is obtained, the ICMP echo request is sent,
   using the steps described earlier in this article.

Test the Specific Utilities

Each utility is different, but once IP connectivity has been established they can be tested individually.

   FTP: Type "ftp ipaddr" or "ftp hostname." Microsoft does not currently
        provide an ftp server, so the destination address or name must be
        another system that provides the ftp service. See chapter three
        of the "Microsoft LAN Manager User's Guide" for specific options.

TELNET: Telnet is accessed differently on MS-DOS and OS/2 machines. From
        MS-DOS, type "kermit ipaddr" or "kermit hostname." From OS/2, type
        "tty ipaddr" or "tty hostname". See chapter 2 of the "Microsoft
        LAN Manager User's Guide" for specific options. If you choose, you
        can use a more sophisticated terminal emulator than Kermit or tty,
        in which case you should specify BAPI as the network interface in
        the emulator setup. Any emulator which supports the BAPI interface
        should work with Microsoft telnet.

     RSH: The key to making RSH (and RCP) work properly is to set
          permissions correctly on the target machine. Chapter five of the
          "Microsoft LAN Manager User's Guide" describes this setup in
          detail. Note in particular that the target host must be able
          to resolve the IP address to a hostname in order for security
          to pass. This means that your IP address must be available to
          the target host either from the Domain Name Server, or from its
          hosts file. The syntax for RSH is "rsh hostname command."

     RCP: As with RSH, passing security is the most difficult part of
          setup. For RCP to succeed, you must have the appropriate
          permissions on both the source and the destination machines.
          The syntax for RCP is:

             rcp [hostname:file] [hostname:file]


Additional reference words: 1.00 tcpip
KBCategory: kbnetwork
KBSubcategory: nttcp


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 30, 1994
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.