Link to home
Start Free TrialLog in
Avatar of Dragon0x40
Dragon0x40

asked on

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 255.255.0.0 No default gatway
Host B xxx.16.0.120 255.255.0.0 No default gateway

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

With a mask of 255.255.0.0 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 255.0.0.0 mask and one laptop could ping the other but not the reverse?

Does MS XP not truly understand networks or am I missing something?
Avatar of Rartemass
Rartemass
Flag of Australia image

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.
http://www.dd-wrt.com/wiki/index.php/Linking_Subnets_with_Static_Routes
Subnet masks can change the default behaviour more, and you can make different subnets based on a single number in the IP.
Example: 10.5.1.1 through 10.5.1.10 can be one subnet, and 10.5.1.11 through 10.5.1.20 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?
Avatar of Dragon0x40
Dragon0x40

ASKER

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 255.255.0.0 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 172.16.0.1 and end at 172.16.255.254. 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: 172.16.0.0 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 172.16.0.0 network. For example if Host A was 172.16.0.20 255.255.255.0 then the network would be 172.16.0.0 and if Host B was 172.16.1.120 255.255.255.0 then its network would be 172.16.1.0. 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?
Dragon,

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. 0.0.0.0/0.0.0.0) to permit all traffic (assuming you're not exposed to the internet).

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

Let me know how it goes.

~BC
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: 10.15.1.1
Machine 1 Sub: 255.0.0.0
Machine 2: 10.100.1.1
Machine 2 Sub: 255.255.0.0

Machine 1 tries to send to 10.100.1.1, 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 10.15.1.1, 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 192.168.1.1/255.255.255.0 (or /24, as it's called in CIDR notation) and you try to ping 192.168.18.124. 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...

~BC
thanks bcbigb,

Technically I believe 172.16.x.x/12 is the private address space.
172.16.0.0 to 172.31.0.0
http://en.wikipedia.org/wiki/Private_network

Can you try the same ip addresses that I used?

Not sure it will make a difference but...

I will check for firewalls.
ASKER CERTIFIED SOLUTION
Avatar of bcbigb
bcbigb

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I have a VPN client on my work laptop and when I shut that client down the pings started going through.