Slasky wrote:Unless his router is able to route the traffic between those two subnets then they shouldn't see eachother, as the subnet-mask defines the network (start, end, broadcast address and so forth).
And as you stated, the subnetmask 250.250.250.0 should be invalid, as it contains a wrong syntax, removing bits in an octet before the previous one is "depleted"
Certainly it is invalid.
If you decide that a target address is on-net/off-net by comparing with an address range, then the 250.250.250.0 mask will result in a much wider address range. The method I am thinking of is to get the base network address by ANDing the IP address with the mask, and to get the end address by ORing that base address with the reverse mask (126.96.36.199). The start address would be 192.168.168.0 and the end address would be 188.8.131.52. This is much bigger than it should be (and gets the wrong answer for many addresses because of the invalid mask), but that is ok for communicating between these two devices. The test I did in the earlier response handles the holes correctly, and also works out ok for these specific addresses. So I think both devices are aware that they don't need to route.
Computing the right broadcast address is an aspect I hadn't considered. The 250.250.250.0 system would in fact compute a different broadcast address - 184.108.40.206 using the normal formula, instead of 192.168.168.255. (since the broadcast address is
the ending address). IP broadcast packets certainly reach the NAS (they have to, since it is directly connected). However, the IP stack in the NAS probably ignores them, since they are not addressed to the broadcast address it computed. I am not sure exactly what would break though. The ARP broadcast request should still work, since it is using ethernet
broadcast (mac address of ff:ff:ff:ff:ff:ff) with a source IP address of 192.168.168.167 and a destination IP address of 192.168.168.168.
Anyway, we are off topic. Hopefully the wrong mask was indeed a typo.