"Advanced filtering" -> "Upstream" - no content
Versions
- Pi-hole: v6.0.6
- Web: v6.1
- FTL: v6.1
Platform
- OS and version: Raspberry Pi OS (Debian Bookworm)
- Platform: Raspberry Pi
Expected behavior
Content after selection.
Actual behavior / bug
Server “fritz.box#53” as an example appears when clicked in the “Dashboard” in “Advanced filtering” -> “Upstream” as IP. Many entries are listed.
If “fritz.box" is selected directly in ‘Advanced filtering’ -> ‘Upstream’, the list is empty.
The same applies to “dns.sse.cisco.com”. fd00::xxx#53 is not even available/ selectable, as described in #3442.
Steps to reproduce
n/a
Debug Token
n/a
Screenshots
Additional context
n/a
Try it with fritz.box*
I think FTL should do kind of a wildcard filtering by default. This would also solve what I described here: https://github.com/pi-hole/web/issues/3406#issuecomment-2819408151
Try it with
fritz.box*
"No results found"
I think FTL should do kind of a wildcard filtering by default.
The problem is that LIKE %% cannot use the b-tree index in an efficient way. Exact string matching is so much faster. Anyway, FTL does handle wildcard matching, the problem here is rather that we do not search the hostnames associated with the upstream servers but only IP addresses. This is the case because we do not store the host names in the SQLite3 database at all.
I think we need to change the suggested upstreams to show IP addresses, only, to at least get some consistency here. Implementing storing the names alongside the addresses needs database modifications which is a bit more work that I can spare right now. Sorry for that. That is not at all saying this will never come - just not today/-night.
@AS98765 Please try running
sudo pihole checkout ftl tweak/suggest_upstream_ips
and see if the situation improves for you.
I think we need to change the suggested upstreams to show IP addresses, only, to at least get some consistency here.
While this will 'fix' the issue, I suspect this might not the best user-friendly solution. They are used to see the host names. Can we suggest IP but add the hostname for displaying only (maybe in parenthesis)?
I tried the branch and it actually does not work, because it only suggests the IP, missing the port.
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.
@yubiuser Please try again, it now looks like this
edit just for clarification: the multi-line ones belong together, e.g.,
Using names for filtering directly would be much more work as we do not store them in the database right now. We'd need to amend the forward_by_id table by the name only then we could modify the search string from f.forward=... to f.forward=... OR f.fname=....
I think the selection from the advanced filtering menu is fine now.
I've just noted three (related) issues:
- On the dashboard, different upstream IPs with the same name are now displayed by name only. One cannot distinguish by IP anymore (select both google IPv4 upstreams, both will be shown as
dns.google) - Clicking on one of the
dns.googlelinks on the dashboard does link to always8.8.8.8#53but never8.8.4.4#53. See the video
- If one comes from the dashboard, the the filter does not pre-select the existing entry in the drop-down but creates a new one.
@yubiuser
About your comments above:
- On the dashboard, different upstream IPs with the same name are now displayed by name only. One cannot distinguish by IP anymore (select both google IPv4 upstreams, both will be shown as dns.google)
- Clicking on one of the dns.google links on the dashboard does link to always 8.8.8.8#53 but never 8.8.4.4#53
I think the Query Log fliter is working, but the chart legend link is broken.
Right after I added the 2 google IPs, the chart legend was showing IPs (with correct links and the Query Log filter was correctly selected):
8.8.8.8#53 ---> Link to queries?upstream=8.8.8.8%2353 (correct)
8.8.4.4#53 ---> Link to queries?upstream=8.8.4.4%2353 (correct)
After a few seconds, the name of the second IP was resolved and this was shown (Query Log filter was correctly selected again):
8.8.8.8#53 ---> Link to queries?upstream=8.8.8.8%2353 (correct)
dns.google#53 ---> Link to queries?upstream=8.8.4.4%2353 (correct)
After a while, the name of the other IP was also resolved, but now the links were wrong:
dns.google#53 ---> Link to queries?upstream=8.8.4.4%2353 (WRONG!)
dns.google#53 ---> Link to queries?upstream=8.8.4.4%2353 (correct)
The issue is here:
https://github.com/pi-hole/web/blob/d799d39d258fe5c57e4d08a7384ec74c1b044611/scripts/js/index.js#L251-L255
The second dns.google overwrites the IP and both links will point to the same upstream.
@rdwebdesign Could you fix this on the web side of things? Is this fix otherwise ready? Sorry, I lost overview over this issue after so long time has passed...
I also lost track. But I think the FTL part was fine otherwise. But I would re-test once with web being also fixed.
I need to test this PR again and check what is broken and what is working.
I will try this later, after work.
@DL6ER @yubiuser
Please check https://github.com/pi-hole/web/pull/3606
Should be fixed with https://github.com/pi-hole/FTL/releases/tag/v6.3