There was a hard recovery included in version 1.51 and later. To use this method, unplug the module.

Plug it back in, wait 3 seconds, and then press and hold the button for 10 seconds.

The module will reset and reboot – with DHCP enabled.

Another question, were you upgrading the module when the failure happened, or did it just happen during normal operation?

Arghhh….

Upgraded the unit to v1.52 earlier today and got a number of hours of good use out of it. I was doing development today on my custom application so the use was normal but more active than everyday use. Things were working fine until I ran a test to see how quickly I could send consecutive commands to the XML socket after reading a post on this forum that the SHN Utility suite was set to do this .2 seconds apart. I sent three consecutive ‘GetVersion’ commands .25 seconds apart and it locked the unit up. I then tried all the various factory reset methods described in these forums and the best I got was the same result described in this post. The suggested remedy didn’t work so I then tried changing the unit’s IP address with the ‘NetCfg’ command through the SHN Utility suite. This seems to have completely killed the unit as I can’t even find it in the utility.

It’s very frustrating to have things like this happen on a system where it’s use is rather critical on a daily basis and I can’t afford downtime. If there are any other last ditch ways to recover this thing it would be appreciated ASAP.

I should have mentioned that I had the *exact* same thing happen as described at the start of this thread. Using the SHN utility, I tried to manually fix the IP information by sending the unit a ‘NetCfg’ command (DHCP on, but with a statically set IP on my 192.168.2.x subnet as well).

After applying this command, my DHCP server logs showed a normal looking interaction between the unit and the server and it was assigned its proper IP address, at least according to the logs. After the DHCP assignment happens, however, it is completely unresponsive to pings, connection attempts to its ports (e.g.: 8002, 80), or even the SHN Utility finder.

I just spoke to Al who walked me through the new DHCP reset procedure in v1.52 using the internal reset button on the left side of the unit. This procedure does consistently force the DHCP negotiation to occur but I still have the same result as mentioned in the prior paragraph. I’m running a portscan on the unit right now to see if anything is listening at all but nothing has come up yet.

One interesting thing I should mention for you, Paul, is that my DHCP server has been setup to assign the EZSrve a static IP each time based on its MAC address which was 00:40:9d:2b:75:1b. When the issue occurred as described by ryan1db at the start of this post, however, the MAC address changed to 00:40:9d:43:35:97. Everything that I’m seeing here makes me think that somehow the unit is getting through some sort of preliminary boot stage, setting up an initial network adapter (with the different MAC address), and then its failing to get into its secondary application stage. When I manually changed the IP address of the unit through the SHN Utility as I described above, I was “talking” to the initial stage, not the application stage. I don’t know if I’m off base here but I have a hunch this is sort of what is going on.

I have a TFTP server on my network and I’m thinking that the best thing might be to reflash the entire thing, boot image and all. Unless, that is, you have some other troubleshooting method I haven’t tried yet…