Network mapping with IP address

ping probably used NetBEUI.

"no route to host" means exctly what it says: it does not know how to find (route) the IP
check with
  netstat -rn
if it can be reached directly, or if you must use a gateway.

Posting The destination IP and the result of
  netstat -rn
  ipconfig -all
may give us some more hints.

Does it have a Netbios name? If so you can create an entry for it in the Hosts file (NT workstation c:\winnt\system32\drivers\etc
All you do it put the computer name and then the ip address
you will see when you edit the file.
Let me know
There should be the same file on a 95/98 Machine but it may be called lmhosts.
After that you should be able to map normaly useing the computer name.

Are you mapping the IP through Explorer rather than the command prompt?

Try TRACERT xxx.xxx.xxx.xxx.
How many hops does it take before it replies? If it is over 15 that could be our problem

it goes through 7 hops before it gets there.  the 8th hop lands on the machine I want.

Sounds like netbios is not enabled over TCP/IP on either or both of the machines. On win 95/98 check the "enable netbios over TCP/IP is enabled" and that TCP/IP is bound to the microsoft network client. On NT check that TCP/IP is bound to the workstation service (and server if you are planning incoming connections to the NT box). If you are connecting across the Internet or WAN, could a firewall be in the way?
The ping suggests that IP addresses and gateway addresses and routes are ok, but check the subnet masks are suitable.

both machines do use netbios over TCP/IP and both have working subnet masks.  There is no firewall in the way between the two computers but both are on different systems.  One is a road runner connection in New York the other is a Road runner connection in Pennsylvania.

LHMOSTS is not the same as HOSTS!! The hosts file are used for resolving TCP/IP hostnames while LMHOSTS are used to resolve NETBIOS names.
Are the machines on the same IP subnet?
Check the IP settings on the Win98 machine and verify that Gateway address is correct.

The two computers are on different subnets.  they are both completely different IP addresses.

And the gateway address, is that correct?
Also, if they are on different subnets (WAN?) and NETBIOS broadcasts are not allowed between them, you need to either use WINS or add an entry in the LMHOSTS file, like this:

my98machine 172.12.12.12

Oops, didn't see the answer and other comments!

the lmhosts file is a NT file.  because I am trying to connect to a Win98 computer from an NT computer.  how do I add the computer to the lmhosts file if I do not know the name of the machine just the IP?

Check these 2 articles, they might help you..
http://support.microsoft.com/support/kb/articles/q137/5/65.asp?FR=0
http://support.microsoft.com/support/kb/articles/Q161/4/31.asp

If we are connecting via an IP address, why is host resolution the slightest bit relevent? If you cannot connect via the IP, resolving a host name to an IP address is pointless. Surely we need to address the IP problem.
I have no problems mapping to machines even when I have only TCP ip installed with no name resolution enabled.

sweatbeast, are you the same as zaq? Or are you just having the same problem?
I quote from the MS article: "When using this new functionality, it is still necessary for the calling computer to know one of the NetBIOS names that is registered on the remote computer. There are currently three ways of finding a valid NetBIOS name to connect to on the target computer:"
What you need is a way to find the NetBIOS name..

NetBios is enabled on both machines.  And there is no firewall between the two computers.

How about a router? Normally, they also prevents NetBIOS broadcasts from comming thru..

a router.  How can I tell if there is one between me and the other IP address.

Just browsing thru the comments.. As your machines are on different subnets, there is a router between the machines. I'm quite sure that this will prevent the broadcasts from comming thru, as this is normal practice for routers!
Either you'll have to open for broadcasts on the router (BAD idea!) or you'll have to make the LMHOSTS file...

This is simple, isn't it ?
The first machine on subnet A needs to point to a default gateway that routes IP through to subnet B.
Subnet B needs to point to a default gateway that routes IP through to subnet A.
If you can PING the address, a TRACERT will tell you how it gets there.
It could be that your router has filtered out the ports 137-
139 ports or maybe just one, in which case NetBIOS over TCP/IP won't get through.
It's a common practice used to improve security and reduce bandwidth.
Even an LMHOSTS file won't solve this if there are filtering problems !

So is there any way to solve this problem?  Because I did a tracert and found the way it gets there.

Wait, look at tim_holman's last comment, if there is any machine inbetween which blocks ports 137..139, you cannot "map" using NetBIOS.

Also note that ping may either use NetBIOS or TCP/IP to communicate with the remote host, depending on you node type.
Tracert uses TCP/IP (hope M$ knows this), and it's a heuritic method of finding the path to the remote host. So you cannot be shure that anny other (following) command will use the same path (route through the same hps in the same order.

To find out a other machine NetBIOS name use  nbtstat -a ip-address .

A simple test to check if you can route port 139 is: telnet ip-address 139
If you get a connection it's probably not filtered ;-)

Was your IPs an true or just internal one? Try to change your comps' IP to 192.168.1.x and try again!

To make things a bit clearer ?
NetBIOS is non-routable, so you can't ping NetBIOS hosts on a different subnet unless your system resolves the NetBIOS name to an IP address and pings that, but either way, you're still using TCP/IP to ping.
One other thing - I thought you could only telnet to ports running the telnet service (ie port 23) ?
Otherwise telnet just hangs.
nbtstat -a ip-address will try to use port 137 on the remote host, if it can get there, in order to resolve the name.
net use \\remote ip address will use port 139.
If neither of these work, filtering's in place, as long as you can still ping the address OK.
If the destination PC has these ports removed from its services file, it won't work either, I think ?

> I thought you could only telnet to ports running the telnet service
ok, we are in a Win topic here, where people do only what M$ told them to do, usually. :-)
But even M$'s poor telnet can connect to any port (see Telnet->Connect). Anyway, its another question if it is usefoll, or even if it works (like on port 137).
tim_holman, thanks for the port-hints about net use and nbtstat.

Ok.  I tried to use nbtstat -a ip and it says host not found.  I then tried to use net use \\ip and it says the network name cannot be found. Telnet also did not work.

So is there any way I can map this computer?  Or is it hopeless?  Is there a way I can open port 137 or 139 on the machine I am trying to connect to, or is that up to the router in between the computers?

It's up to the admins to open the ports.

The admin of what though.  The router or the other computer?

Whoever looks after the router can open these ports for you.
It's a quick and simple process - all they have to do is log on to the router, type something, then logoff (!).
Don't let them palm you off....
At the other OS is only Win 98, I doubt anyone would have mucked around with ports.

The master browser of each network does a ip to name conversion. To do this you need at least one PC from each domain to be on the other subnet - ??? i think, mind is fuzzy.

Hmm...
I was under the impression that routers were not 'port specific' devices - being network layer systems. Ports are transport layer and are dealt with by firewalls/proxy systems.

If there is a firewall between the two systems, you may have a job persuading the administrator that he should allow you to pass unsecured packets! However this is unlikely as you can 'ping' and firewalls usually block ICMP packets (Prevents some 'denial of service' attacks).

Your problem may come down to the fact that your WINS server cannot resolve the name of the remote machine. The simplest solution to this would be to find the name of the remote WINS server and put this as your secondary WINS server. Obviously, if you already have a secondary WINS server, or use DHCP to provide your WINS server address, this will not be possible. In this case your WINS server itself needs to be able to replicate WINS information with the reomte WINS server (Lots of fun for your NT administrator!).

Unfortunately, even if the remote machine is acting as a browse server and you can see it over TCP/IP and ytou have it in 'lmhosts', your machine will still refuse to talk to it unless it can get a registered address (If anyone knows differently I would like to know - I spent several hours earlier today with exactly this problem!).

Best of luck!

Hstiles, net use \\xxx.xxx.xxx.xxx\share_name DOES work as long as the client PC knows a netbios name on the server. That is where our problem appears to be.
Blackman, with reference to earlier comment I overlooked the fact that we were talking about different subnets!

I do not know why.  But I had tried that before and it did not work.  But our solution of net use letter: \\ip\share worked this time.

Thank you.  Not sure why it did not work before though.