:
: On Mon, 16 Feb 2004 02:56:28 -0600, Roland Hall wrote:
: > NetBIOS over TCP/IP is what 98 uses so you need that on W2K to talk to
them.
: > You can eliminate NetBEUI.
:
: But that doesn't explain why the 2K machines couldn't "see" each other,
You're right, it doesn't. But the best thing to do is to eliminate any
unnecessary variables in this equation. You only need one protocol, TCP/IP
(which is a contradiction in inself, since TCP/IP is a suite of protocols).
You need to enable NetBIOS over TCP/IP because ALL Windows versions,
supporting TCP/IP, prior to W2K ONLY use NetBIOS over TCP/IP. They may list
only TCP/IP, thank you Microsoft, but they are not using native IP.
You need Client for Microsoft Networks installed.
For NetBIOS naming you either need WINS, running on an NT/W2K/W2K3 server or
you need to use LMHOSTS.
For TCP/IP naming you either need DNS, running any server that supports it,
or you need to use HOSTS.
To get your IP addresses dynamically, you need DHCP, only one, on a server
that supports DHCP or you need to assign IP addresses manually. I suggest
you write down which computer has which address and refer to that when
assigning more.
: or itself.
You said you have W2K, but you did not state if they were client or server
OS. I'm assuming client because AD (Active Directory) would add more
variables to the equation.
On Windows clients, COMPUTERNAME = NetBIOS_NAME. To test if it will
respond, using TCP/IP, you can ping NetBIOS_NAME. Computer names shouldn't
have spaces in their names. The HOSTS name can be different than the
NetBIOS_NAME. Remember, HOSTS (TCP/IP), LMHOSTS (NetBIOS). To test if
TCP/IP is working on a computer, from its console: ping localhost. If it
fails, TCP/IP is the issue. Localhost is ALWAYS 127.0.0.1. It's reserved.
: I was hoping to avoid using NetBIOS over TCP/IP if possible.
Why? You were willing to use NetBEUI, written by IBM in 1984-85. It's
chatty, has no security and cannot route. Granted NetBIOS is not very
secure either but it does route and it is not as chatty as NetBEUI, which
never seems to shut up. If you ever use a protocol analyzer or packet
sniffer, you'll hate tracing NetBEUI.
: Does 98 use it no matter what?
Yes. )O:=
: Or do you have the option to?
No. )O:=
: I know if there
: was an option to not use it I didn't, I'll have to check.
No need, there isn't one.
: Can I use an
: LMHOSTS file instead?
Instead of WINS, yes.
: If so, can that be made using Wordpad?
You should use notepad so you're sure control characters are not embedded in
the file.
: Sorry for
: all the questions, and thanks for answering so quickly.
No problem. Ask away. If one person doesn't know, usually someone else
does. If someone makes a mistake, usually someone corrects them. I've been
on both ends.
If you cannot ping the computer you're on by IP, then TCP/IP is having an
issue. It's ok to ping localhost because it is built in to try 127.0.0.1.
Always ping by IP first, to test. A success proves connectivity works.
Then ping by name, if it fails, it's a naming problem, meaning either DNS
does not have an entry or is not being used. If not being used, then your
HOSTS file needs an entry to relate that name to that IP address. HOSTS
files are dynamic. Put in an entry, save it. Nothing else to do.
LMHOSTS files do not work like that. Put in an entry and then issue
commands:
nbtstat -R
The R MUST BE UPPERCASE!!
This purges and reloads the cache with the entries in the LMHOSTS file.
Whatever you put into an LMHOSTS file is put into cache and cache is always
checked first, even before WINS, even though they tell you node type clients
H-Node (0x8) will use WINS first, instead of broadcasting. However, you can
read that as, First after cache.
To see what is in your NetBIOS cache, use:
nbtstat -c
To help make this clearer and hopefully not muddying the waters anymore,
NetBIOS over TCP/IP means NetBIOS packets are encapsulated in TCP/IP packets
and TCP/IP is ONLY used as a transport. So, what does that mean in human
terms? If I issue the following command:
If I'm on a workstation named: wk1
nbtstat -a fs1
I'm trying to see if I can list the remote server's (FS1) name table. What
is actually happening is a NetBIOS command is being issued, the packets are
encapsulated into TCP/IP packets, the packets are transported to the remote
server and unencapsulated on that end and NetBIOS is then used to issue the
command. The return works the same way. This key word here is 'over'. Use
TCP/IP to get over the network and run my command using NetBIOS.
If ping fails, does that mean that connectivity is not there? No. It means
your ICMP (PING) message has failed. That's all. A router in between can
have 'no icmp echo requests', like on a Cisco, and your ping will fail.
Ping is not that reliable except on a subnet where you know ICMP messages
are not being blocked.
To double check yourself, use IPCONFIG.
ipconfig /all
This returns all NICs, in a given system and their TCP/IP settings, most
importantly NIC name, IP address, subnet mask, DHCP server address, Primary
and Secondary DNS server addresses.
How can it help? It is telling you what it knows so if something is not
working, then checking here will tell you if it is related to what the
computer knows.
Ex.
You cannot get an IP address or on W2K you can an IP address that is not on
your subnet and you're set to obtain an IP address automatically. When
checking with ipconfig, you notice DHCP address is empty. So, set an
address manually, you know is available and then try again. If it works,
then look at the DHCP Server. Check to see if the service is running, check
the log file, etc.
If you can ping by IP address and not by name, then you have a DNS issue.
If you're not using DNS but rather using HOSTS files, then that is where you
look. If you are using DNS, then are you using the right one? This is more
of an issue regarding AD, when you're not using the right one. Or, are you
pointing to a server that does not have DNS running? Has it failed? Is it
being blocked by a firewall, on a router in between that is not passing DNS
queries because port TCP 53 is blocked?
Summary:
Make sure you have the basics.
Test local.
Test [remote] connectivity by IP.
Test connectivity by name.
There is not need to go onto the next level of testing if you're not
successful at the one you're at.
If you cannot ping localhost, you cannot ping anywhere else.
HTH...
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech