Logcat documentation

[pawlosck]

Where I can find documentation for logs generated by rethink dns? It would be nice, if you show me list of all logs generated by rethink with description. The most important thing, to know what log show blocked domain/ip.

I have problem with notifications and I would like to check what block it.

Few days ago, I tried to block everything from Google Play services and I blocked most of domains.
Steps:

1. block domain1
2. Check if it work
3. block domain2
4. check if it work
   ...
   Block domain XXX
   Check if it work

There is problem. I found domain, what blocks notifications, but when I unblocked it, notifications are still blocked. I unblocked next domain and notifications are still blocked. Currently, I don't know what domain blocks notifications.

[ignoramous]

Sorry, I'm confused.

What do you mean by "documentation for logcat logs"? Where are you viewing these?

Why do you need to read through those to set rules in Rethink?

I think, either you may be overcomplicating it, or Rethink needs to do a better job of communicating how rules affect apps.

[pawlosck]

What do you mean by "documentation for logcat logs"? Where are you viewing these?

What rethink dns send to logcat (sorry, but I am not android developer, so maybe I am using wrong words). Logs from logcat I am reading using Logcat Reader (https://f-droid.org/packages/com.dp.logcatapp/).

Look at screenshot - example of log from rethink dns.

Why do you need to read through those to set rules in Rethink?

As I said, I have problem with notifications and I need more info about, what rethink dns do. What is blocked/allowed.
If I know, in log window (inside rethink) there are info about blocked ip/domain, but there are no info about blocking ip/domain using advanced features like:

• anti censorship,
• advanced dns filtering.
  For example, "advanced dns filtering" blocks VoWiFi (VoWiFi and push notifications (for example bank app) doesn't work  #2633 - there are more similar issues) , but there are no any info about that. People don't know, what rethink dns features do and why block specified ip/domain or action like sending data beetwen apps (I don't know if rethink blocks it too).

Maybe you should add into logs simple items like:
ip/domain (or something else): blocked/alloved
what blocked/allowed: feature XX/rule XX -> example "Configure --> DNS --> FILTERING --> "Advanced DNS filtering"
Date/time
That's all. If someone need more info, could search using rest of logs.

Long time ago, I created issue #1738
and you implemented it, but it's not helpfull. It should be like:
"Configure --> DNS --> FILTERING --> "Advanced DNS filtering: old_value->new_value". It will help to find problems.

Put logs into table with filtering/searching and should be ok.

[ignoramous]

Thanks.

As I said, I have problem with notifications and I need more info about, what rethink dns do. What is blocked/allowed.

Don't need logcat logs for these. Each allow / deny decision will make to the Configure -> Logs UI (barring any heavy use of dns/network when some network/dns log entries may be dropped to relieve database of write amplification).

Put logs into table with filtering/searching and should be ok.

This is already the case. See About -> App Logs. These logs aren't persistent, though (that is, only past 35,000 log entries are kept in-memory, not on disk).

advanced dns filtering

That's an experimental setting. It changes IPs that apps or components connect to. Not every component or app will like that. Should only be used with trade-offs in mind. That said, VoWifi has other issues with VPNs themselves, unrelated to Advanced DNS Filtering. The connection to VoWifi IPs need to bypass / excluded from the tunnel altogether. Rethink doesn't support this today, but we intend to soon.

Maybe you should add into logs simple items like ... If someone need more info, could search using rest of logs

Ideally, the (logcat) logs + code is how this is supposed to work. Viewing logs in isolation will always be confusing. But I will think about how to make the log messages better than they already are.

[Start-Cart]

It would be helpful if the "UI Logs" and "Event Logs" could optionally be included in "App Logs". Currently, troubleshooting requires going back and forth between different menus and trying to cross-reference information that is continuously changing. Having one chronological log would make this much easier.

It would also help to use consistent, human-readable timestamps. For example, UI Logs may show “6 days ago — 21:00” (with no date), while App Logs use a Unix timestamp like 1786311069724 when downloaded, making events harder to correlate.

The App Logs can also be complicated for most users to interpret, so clearer context in the log messages would help prevent misunderstandings. Looking at the source code isn't a practical option for ordinary users trying to troubleshoot an issue, which is why clearer, self-explanatory log messages would be helpful.

Optionally, it would be useful to have:

Longer log-retention periods for identifying patterns before being auto deleted Or Automatic encrypted log exports.
Automatic redaction of sensitive information, such as local IPs, when sharing logs.

I understand that including everything could make logs larger, so these could be optional settings. This would be a helpful diagnosis upgrade

[ignoramous]

Makes sense.

It would be helpful if the "UI Logs" and "Event Logs" could optionally be included in "App Logs"

Sorry, what's "UI Logs"?

Looking at the source code isn't a practical option for ordinary users trying to troubleshoot an issue

Gotcha. I mostly meant from the angle that, if someone is going to go through the trouble of looking at logs, they might already be technical enough to look at the code (or at least point a capable LLM at it along with logs).

Longer log-retention periods for identifying patterns before being auto deleted Or Automatic encrypted log exports.

Retention (at least in "App Logs") is expensive (in resource use; both CPU and RAM). So, I don't see it.

Automatic redaction of sensitive information, such as local IPs, when sharing logs.

Depending on the issue being reported, redacting logs of IPs/domains etc will make it harder to track down what's going on.

• One-tap export of configuration summary / logs #1523

I don't see this feature as priority as the number of users (in our already tiny userbase) who are going to look at logs at this detail (but not at the code) is going to be tiny... especially the work required to implement all these suggestions (which are valid) doesn't benefit the core developers, who are the primary consumer of these logs.

That said, we'll make a gradual effort to implement your suggestions over time, across versions. Welcome pull requests, too (but I understand that there are just way too many log messages to "fix").

---

I'd say though, as an end-user, you do not have to look at the logs at this detail. You can always report an issue to us and have us look for you (if you think it is a common enough issue). The feature to setup "Log levels", view Error or Warning level "App Logs", "Event Logs", "Stats", "Stacktrace" in the About UI, diagnostic messages in the bottomsheets that come up when you tap on entries in Configure -> Logs -> Network & Configure -> Logs -> DNS all exist to simplify the debugging for the end-user. Raw "Very verbose" / "Debug" logs themselves are meant for us (core developers) or folks technical enough to look at the code and the "logcat" logs, both.