XP laptop can not ping other XP laptop

I have two laptops that can ping each other when configured this way.
Host A xxx.16.0.20 No default gatway
Host B xxx.16.0.120 No default gateway

They can not ping each other when configured this way.
Host A xxx.16.0.20 No default gatway
Host B xxx16.1.120 No default gateway

With a mask of I thought the xxx.16.0.0 would be one big network and the 3rd octects would not need to match.

I also tried changing xxx16 to 10.0 and 10.1 with a mask and one laptop could ping the other but not the reverse?

Does MS XP not truly understand networks or am I missing something?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

RartemassLife CoachCommented:
The behaviour you mention is as expected.

With IP addresses the first three numbers need to be the same for direct communication without further configuration.
Your second configuration where the third number is different means you are setting up a subnet.
Essentially they are treated as two different networks.
To have those PCs talk you need to configure the router to create a link between the subnets.

This links provides an example of how to set it up.
RartemassLife CoachCommented:
Subnet masks can change the default behaviour more, and you can make different subnets based on a single number in the IP.
Example: through can be one subnet, and through can be a different one, by changing the subnet mask.

What is your purpose in doing the above? Is there an issue with keeping them on the same subnet?
Dragon0x40Author Commented:
thanks Rartemass,

I am trying to find out why using the incorrect subnet mask prevents communication between devices.

In my opinion these results are not as expected.

Any IP address whose 1st octet is between 128 and 191 has a classful mask of which indicates that the first two octets of the ip address are the network and the last two octets are the hosts.

In my example the network would be 172.16.x.x and the valid hosts on that network would start at and end at Addresses ending in 0 or 255 are normally not valid host addresses though.

So host A and B should both be on the same network: and should not need a router because they are both on the same network.

If you place a longer mask on the host then you start to subnet the network. For example if Host A was then the network would be and if Host B was then its network would be Then you would need a router because the hosts are on different subnets.

But they are on the same subnet and cannot ping each other. They both show up in each other's arp cache and send the echo request but it does not make it to the other host.

I am using wireshark to see the echo reply so maybe that is staying local to the computer tcp stack and not actually be sent out the nic?
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions


Your logic is completely correct. What you are doing is called supernetting (vs. subnetting), which is the combination of several smaller networks (subnets) into a larger one using subnet masks. I use this all the time for routing rules and the like so I know it works, despite the objections of some of my counterparts.

I just tried this with two machines as follows (hey, I've heard of stranger problems with XP ;-) ) and have successfully gotten it to work. I'm thinking the problem may be elsewhere. Are you using a managed switch by any chance? I have seen some that will not switch traffic outside the subnets assigned to that VLAN.

Also, check for firewalls that may have their own subnet rules defined. Start with the Windows Firewall, which can be disabled in "services.msc" under the service of the same name (at least stop the service, if not disable it as well). Then check for 3rd-party firewalls... I know Comodo assigns /24 subnet masks to their "allow" rules by default as do many personal firewalls. Lastly, some firewalls come in other packages, such as Norton Internet Security and the like, so check in "protection suite" packages like that as well. Disable any you find or at least add blanket allow rules while testing (i.e. to permit all traffic (assuming you're not exposed to the internet).

Machine 1:
Machine 2:
Result: Pings both ways. Windows firewalls disabled. Fresh XP Installs on both ends.

Let me know how it goes.

Also, a unidirectional ping result like that is a classic sign of what I call an uneven test environment (both sides are not configured the same). For a ping to successfully respond, it must be transmitted, then sent back, meaning that the subnet masks on both are configured correctly. If they weren't, the results would be as follows:

-----Example #1-----
Machine 1:
Machine 1 Sub:
Machine 2:
Machine 2 Sub:

Machine 1 tries to send to, checks it against the subnet mask, sees that it matches, so attempts to send it locally (vs. sending via the gateway). Machine 2 receives the packet, checks it against the subnet mask, sees that it does not match, and throws it away.

-----Example #2-----
(Same addresses and subnet masks)

Machine 2 tries to send to, checks it against the subnet mask, sees that it *does not* match, so it sends the packet to the gateway, which "should" know how to route it to the 10.100.x.x network to reach Machine 1. Either there is no gateway, and you will get "destination host unreachable" in a ping test, meaning your machine knows the address isn't local, but can't find a route in its routing tables to direct the packet elsewhere (a gateway is just a default route, handling all packets not defined elsewhere in the routes). If you have defined a gateway, then Machine 2 will send it to the gateway, where it will be rejected or sent to that router's gateway etc etc, depending on the router's routing tables, and you'll see ping pause for a bit while this request times out (~2 secs) and then you'll get "Request timed out" meaning it wasn't routed, but no response was received from whatever router eventually received and denied the packet.

This is what happens when, for example, you're on a small home network like (or /24, as it's called in CIDR notation) and you try to ping It will get sent out your router, then out your router's default route to your ISP's router/layer 3 switch, and get quietly rejected because 192.168.x.x/24 is unroutable on the internet, just like 172.16.x.x/16 and 10.x.x.x/8, which are all private address ranges.

K... now I'm done ;-). Let me know...

Dragon0x40Author Commented:
thanks bcbigb,

Technically I believe 172.16.x.x/12 is the private address space. to

Can you try the same ip addresses that I used?

Not sure it will make a difference but...

I will check for firewalls.
My bad... I get stuck into multiples-of-8 thinking sometimes when working with subnets ;-)

It'll work... I just tried it both ways to make sure I wasn't missing a small detail, but I'm quite sure for several other reasons.

First, anecdotally, I've got several networks that take advantage of literally every /24 in the 172. and 192. block and many of them in the 10. block and the routes are all supernetted in the firewall using the private address space masks listed above. They also are subnetted in various combinations on the servers just like your network above.

Secondly, as I mentioned above, the fact that you're getting any pings through at all means they *are* able to talk to one another (there is no such thing as a unidirectional ping). The fact that pings work one way means they *must* work in the other direction as well, *except* if something on either machine is blocking them. Firewalls are simply the most obvious answer as they can analyze packets at a deep level and ignore them for myriad reasons. For ex, it could be blocking incoming ICMP Response packets on one side or outgoing ICMP echo packets on another or could even be tampering with ICMP in other ways (though I doubt you have a firewall that's this complicated, I have seen some home firewalls do wierd things in either broken or working states). ICMP is the protocol underlying pings. You can see a basic explanation of how ping works to corroborate this or for your own interest in the second paragraph at:


So, given what I've said here, I'm pretty sure you'll find a firewall or other device or piece of software (it could be something completely unexpected, though experience says this is incredibly rare as very few pieces of software have access to the ip stack at a low level like a firewall does/needs to have. I'm betting you'll see a firewall rule of some sort (many home software firewalls don't just have one set of rules, but have "safe networks" and all kinds of other things that completely affect traffic but don't show up in the normal rules list.  It'll likely say something on the order of "'Home' Network:     SAFE" or however your firewall displays it.

Oh, and if you see any Norton software on your computer, remove it. Everyone of Norton's tools are convoluted and often work in unexpected and unexplained ways. I have fixed medium-sized business networks simply by removing it. They have a thorough removal tool you can find by googling "Norton Removal Tool" and navigating through a couple of pages to grab it.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dragon0x40Author Commented:
I have a VPN client on my work laptop and when I shut that client down the pings started going through.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Switches / Hubs

From novice to tech pro — start learning today.