192.168.0.1: breakage (?)

[MasterKia]

Prerequisites

• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• I am running the latest version of uBlock Origin

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

URL(s) where the issue occurs

http://192.168.0.1

Describe the issue

This is the address for my router panel login.

I don't see any actual breakages, but is this blockage an intended behavior?

Screenshot(s)

https://user-images.githubusercontent.com/17685483/205264958-0ecc08d8-d96b-46db-94a6-8b9852e60ef7.png

https://user-images.githubusercontent.com/17685483/205265107-bb44e25f-e3a2-4cfe-a304-3185016a732d.png

uBlock Origin version

1.45.2

Browser name and version

Firefox 107.0

Settings

• Block Outsider Intrusion into LAN

Notes

/^\w+:\/\/192\.168(?:\.(?:[1-9]?\d|1\d\d|2(?:[0-4]\d|5[0-5]))){2}[:/]/$3p,domain=~0.0.0.0|~127.0.0.1|~[::1]|~[::]|~local|~localhost

This filter blocks xhr requests like http://192.168.0.1/img/attached_device_hover.jpg

[MasterKia]

@gwarser

[gwarser]

Looks like third party request to your router, so filter work as intended. However, something may be wrong with partyness - router UI is handled by service worker? Do you have any add-on for managing your router? If I recall correctly, only requests from add-ons are classified as bahind-the-scene nowadays.

@gorhill ?

---

For example, I see this on GitHub, because of Refined GitHub add-on:

+0			behind-the-scene	0,3	xhr	https://api.github.com/graphql
+0			behind-the-scene	0,3	xhr	https://api.github.com/graphql

[krystian3w]

Also behind of scene is badly save in comment as all URL:

! http://behind-the-scene/
||Foo-network-filter-made-form-logger # possible use service workers like Google Fonts (?)

Invalid on DNS level.

[MasterKia]

I don't have any add-ons for managing my router and I just visit 192.168.0.1, I'm connected to it using Wi-Fi.
Can it be router-related?

[gwarser]

Maybe try browser dev tools to find from where these are requested? ("Initiator" column?)

[MasterKia]

Here's some screenshots, strangely I can't find the blocked requests in the network dev tools.

https://user-images.githubusercontent.com/17685483/205444013-864b74a0-f861-4df2-a1e8-5d2b12dc2a37.png

https://user-images.githubusercontent.com/17685483/205443914-6cfdc8c1-c3f6-44b5-a101-17379da08d12.png

[gorhill]

It's difficult to help with screenshot which leave out most of the information. As per your scroll bar, there is a lot of xhr made, did you scroll all the way to find errored requests? Blocked requests should have a size of 0, so you could sort by size to bring those blocked requests are listed first.

[gwarser]

In Nightly I can see these b-t-s requests in Ctrl+Shift+Alt+I "Browser toolbox", but no info about "initiator" here (for Refined GitHub requests) only fetch keyword. They are also visible in Ctrl+Shift+J Browser console, when configured to show requests, but not much info about the reason here.

[MasterKia]

There was nothing useful in the rest of the scrolling, all of them were just the same goform xhr requests.

[MasterKia]

Blocked requests should have a size of 0, so you could sort by size to bring those blocked requests are listed first.

[gwarser]

F1 or dots menu in top right -> "Enable chrome and add-on debugging...", "Enable remote debugging".

Now Ctrl+Shift+Alt+I should allow to enable "Browser Toolbox" (should be also in browser menu -> More tools).

These requests should now be visible there. I still don't know how to locate their source/initiator.

[MasterKia]

I still don't know how to locate their source/initiator.

Just says "fetch".

[DandelionSprout]

To the degree I've researched this issue, it seems to me to be a bug wherein $3p cannot identify RegEx entries, in this case in /^\w+://\[f(?:[cd][0-9a-f]|e[89a-f])[0-9a-f]:[0-9a-f:]+\][:/]/$3p,domain=~localhost|~127.0.0.1|~[::1]|~0.0.0.0|~[::]|~local.

I don't think there are any easy ways to fix this, but potentially something like @@://192.168.0.$xhr,1p could be tried out.

[gorhill]

$3p cannot identify RegEx entries

Makes no sense, partyness assignment has nothing to do with pattern part of a filter, be it regex or plain. For Firefox, partyness is determined by the documentUrl property of the argument object passed to uBO through the webRequest listener. As per current state of the code, it appears the documentUrl property is not present in those blocked requests. A breakpoint there would confirm this and provide more details about what is going on by looking at the content of details.

[MasterKia]

A breakpoint there would confirm this and provide more details about what is going on

Is there something I can do?

[krystian3w]

Under the latest policy, there is unlikely to be any chance of expanding the list to include such an exception.

If you want to have a list, it is most convenient to use badfilter and regularly add IPs of routers to yourself.

I do not recommend in Iran to deactivate uBo, maybe you have a router with a kid/newbie/noob Trojan that can be blocked with add-ons.