Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Ping TCP/IP  Problems

Posted on 1997-02-23
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.
Question by:franks022397
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 1589271
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.

Author Comment

ID: 1589272
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.  

Author Comment

ID: 1589273
Edited text of question
How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.


Expert Comment

ID: 1589274
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.

Author Comment

ID: 1589275
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.

Expert Comment

ID: 1589276
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.  

Author Comment

ID: 1589277
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 !

Accepted Solution

gotlieb earned 300 total points
ID: 1589278
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.  


Author Comment

ID: 1589279
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.

Expert Comment

ID: 1589280
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).  

Featured Post

On Demand Webinar: Networking for the Cloud Era

Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you’re involved with your company’s wide area network (WAN), you’ve probably heard about SD-WANs. They’re the “boy wonder” of networking, ostensibly allowing companies to replace expensive MPLS lines with low-cost Internet access. But, are they …
What we learned in Webroot's webinar on multi-vector protection.
This is my first video review of Microsoft Bookings, I will be doing a part two with a bit more information, but wanted to get this out to you folks.
In this video you will find out how to export Office 365 mailboxes using the built in eDiscovery tool. Bear in mind that although this method might be useful in some cases, using PST files as Office 365 backup is troublesome in a long run (more on t…

704 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question