This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I found a bug in the firmware, after restoring the factory settings, when the ISP is on the 192.168.1.0/24 network segment, the device will automatically switch to the 10.0.00/24 network segment, and at this time when accessing the management page on the web site, a page "Your connection is not private" will appear, but this problem does not occur on the 192.168.1.0/24 network segment(meaning I need to disconnect from the WAN port of the ISP box first). After testing, I found that this is caused by the NCSI test failure of windows 10, it should be caused by the failure of NCSI test in China, but why there is no NSCI test in 192.168.1.0/24 network segment when accessing the web administrator? The current temporary solution is that I can either disable NCSI group policy in windows 10 on the 10.0.0.0/24 network segment, or I can only manually re-visit the official web page by typing "thisisunsafe" in the browser. So I hope Netgear will fix this bug completely in the next firmware release. Please note that need to clear your browser's cookies to reproduce this issue, not only that, but it also affects NMRP and TFTP firmware rewriting on the 10.0.0.0/24 network segment, after testing, TFTP tools get write errors when working on this network segment.
I just don't understand why it would fail to run NSCI on an SXK80 device after restoring factory settings and switching to a 10.x subnet.
Don't worry, me neither. Simply no time to waste more time on this special case. Keep in mind not many users have to factory default, and all this in the double-NAT context.
Is the problem prohibitive for bringing up a SKX80 (or for the sake of it the similar SXK50 or SXK30 system) from a factory default re-config?
Realistically, 99.9x% of these systems are configured once, and run forever. There it goes the expectation for a utility, beyond plain standard tftp - available on many different platforms and OSes. If it's not broken already as of writing, unlikely Netgear does spend time and resources on this 80/50/30 product line.
For my part, I'm done with this, as I don't own such one of these product, and never got one for Beta testing. Other community members seem to have the better contact to the Orbi Pro router team than me. I'm just yet another community member trying to help where he can. Netgear does not care for us at all. We're accepted to spend time and effort for free, but this is the end for now. One day, if I find a pre-loved European device, I might be willing to buy one for some Cents. Just like the BR500 I own for the fun or pun of it.
Said this: Sorry for asking silly questions - now you understand, why.
I found a bug in the firmware, after restoring the factory settings, when the ISP is on the 192.168.1.0/24 network segment, the device will automatically switch to the 10.0.00/24 network segment, ....
This isn't a bug - this is a long standing feature and implemented on all Netgear routers. Both 192.168.0.0/24 and 192.168.1.0/24 IP subnets are included when I have this right. When connecting the WAN to any device, like another NAT router for example, the default LAN subnet is changed from the 192.168.1.0/24 (and 192.168.0.0/24), the DHCP server is reconfigured.
Sigh, this can cause a lot of work if people "just for a test" connect the WAN to such a subnet, and the user does prefer not to factory default again.
I think you misunderstood or I didn't explain clearly.
When the WAN port of the device is connected to subnet 192.168.1.0/24, the LAN of the device switches to subnet 10.0.0.0/24, which is not a problem, because I was using an R7000 before using the SXK80, and it already had this feature.
The bug I'm talking about is that when the device's LAN is working on subnet 192.168.1.0/24, it will not activate the windows 10 client's NSCI function, but when the device switches to subnet 10.0.0.0/24 subnet, it will activate the windows 10's NCSI function to the extent that the web management page jump error in the screenshot occurs, unless the web management page jump error in the screenshot is first Turn off NCSI function.
The bug I'm talking about is that when the device's LAN is working on subnet 192.168.1.0/24, it will not activate the windows 10 client's NSCI function, but when the device switches to subnet 10.0.0.0/24 subnet, it will activate the windows 10's NCSI function to the extent that the web management page jump error in the screenshot occurs, unless the web management page jump error in the screenshot is first Turn off NCSI function.
No Netgear router, in fact no Linux system, does participate in any way (certainly not active) with Windows NSCI. This happens only on your Windows system(s).
But what I can't understand is why it only happens on the 10.0.0.0/24 subnet and is fine on the 192.168.1.0/24 subnet, whereas the previous device, the R7000, didn't have this problem on either subnet.
But what I can't understand is why it only happens on the 10.0.0.0/24 subnet and is fine on the 192.168.1.0/24 subnet, whereas the previous device, the R7000, didn't have this problem on either subnet.
Sorry I missed the key point, the problem I was talking about only occurs the first time you visit the web admin page after restoring the factory settings. When the device is restored to factory settings, if the WAN port is not connected, at this time the device works on the 192.168.1.0/24 network segment, no problem. When the device is restored to factory settings and the WAN port is connected to the ISP's box, because the ISP's box is working in the 192.168.1.0.0/24 network segment, at this time the device automatically switches to the 10.0.0.0/24 network segment, and the error reported in the screenshot appears. But my previous R7000 device, which works the same way, doesn't have the same problem, which is the main reason for the bug in my mind.
Actually the system is working as designed. If your host router already uses 192.168.1.1 and the SXR is designed to use same 192.168.1.1 subnet and the system detects this during the setup routine after a FR, then the system will avoid the conflict and and change itself to use the 10.x subnet. All NG routers do this. Not a bug in this regard.
Are you saying that the SXR is not providing internet services after it's been FR and setup from scratch, it changes to the 10.x subnet?
Just curious, if you change the 10.x IP subnet to 192.168.0.1 on the SXR, does the SXR work correctly then?
What is the Mfr and model# of the Internet Service Providers modem/ONT the NG router is connected too?
I mean when the SXR is reset and the subnet is switched to 10.x, it activates the NSCI detection on the windows 10 client and doesn't automatically redirect to the orbilogin.org url And when the SXR is reset and the subnet is working at 192.168.x, it will redirect to the orbilogin.org url directly I'm currently living in China, the ISP modem is a Chinese vendor, and the NSCI detection URL doesn't work in China. To be honest, I'm equally curious as to why the NSCI detection is enabled when the subnet is at 192.168.1.1, which works fine, but when the subnet is switched to 10.x.
In fact I understand what you are saying and the related solution, but the problem is that on this product, the issue I am feeding back only occurs when reset to factory settings and automatically switched to 10.x subnet, and that's the point, and I want to solve this problem. The fact that this issue does not exist when using the Netgear R7000 product, even after resetting to factory settings and switching to the 10.x subnet, means that this is not an issue with all Netgear routers. From what I understand, this should be caused by the fact that the DNS that comes with the device redirects to a different URL for the 10.x subnet than it does for the 192.168.1.0 subnet.
The only reason why the SXR is switching to the 10.x subnet is that it's detecting a upstream router that's also using 192.168.1.1 and upon a reset and setup from scratch, ALL NG routers will auto change to 10.x subnet to avoid the conflict as you can not have two routers using same subnet address. This is NOT a bug.
But the NSCI detection is triggered only on the 10.x subnet, not under the 192.168.1.1 segment, and not under the other Netgear routers under the 10.x subnet, which is the bug I'm talking about... do you understand this key point?
But the NSCI detection is triggered only on the 10.x subnet, not under the 192.168.1.1 segment, and not under the other Netgear routers under the 10.x subnet, which is the bug I'm talking about... do you understand this key point?
Again: The NSCI is a pure proprietary code implementation by Microsoft, and run on your Windows systems. You talk to the wrong people here.
I just don't understand why it would fail to run NSCI on an SXK80 device after restoring factory settings and switching to a 10.x subnet. On the other hand, Netgear's router R7000 has no problem after restoring factory settings and switching to the 10.x subnet.
I just don't understand why it would fail to run NSCI on an SXK80 device after restoring factory settings and switching to a 10.x subnet.
Don't worry, me neither. Simply no time to waste more time on this special case. Keep in mind not many users have to factory default, and all this in the double-NAT context.
Is the problem prohibitive for bringing up a SKX80 (or for the sake of it the similar SXK50 or SXK30 system) from a factory default re-config?
Realistically, 99.9x% of these systems are configured once, and run forever. There it goes the expectation for a utility, beyond plain standard tftp - available on many different platforms and OSes. If it's not broken already as of writing, unlikely Netgear does spend time and resources on this 80/50/30 product line.
For my part, I'm done with this, as I don't own such one of these product, and never got one for Beta testing. Other community members seem to have the better contact to the Orbi Pro router team than me. I'm just yet another community member trying to help where he can. Netgear does not care for us at all. We're accepted to spend time and effort for free, but this is the end for now. One day, if I find a pre-loved European device, I might be willing to buy one for some Cents. Just like the BR500 I own for the fun or pun of it.
Said this: Sorry for asking silly questions - now you understand, why.
