Windows Network Issue: ReadyNas Dissappearing Act (SOLVED)

[StephenB]

Hi Stephen B

Static IP address for PC was 192.168.168.167 and subnet mask was standard 250.250.250.0.

As it goes, I am now delighted to inform everyone that Netgear Support have finally put the fault down to a hardware problem and have agreed to swap the ReadyNas.

Fingers crossed for my 3rd ReadyNas Duo in 9 months

The subnet mask should have been 255.255.255.0 (not 250).

[Slasky]

Not to be a wise-ass here, but did the NAS also have the 250.250.250.0 subnetmask? Because a normal subnetmask for this address is 255.255.255.0

If the computer and the NAS has two different subnet-masks it will be defined as two different networks

[StephenB]

Not to be a wise-ass here, but did the NAS also have the 250.250.250.0 subnetmask? Because a normal subnetmask for this address is 255.255.255.0

If the computer and the NAS has two different subnet-masks it will be defined as two different networks

The NAS doesn't ever see the subnet address configured in the PC anyway, so a mismatch in itself is not a concern. Each device needs to determine if the remote IP address is on the local network or not. If either conclude that the remote address is off-net (using their mask), then the connection fails in that direction because there is no router.

If the NAS had the correct 255.255.255.0 subnet configured, it would certainly conclude that 192.168.168.167 was on the same subnet, and it would have reached the PC ok.

Figuring out how the PC would have treated the 250.250.250.0 mask is a bit more confusing, since the mask is not expected to contain holes. Given his static IP address choices, I think the PC would also conclude that both devices were on the same network, and not attempt to route. That is because (192.168.168.167 & 250.250.250.0) is equal to (192.168.168.168 & 250.250.250.0). So my guess is that the mistake is harmless in this case.

[Slasky]

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"

I guess its a typo, unless the NAS or the computer can parse an invalid subnet-mask

[StephenB]

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 (5.5.5.255). The start address would be 192.168.168.0 and the end address would be 197.173.173.255. 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 - 197.173.173.255 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.

[Nuzzington]

Hello All

We'll my thread did indeed go off topic (subnet masks?!). On that point, at the end of the day, while I would have loved to have been able to ensure that both my PC's subnet and the ReadyNas's subnet masks were the same, again, I was unable to administrate the ReadyNas at the time (no network connection, no direct connect to PC - see above thread for details).

So....now for a Netgear support update:

Netgear did indeed replace the unit, only for me to have the exact same issue!! Clearly it’s either a configuration on the REadyNas or something on my network / firewall (or both) which are causing the issue. I can't locate the source though, having tried countless re-wirings. I have one last attempt to see if I can turn off DHCP, create a mini-internal network with a few machines in the office (not connected to the Internet) and use a basic switch and see how the ReadyNas likes that.

I did have some success in that I have finally got the ReadyNas to direct connect to one of our office PC's so we're just about able to administrate it (although on a basic level as this machine is now off the rest of the network). I can also report that when I slotted back my x2 HHDs into the unit (you must get them the right side as before) there were no issues and I did not need to use my config backup. All my original shares remained, etc. however I'm wondering if it is indeed my share set-up which has resulted in my network issues. At this point I am gearing up for a full factory re-set on both the unit and my HDDs to see if that helps.

I am also looking into a Windows based Nas solution as I've had enough and want something simple and familiar (I don't have a clue about Linux)

I'll keep you all posted...

[Nuzzington]

Dear All

We have solved the issue - FINALLY!!!

It would appear that (as suspected earlier) the issue lay with our Firewall, which also manages DHCP. To circumvent the use of DHCP, I assigned each computer and the ReadyNas an IP within our local range, pairing it with their respective MAC addresses using ARP.

I was able to edit this on the ReadyNas once I'd direct-connected it with my PC.

I also ensured that the subnet mask and DNS details all matched throughout the network and VOILA! The ReadyNas became available in our network again

I would add that share permissions seems to be all out of place and I have had to do a blanket 'read/write' access for everyone for the time being.

I would also add that I did have to work this solution out myself; it didn't seem to occur to the Netgear support team to direct me to the ReadyNas's IP settings (Doh! Or should I have not expected this?)

Anyway, I hope this offers some solution and peace of mind to anyone else going through something similar.

Regards

Nuzz