We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Ping TCP/IP  Problems

franks022397 asked
Medium Priority
Last Modified: 2006-11-17
All machines run Win95 , are attached to a Novell 3.x server and have tcp/ip installed. There is no problems with the interface of any machines with respect to Novell.  Some machines can ping all others on the lan but some can only ping some of the machines and return a "timed out" message. All addresses are from to (my machine with a working dial-up ) and all have a subnet mask of  The wiring is thinnet and I have moved one of the "bad" machines to a port that has had a machine with full access to all addresses and have the same limited results.  What can I do to resolve the limited view of my lan and give all machines  the ability to ping each other ? I have changed configs on some machines using the same entries taken from a "good" machine and still have not corrected this problem.
Watch Question

Which system is the default router? Are all systems configured to point to that ip address. I assume you are pinging by ip address and not names.  If names, make sure all systems have an up to date host file. Otherwise it's strange.


There is not default router on the system. I do however have Wingate installed on  When using ping I always use IP addresses as opposed to names,even though I have up to date HOSTS files in the machines. I have also tried not loading Wingate and am still not able to ping all hosts.  


Edited text of question

If everything is on the 192.1.1.x subnet, with mask, then no routing should be happening.  If you are ping by number and it does not work, I'd look for duplicate IP addresses.


All machines had been checked for IP addressing using winipcfg command and the results confirmed/compaired with settings in control panel. Any "forced" duplicate IP addresses cause error messages on both systems that have the same address.

When you say "thinnet", I assume you mean BNC-type connectors. Over the years, I have seen this type of wiring cause significant, inexplicable problems, especially when used over distances in excess of 100 m. or with multiple drops.  Most problems 'went away' when we converted to twisted-pair.  Now this may *not* be your problem, but one way to test is to isolate your LAN into "chunks" (make sure you use a proper BNC terminating "T"); re-test the PING test on the new "chunks" of the network, and see if you can isolate the PING time-outs.  You may find that a part of your network is acting strange -- or, if everything works divided into 2 "chunks", but not when re-connected, then your span is too long.  


Yes, my thinnet bus does use BNC-type connectors : (
I had given some thought to chopping the cabling into two segments to see what the results would be but haven't had a "slow" time  in the office to take people off line for the testing yet.  I did however move a few machines around  in a effort to see if it was location related or machine related.  This so far has not given me any results that confirm the root of the problem.

Thank you all for your comments,,,,,,,,,,,if ther are any others I would certainly welcome them !
If you are able to communicate using IPX/SPX(Novell) or NETBEUI(MS networking) then your wires are not the problem.  TCP/IP will work on marginal wires long after IPX/SPX(Novell) and NETBEUI(Microsoft) have failed.  In mixed environments(yours is one) you must check your frame types for compatibility.  Novell and TCP/IP can run over either 802.3 or Ethernet_II frames.  These frames create separate networks that cannot be seen from the other unless a machine on your local wires routes between the two.  I've found that TCP/IP works best when it has a separate frame type than your Novell network.  Regardless, all your TCP/IP machines must use the same frame type or they may as well be on separate wires.  Check your ncf files on your novell server to find out what frame you are running IPX/SPX over(usually 802.3), then set up your TCP/IP to run on the other.  This varies depending on whose TCP/IP stack you are running.  Let me know what stack you are running and I will attempt to find out how to ensure the proper frametype.  

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Now I think we may be closing in on this problem !  I checked the frame settings on most of the hosts in the building and found them to be set at 802.3 (IPX/SPX), just as you thought.  I really don't see how or where to set frame types for the TCP/IP protocol or the adapter through the control panel settings. ( ? )
I also started checking the hosts ( 3 ) that I'm having the most problems seeing by doing a search for files with TCP.  The search results of these machines don't match with mine at all.  It would seem that these machines may have their tcpip stack from WFW, even though then are all running WIN95.  These     ( 3 ) machines are all set up for using our RISC6000 which was installed, by others, prior to Win95.  If indeed these machines are running a different version of tcpip could I expect the problems that I am having ?  Making changes to the hosts using the RISC is a real problem as the allow me no down time, and even going near the RISC requires VP approval !  

Thanks for your time and patience.

Some troubleshooting questions.

1. Does your Novell server have TCP/IP loaded(in startup.ncf)?
    If you aren't IP tunnelling or running NetwareIP you probably  don't need it.  Also it can route indiscriminately which is one more variable you have to nail down.  
2. Can the three hosts using the RISC6000 ping others in the LAN?
    Just trying to be systematic here.

3. Can others ping the RISC6000 hosts?
    Same here.

4. Can others ping the RISC6000?
    Same here.

5. Are you connected to the Internet and if so how?
    This may seem like an obvious question but many nets are standalone and it's important to know of any possible routers which may be causing conflicts.  There should only be one router on your network and it should most likely be the machine that connects you to the outside world.  If you aren't connected to the Internet or any other subnets(ie hosts not 192.1.1.x) then you should not need a router at all.  

Answering questions 2,3, & 4 will pretty much tell you if the different TCP/IP stacks are the problem.  Be systematic when you  answer these questions and don't assume anything.  IP problems are usually associated with cluttered configs(ie, IP address conflicts, frame mismatches, mis-routered packets).  
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.