NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
TLS 1.3 Support
Given that your entire product line of ProSafe Smart switches only supports up to TLS 1.0, I'd like to suggest that you start working on making TLS 1.3 available. Especially, since TLS 1.2 has been around since 2008 and you should really be embarassed that your business line of switches only support insecure communication methods.
Support 4096 bit SSL key length on GS110TP
The GS110TP supports only a max SSL key length of 2048 bits. This is a real problem for modern PKI infrastructures where - at least - the CAs almost always use a 4096 bit key length. Given that the GS110TP is still sold today I hope hat this could be corrected in a (near) future firmware update.
Temperature monitoring and control on Smart/Plus switches
I own an XS724EM 24-port 10G switch. It runs warm to the touch, and the default fan profile seems to err on the side of low noise rather than cooling. Tech support says that the switch is designed to spin down fans entirely unless a certain temperature threshold is reached. Personally, I would prefer to see more aggressive cooling, even if meant slightly more fan noise. So my feature request is twofold: Basic temperature monitoring (ambient, internal) in the admin GUI. All I want is a simple readout of how warm the switch currently thinks it is. Basic manual fan control in the admin GUI. I'm envisioning something like the "Cool/Balanced/Quiet" drop-down menu (see image) found on ReadyNAS units. I know the managed switches have functionality along these lines. To me, this basic temperature monitoring and control seems like it should definitely be included on Smart/Plus switches too.
More information in the log to be able to tune the DDoS (due to "False Positive")
Problem statement: GS324T deactivates the port due to suspected DDoS, but most likely it is a false positive - tuning is not really possible due to the missing information (in the log) about the reason(s). The Switch log shows only one line: <11> Apr 11 04:55:29 Main Home Switch-1 DOS[dtlTask]: dos_api.c(1928) 2115 %% ERR Interface g12 has been shutdown by DOS attack notification. Based on the reply on my post in the forum here, it looks like there is no possibility to have more information in the log, and identify the real reasons, what exactly has triggered the port deactivation. Hence, there is no possibility to "tune" the DDOS settings and avoid the "False Positive". In other words: only "blind" tuning possible. Ask: To have the possibility to get more details about DDoS to the log e.g. by having different log level for DDoS, up to the additional information what exactly / what "active" parameter in DDoS settings has triggered the port deactivation. Thanks, AndreyOrbi Pro AC3000 (SRR60) - Support for Vlan segmentation
When I bought this business class mesh system about a year back (1 router and 2 satellites), tech support stated that the product being a business producr does not have a built in firewall and I should procure an external firewall. A year back tech support stated that vlan segmentation and vlan to ssid mapping would be coming in a later release. At this point indeed the feature came in a later release of hardware in AX6000. I was talking to tech support today again as I purchased a decent hardware firewall and I would like to have the same vlan feature Iin the AX6000) of vlan 1,10,20 and 30 married to SSID with trunking available on the AC3000 as this should be basic network fiormware/software update and has nothing to do with wifi6 which may demand a new chipset. In the very least I need to segment the IOT stuff from business traffic. Can you please integrate proper vlan/ssid mapping into the AC3000 (SRR60). The way this should work is a user joins SSID Wireless 1 and should be part of the corresponding VLAN/Subnet and the AC3000 would run in AP mode and trunk (80-2.1q) the vlans via the WAN port to the Firewall which provides the IP routing, dhcp and all other services. I am not looking for wifi-6.Remove SSL 2.0 and 3.0 and TLS 1.0 from Embedded https Web Servers
Many NTGR business products still have SSL 2.0 and 3.0 and TLS 1.0 as options - nowadays these are obsolete and should be removed, TLS 1.2 is in the field for more then 10 years, so there should be no more prehistorical Web browser still requiring anything different.GS724Tv4 IGMP Snooping on a VLAN breaks IPV6 Multicast on same VLAN, Still after over 1.5yrs.
The "workaround" about doing it at port level is not 100%, seems alot of Multicast stream are missed and not reported in the switch in that config. When setup at the VLAN level it works 100% like its suposed to for IPv4, but ofcourse that breaks IPv6. This needs to be addressed, and apprently its on this whole "family" of switches based on other post here. EDIT: and this is with the latest firmware of 6.3.1.16Add TLS 1.2 Support
Please add support for TLS 1.2 to GS108Tv2 switch range. Currently only TLS 1.0 is supported on firmware 5.4.2.35. TLS 1.0 is considered deprecated by IETF: https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-12 <extract> 4. Do Not Use TLSv1.0 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of TLS MUST NOT be permitted. Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be configured to prevent interception, though using the highest version available is preferable. Pragmatically, clients MUST NOT send a ClientHello with ClientHello.client_version set to {03,01}. Similarly, servers MUST NOT send a ServerHello with ServerHello.server_version set to {03,01}. Any party receiving a Hello message with the protocol version set to {03,01} MUST respond with a "protocol_version" alert message and close the connection. Historically, TLS specifications were not clear on what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version could be selected to maximize interoperability, though no definitive value is identified as ideal. That guidance is still applicable; therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate TLSv1.0. </extract>Letter of Volatility
Please ensure NTGR does publish the Letter of Volatility (LOV) along with the product support download pages. We see that requests for LOV are taking reasonable bandwidth in the community support, temporary file downloads will be enabled with valid for a few days only. This makes the replies virtually useless, because the download is no longer available. So we see requests for the same product LOV again, or we get new posts. All this can be avoided... Thank you for consideration! Regards, -Kurt
