MVP 8400 & iPad won't reconnect to processor after reacquiring access point

klmyers

Anyone seen this? It is a simple home network with Linksys access points. There is an 8400 and an iPad. When the 8400 or iPad goes out of range of the access point, then later reacquires to the access point, neither panel will reconnect to the processor. The only way to reacquire to the processor is to reboot it. Any help would be appreciated.

ericmedley

I have seen this kind of thing before. You don't specify which router you're using but since you mention Linksys, I'll let you know that I've seen repeated problems like this with the old Linksys WGxxxxxx wireless routers and non-wireless routers. The symptom is the NI master just quits recievieng communications from it's IP port. All looks just fine but it's deader than a door nail. A reboot fixes the problem for some period of time (days) only to repeat again.

A coouple things seemed to fix this problem on many of the systems. 1) was forcing the NI to only use 10Mbps 1/2 duplex. You can do this by telneting in and taking the master IP connecion out of 'Auto' mode and force 10/half.

The other is not use the Linksys router. Since it's not that exensive in the first place it should be too much of an issue.

John Nagy

What does TELNET say about the connection?
You don't mention processor type or firmware. Particularly on older firmware, NetLinx connection cleanup is slower. We've seen many cases where a panel won't reconnect, and in telnet, you can clearly see the error reports of "192.168.1.181 already connected, ignoring duplicate" as the panel tries to reconnect. Because the NetLinx never registered the departure, it won't allow a "new" connection. Once started, this cycle only ends with a reboot.

New firmware all around reduces the chance of this to very close to nil. Close. This mostly happens in locations where operating at the fringe of range is common, and the panels flip on and offline very quickly, often enough to freak the NetLinx. You should see each online and offline event in TELNET, so there should be little mystery if this is the case.