NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Device blocking does not work on 870
I have an 870 system with router firmware V10.5.20.4_1.3.5. Device blocking does not work properly. The only time it worked is when I set a device to be blocked and happen to restart the router. When I went to unblock it, I also had to restart the router for that to work.
In the web UI, nothing works at all. I browse to Advanced >> Security >> Access Control. When I select a device and hit "Block" I get a pop-up that says "Do you really want to block access to selected device(s)?" I hit OK and then the page reloads and the same exact device still says "Allowed" next to it.
In the iOS app, the device will turn red but that is not reflected in the UI and has no affect.
When I inspect what is happening with dev tools, I see a HTTP POST request to /dniapi/accessControl with the following payload:
acl_enable=1&acl_default_policy=allow&display_allow_no_connect_sta=&display_block_no_connect_sta=&sub_list%5Bindex%5D=0&sub_list%5Bdevice_name%5D=&sub_list%5Bmac_addr%5D=&sub_list%5Bacl_strategy%5D=&sub_list%5Btype%5D=add&acl_strategy=0&action=save
Here is a pretty format:
acl_enable: 1
acl_default_policy: allow
display_allow_no_connect_sta: ""
display_block_no_connect_sta: ""
sub_list:
index: 0
device_name: ""
mac_addr: ""
acl_strategy: ""
type: add
acl_strategy: 0
action: save
Then the UI does a GET request to get the device list and my device still has:
"acl_strategy": "allow", in the JSON response.
Having to reboot the router for these settings to work is a subpar experience.
Is this a known bug or is there a workaround without having to reboot the router to block and un-block devices?
29 Replies
This is actually the payload when trying to use the block button:
action block
index 46
acl_enable 1
acl_default_policy allowThanks for the detailed explanation. Correct. This is NOT what is supposed to happen. On other Orbi routers, using the Security->Access Control page to change a device from "Allowed" to "Blocked" pops up that question (Do you really?) and the device changes from Allowed to Blocked.
Guessing that this 870 system has passed the magic 90 days of 'complimentary support'?
Perhaps someone on the Forum who has an 870 system can reproduce this situation. (I do not have one, sorry.)
Could you provide instructions on how to use "dev tools" to capture the web traffic between web browser and Orbi router?
(some of us would like to reproduce this, but are not experienced with ..... <whatever the hell you did>)
On Chrome, I go View > Developer > Developer Tools > Network tab. Then you can see the network traffic being sent from the router UI to its backend with the commands for blocking, etc (that don't actually work).
Try setting up some IP address reservations for devices you are wanting to control first.
Also, Be sure to disable any MAC Address randomizers on phones and pads while at home:
https://community.netgear.com/kb/en-orbi-knowledge-sharing/netgear-mobile-applications-and-androidapplewindows-devices-faq/2457046This has nothing to do with the ACL feature working properly. The MAC addresses of the devices I'm blocking have not changed and can not change. Also, even if they were, the feature itself should still work and the router config should be properly updated with the device showing blocked. This is a bug.
Try setting up some IP address reservations for devices you are wanting to control first.
I'll check with my 870 series system thats online today as well on this.
Note the NAS and PC I was using were both connected via switches, so it is likely that the switches still had the NAS in their MAC tables. Still, the NAS should not have gotten the IP address back when it rebooted.
I have observed this on other Orbi models. My impression is that Netgear's implementation of Access Control does not match our human expectation. i.e.
- Access Control does not prevent connection. It prevents traffic flow through the router. Thus
o A wired device will still receive an IP through the DHCP process, and
o A WiFi device can still complete a WiFi "connection" and receive an IP address, but - Any communication that passes through the router will be blocked.
- Any communication that does not pass through the router because it is confined to the level 2 Ethernet switches will continue.
- Thus a PC wired to the router can communicate with a wired NAS that is connected to the router (even through switches), but
- If one of the devices is 'wired' to a satellite, that will force the traffic to flow through the router, which will block it.
As evidence, consider the Access Control table. When a device appears in the table with the label "Blocked", does it display an IP address?
Netgear's implementation of Access Control does not match our human expectation.
It's clearly not the normal MAC address implementation, since it does allow connection. It is apparently just doing layer 2 filtering.
I haven't tried "block all new devices from connecting", I guess that might be more aligned with what I expect. One would hope that adds admission control to the filtering.
Still, the help text says
When a device is blocked, it would only be able to get an IP address from your router, but it won't be able to communicate with other devices, nor it would be able to connect to the Internet.
That is definitely not the case with the 870 (based in my wireless iPad test). I don't know about other models, since this is not a mechanism I've ever used.
I do understand the limitations with wired - local streaming isn't disrupted on my network even when I turn the router off. Layer-2 forwarding is enough to keep all the wired stuff working. But I had expected that the router wouldn't give the NAS an IP address when I rebooted the NAS.
- Access Control does not prevent connection. It prevents traffic flow through the router. Thus
