NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
GS724TV6 - Refuses to get DHCP address non 192.168.0.x address
I have two GS724TV6 that I want to configure and set up on my network. The network is a Verizon FIOS router that serves as DHCP to a Netgear GS724TV4. I also have a few 8 port Netgear switches on the network (GS108EV4) and a GS316EPP. All of these get DHCP addresses perfectly fine. - Neither get DHCP addresses - They take the default address of 192.168.0.239 - I was able to configure a PC as 192.168.0.1 and connect to them - I assured that they were both configured as DHCP - When I configured one to 192.168.1.30 with a gateway of 192.168.1.1 (the Verizon Router) it would be seen when I plugged it into the network. - I set up it's MAC address in the router to assign it 192.168.1.30, the router never assigned the address - I upgraded the firmware to 7.0.0.14 from 7.0.0.12, no change - The Network Discovery Tool doesn't see the device on either the 192.168.0.x or 192.168.1.x configurations How to I get it do get a DHCP address from my regular network like all of the other 40 devices seem to be able to do?We have a 4 unit stack of m4300-52G switches running firmware 12.0.19.15.
We have a 4 unit stack of m4300-52G switches running firmware 12.0.19.15. Suddenly as of today SNMP stopped working fully, i cant accces the webinterface, cant access webinterface from OOB and cant even use the physical console to get into the master unit of the stack (unit 1) . The member units 2 to 4 are still up. Even set sup-console or session start to unit 1 from another member unit hangs. So there is nothing i can do to even debug when connection to the master unit is impossible. Its very much related to your issue and the other forum. I'm also wondering if the issue is fixed in the new firmware release. There is no hard conformationWAX210 Band Steering Made AP hanging
I got a new WAX210 used in the office. Everytime I enabled band steering in the configuration, the AP hanged with red lights blinking. Then I can no longer login to AP unless factory reset. The AP has loaded the last firmware V1.1.0.36. Is it hardware issue or firmware issue? Does anyone have similar experience?WAX638E Truncates MPSK Table
We have around 30 APs, about 24 of them WAX638Es, and the rest 620s, with one 610Y. We've deployed MPSK on a network, with 43 key entries. Currently, the full table copies to the 620s and 610Y, and users can instantly authenticate as expected. The 638Es, however, only copy in the first 8 entries, whether they are on PoE+, PoE++, regardless of switching config, and the issue persists after both an insight remove/re-add and a factory reset and re-add. I have an open case on this issue, started two days ago, but I wanted to post it here for posterity. JonahWAX210 Firmware 1.1.0.34 Bug – SSID Password Complexity Incorrectly Enforced
Hi everyone — I’m seeing what looks like a firmware regression on the WAX210 after updating to v1.1.0.34, and I want to report it in case others are affected. After updating, the AP now refuses to save any configuration changes (even unrelated ones like just renaming the Access Point). The UI throws this error: SSID1: SSID passphrase length must be between 8 and 63 characters, and contain at least one uppercase letter, one lowercase letter, one number, and one special symbol. This happens even when the SSID password is not edited at all. The AP loads the existing (valid) WPA2/WPA3 passphrase and flags it as invalid due to a complexity requirement that didn’t exist before. This appears to be the AP Login Password complexity policy being mistakenly applied to SSID passphrases, which contradicts the official manual. SSID passwords for WPA2/WPA3 should only require 8–63 characters. Reproduction Steps Update WAX210 to firmware 1.1.0.34 Log into the web interface Make any change (example: AP Name only) Click Apply The SSID password complexity error appears, even though SSID settings were untouched Impact. The AP cannot accept any configuration changes unless the SSID password is replaced with a much more complex passphrase. This forces a complete re-key of all connected devices. Expected Behavior Per the WAX210 User Manual, SSID passphrases should be valid with: 8 to 63 characters No requirements for uppercase/lowercase/digits/symbols Those rules worked correctly in previous firmware versions. Current Workaround Rolling back to firmware 1.1.0.25 or 1.1.0.20 fully resolves the issue. Request Can Netgear please confirm whether this is a regression in 1.1.0.34 and escalate to the firmware engineering team? This issue effectively prevents configuration of the device. I can provide: Screenshots of the error dialog A configuration backup A short video showing the issue Exact hardware revision and serial if needed Thanks in advance.M4300-52G-POE+ Bricked Recovery Method
Anyone knows how to recover from a power outage that bricked my M4300 ? M4300-52G-POE+ We had an outage. Power came back on, then the unit boots but none of the 52-ports came back up. The OOB port lights up when plugged into, but nothing. Then I console it and got the readout. It didn't even get past port0 and stalled out. Here is the vid: https://www.youtube.com/shorts/7Q5zGWaNzxY About 8 seconds into it and the screen will show upWAX610 – 802.1X Supplicant on Wired Uplink Port – Feature Availability
Hello NETGEAR Support Team, I am currently deploying a network infrastructure using several WAX610/WAX620 access points (firmware up to date) combined with a MS510TXPP managed switch. As part of my security architecture, I would like to enable 802.1X port authentication on the switch ports connected to the access points, in order to prevent unauthorized access in the event an AP is physically removed and replaced by a rogue device. This requires the WAX610 to act as an 802.1X supplicant on its wired uplink/LAN port — independently from the 802.1X authenticator role it already plays for wireless clients via RADIUS. After reviewing the WAX610 user manual thoroughly, I could not find any mention of this capability on the wired port. My questions are: Does the WAX610 currently support 802.1X supplicant functionality on its wired uplink port? If not, is this feature on the roadmap for a future firmware release? This is a fairly standard enterprise security requirement, and I believe many customers deploying WAX610 in environments where physical security of the AP cannot be fully guaranteed would benefit from it. Thank you for your time and assistance. Best regardsGS728TP v1 failed update
Can you tell me if it's possible to restore the GS728TP v1 after a failed update? The firmware was 6.0.1.14. I updated to the latest firmware 6.0.1.30 via SCC (Smart Control Center). SCC (Smart Control Center) reported that the firmware was updated and the switch would reboot. But after this update, the switch keeps rebooting. How can I restore it?Nighthawk M2 IP PassThrough stops working when idle
So I have a Nighthawk M2 in IP PassThrough with a VPN tunnel uplink over time it disconnects from 4G network for some reason and as soon as I login to the Nighthawk it springs to life. firmware NTG24_10.19.03.00 So anyone else having this problem? the ISP is o2WAX630E v12.8.0.6 log messages
I’m hoping someone from Netgear support can pass this along to engineering. Since updating my multiple WAX630E access points to firmware version V12.8.0.6, all of them are continuously displaying the following messages in the system log files. New messages are generated about every second. May 3 09:26:44 nddmp[5641]: nddmp total time to execute = 1.000000 seconds May 3 09:26:43 nddmp[5641]: NDDMP: data received from lighttpd = "[REMOVED]" May 3 09:26:43 nddmp[5641]: nddmp total time to execute = 0.000000 seconds May 3 09:26:43 nddmp[5641]: NDDMP: data received from lighttpd = "[REMOVED]" May 3 09:26:43 nddmp[5641]: nddmp total time to execute = 1.000000 seconds May 3 09:26:42 nddmp[5641]: NDDMP: data received from lighttpd = "[REMOVED]" May 3 09:26:30 root: monitor_stuck is running May 3 09:26:14 root: monitor_stuck is running May 3 09:25:58 root: monitor_stuck is running May 3 09:25:42 root: monitor_stuck is running