raider_fawns

Gotcha. Well even if the new devs don’t understand why it was changed (I’m sure a lot is different between the major versions with the TC stack added in) I can’t imagine that’s intended behavior to cut off both wan and opposite band local access simultaneously, so I hope they are able to address the bug. I’m almost to the point of restoring and attempting to downgrade, but I prefer DumaOS v3 other than this issue, which is frustrating, haha.

Thanks Fraser, let me know what they say. It’s completely reproducible if I can help in some way.

Hi Fraser, had a busy weekend but did get around to some testing. So the issue seems to only happen with devices on different bands. If they're on the same band, they continue to be reachable locally with a Traffic Controller rule in place, but cross-band communication is immediately cut off with a rule enabled. Since the smart home device I'm targeting only operates on 2.4 that explains why this is happening, since the other devices are on 5GHz. Did something change from v2 to v3 firmwares that silos the bands off from each other? It was working cross-band locally with the "Block Device" checkbox enabled on the target in Device Manager under v2 firmware, and the 2.4GHz local access only devices were still talking to 5GHz devices without issue. I have discrete SSIDs for each band, both on v3 and previously on v2, so nothing is different there. Thanks for any insight!

Good questions, I’ve only tried with one other device so far which worked as expected with the traffic controller rule. I’ll have to test that rule with some other devices this weekend. Connected via WiFi, no switch, bridge, extender etc. It is a smart home device, and not something I can directly log into and check connectivity, but have to instead observe it from other devices. It’s strange that it’s visible and pingable and wholly useable from the local network with no traffic rule, but immediately unavailable with the rule enabled. There’s no need for the device to have any external connections which is why I’d like to be able to turn it off somehow! I’ll apply the rule to some other devices to see how they behave and let you know, thanks!

Hey Fraser, thanks for the suggestion! I thought the same thing, but the results of enabling Traffic Controller were the same for the device in question and it immediately disappears locally, ping suddenly shows request timeouts. Something must be strange with the device in question, as I tried Traffic Controller with a third unrelated device and in that instance it behaved as expected: locally accessible and continuing to respond to pinging, but with no access to the internet. I used that same working TC rule and just changed it back over to the desired target, which again just immediately stops responding. I'm at a loss as to why the different devices react differently to the same rule, very frustrating haha.

Hello, I've noticed that since updating my XR500 to a DumaOS v3 firmware I'm unable to restrict internet access without also affecting local access. On a DumaOS 2 firmware, the "Block" toggle in Device Manager would accomplish exactly this, but on v3 it cuts off all device communication it seems. I'm able to receive ping responses sent from a device on the local network while the target is not blocked in device manager, as expected. Once the target device is set to blocked, local ping attempts immediately time out. How can I keep the target reachable on the local network while preventing only internet access? Thanks for any help! XR500 V2.3.2.134, DumaOS Version 3.0.202