AnonymousJune 27, 2008 at 2:58 pmPost count: 3
it’s stuck on 10.53.33.130 i think, which is a weird IP, and not coming from my DHCP. according to your windows software i used to even figure out that it was working at all, it’s manually set to that IP, but i can’t use the software to change it, reboot it, or edit it. after setting my ip to be in that weird 10.53.33 network, i could get it to ask me for a user/pass in a browser, but it won’t take the one i had, and it won’t take the default one. the login is a netsilicon one, so maybe the little netsilicon chip got reset back to it’s original firmware or something. holding the button for 2-7 seconds or for 10 or more seems to reboot the device, but it does not change anything, and the IP stays exactly the same.
any ideas what i can do or is it bricked?AnonymousJune 27, 2008 at 3:17 pmPost count: 408
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?AnonymousJune 27, 2008 at 4:02 pmPost count: 3
normal operation. i tried the unplug, replug, wait 3 seconds, hold for 10 seconds, but i’ll try it again when i get home tonight.AnonymousJuly 11, 2008 at 6:11 amPost count: 31
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.AnonymousJuly 11, 2008 at 10:45 amPost count: 3
works now, after I got more specific instructions via email to reset it. I’ll post them once I’m on my computer insted of my phone.AnonymousJuly 11, 2008 at 9:53 pmPost count: 31
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…
- You must be logged in to reply to this topic.