SNMP reset / reboot

A reboot string for the WG302 and WG302v2 woul also be nice.

Best Regards

Jan Jepsen

Hi guys,

I have found the SNMP command to reset the WG102:

finesnmpset.exe 10.10.10.10 private 1.3.6.1.4.1.4526.4.3.9.1 integer 1

This works well, and can be scripted easily.

I found details of the wg102 MIB in the latested firmware download from Netgear for the WG102.

Enjoy.

I would guess that if you can reset the access point using SNMP that it has not "locked up" as per your first post.

fordem wrote:
I would guess that if you can reset the access point using SNMP that it has not "locked up" as per your first post.

Yes...If it's hung you can't reboot it. But what he means to do, like most of us have to do with these Netgear WiFi AP devices, is to setup a script to preemptively reboot the device before it locks up. I reboot my wg102 devices every Tuesday evening at 11pm. Before I started doing that, they would lock up about every other Wed (the busy day in the office). It was worse before the version 8 firmware, but it's still a consistent problem.

I would love to see this fixed in a new firmware.

psyclops wrote:

Yes...If it's hung you can't reboot it. But what he means to do, like most of us have to do with these Netgear WiFi AP devices, is to setup a script to preemptively reboot the device before it locks up. I reboot my wg102 devices every Tuesday evening at 11pm. Before I started doing that, they would lock up about every other Wed (the busy day in the office). It was worse before the version 8 firmware, but it's still a consistent problem. I would love to see this fixed in a new firmware.

If it is that reproducible, it suggests that there may be a problem that causes it to lock up, have you ever tried to pin point it?

I've seen routers that literally run out of resources and appear - see below - to lockup when there are too many connections - as in torrents - or when a spam mailing virus gets loose on the network.

The reason I said appear to lockup, is that some routers and access points can only be managed through a web interface, I've had Cisco product that appears to be locked solid, no routing, no web interface, but still accessible through telnet or the console port, thus allowing me to actually determine why it had apparently locked up. At one installation, I went so far as to leave a console cable connected and hyperterminal running so that I could capture all of the console messages.

Ever wondered why every other Wednesday and not every Wednesday?

fordem wrote:

If it is that reproducible, it suggests that there may be a problem that causes it to lock up, have you ever tried to pin point it? I've seen routers that literally run out of resources and appear - see below - to lockup when there are too many connections - as in torrents - or when a spam mailing virus gets loose on the network. The reason I said appear to lockup, is that some routers and access points can only be managed through a web interface, I've had Cisco product that appears to be locked solid, no routing, no web interface, but still accessible through telnet or the console port, thus allowing me to actually determine why it had apparently locked up. At one installation, I went so far as to leave a console cable connected and hyperterminal running so that I could capture all of the console messages. Ever wondered why every other Wednesday and not every Wednesday?

I haven't tried that hard to pinpoint it. But it does seem to be a common complaint from more then just a few users of this product. And like I siad, if i reboot the access points once a week, they don't lock up. It would seem odd that if i simply reboot the access point, before the traffic hit, it would then be able to handle a virus , or spam or BT 'storm'.

It's not every other wed...but thats just the day it gets the most use. The device will run longer under lighter loads...and locks up quicker under heavier loads. And the device hang issues is consistent with the 2 devices i have in service.

If they do somehow survive on their own for longer then a couple of weeks with out a reboot...i have seen a few times where the devices will hang, and then lose their configuration information. I then need to reconfigure, or upload the config file that i learned to save off the device.

Again, if i reboot the devices about once a week...they work like a charm.

Hi there,

I also bought 2 WP102 a short time ago for using them as a point 2 point bridge.
So far it works as expected, but I also have the problem, that the 2 APs won't answer to pings (nor can I get access to the web interface or can read snmp values) after a few days. Sometimes the come back to life sometimes not!
There is not much traffic over the wireless bridge. But if the devices start to "not answer" pings the wireless speed is horrible. After a simple reboot of the devices everything works fine for a few days. They both are on FW 4.0.16 (not upgraded).
I also look around in the web and found a lot of discussions about this problem.
So at first I'll try do do the "snmp write reboot" stuff.
One strange thing I just discovered... Because I have this problem now and have no physical access to the devices I tried something strange. I disabled and then enabled the switchport where one of the devices is connected to... and this WP102 is "pingable" again. But I can't acces the other side :-(

So any help welcome! Maybe a new Firmware (even Beta!)

Greetings from Germany

Juergen

Or you can use wget to reboot the netgear switch through the WebUI like this:

wget -v --no-check-certificate --http-user=admin --http-password=password --post-data="reboot_ap=1" https://xxx.xxx.xxx.xxx/ureboot.htm

I'm using it on a handful of WAG102s in an office environment ... I reboot them every night at 2am and that seems to prevent the hangups discussed above.

- JB

Could you explain the --post-data in detail.

cjiwonder wrote:
Could you explain the --post-data in detail.

I can explain this as I just figured it out for the FVS114. :) The post data is the form submission information you find when doing a view source on the original html page from the router's web interface. You'll see something like name="reboot_ap" and value="1" in the ureboot.htm source.

Using this and a bunch of guessing and reading, I figured out how to make a reboot script for my FVS114.