rethink-app: v055: can't resolve `.local` domains - never get any DNS response

Thank you for doing our design, research, and testing for us! We merely implemented it (erroneously so, for over 4+ versions).

---

mDNS aside, I doubt p2p apps would still work, unless Do not route Private IPs is enabled or those apps are Excluded from Rethink altogether.

Seems like some Android limitation (ex: #1356), but I’m yet to fully get to the bottom of it.

(closing this issue, feel free to reopen)

@ignoramous Sorry for the delay. Apparently I wasn’t getting update notifications from F-Droid for some reason[^bg] - I just discovered last night that the new version of Rethink (among other things) had shown up.

I just set Termux and AVNC back to the normal ‘allow’ settings, and I can resolve .local domains inside both of them - even after removing the manual .local entries from pDNSf, restarting pDNSf, and pressing the DNS Refresh button in Rethink. (I also tried another .local that had never been in pDNSf, just to be extra sure.) So far, it all seems to be working properly!

Thank you so much for your help with this.

[^bg]: I probably just missed turning off one of the battery optimization settings or something like that, and the OS killed the F-Droid app.

@ignoramous I’ll keep an eye out for it. Thanks.

Hi @Rhys-T: Can you please check if v055e (F-Droid should have the build in 3 days or so) works for .local queries? I tried to set something up on my local network and avahi on my laptop responding to xyz.local, but could never get it to work; as in, either Rethink doesn’t yet impl mDNS as it should (very likely) or my setup is whack (also equally likely).

That’s odd - excluding it makes both of those commands work on my device. Does it work on yours with Rethink turned off entirely?

Yeah, no difference whether rethink is ON or OFF. I think my mdns setup isn’t fully working… I’ll keep looking for ways to test this over the next few days, though.

thought maybe the strings.Contains() call was failing to match because it’s case-sensitive.

Good catch. Even though it is unlikely to be the issue here, I’ve fixed it anyway: https://github.com/celzero/firestack/commit/f7190cb424e0fb73fa953e72c949a3c8567452af

And added a bunch more logs(https://github.com/celzero/firestack/commit/3796d92eb41c5fb6e6de9d86bf04466fc6d2e563, https://github.com/celzero/firestack/commit/2674ed6479ed4c7f5b13dd6be3d68f8966ed0e77). I’ll keep this thread updated as I work my way to running tests with mdns myself. I’ve bothered you enough.

Please wait for F Droid to get the update. Backup and restore is a hairy beast.

it makes sense that closing client shouldn’t be happening immediately. Not sure what would be causing that, though.

I think this was some sort of bug in the Go runtime. A nil pointer didn’t cause a panic but instead the client was being mopped up… who knows.

We’ve fixed the nil pointer now; and expect client to NOT close right away and wait for responses. It is another thing if the client works at all: https://github.com/celzero/firestack/commit/190524888d8f64c12bd112bc697943d7df88690b

I’ve also tried changing the IP version between IPv4, IPv6, and auto - that didn’t seem to affect it either.

Possible but it adds yet another knob in our app and yet another if condition in the code… I’d only want to add it if it helps despite Rethink getting mDNS to work (in some happy future).

Fair enough. I suspect non-mDNS usage of .local is probably getting rarer these days.

Hm. For me, Go was one of the easiest languages to learn. Fastest I got proficient in. It is a mix of limited versions of both JS + Python.

Oh, I wasn’t saying it was a difficult language - I just haven’t taken the time to learn it yet.

Yep. This means, the mdns transport we’ve wired in isn’t sending out the queries at all. And this would be right as I see the mdns transport is in fact not doing anything, neither does it error out, but closes immediately within a millisecond (instead of waiting for 3 seconds). This is what appears in the logs as

I mdns: closing client {true true 0x4000314e10 0x4000314e18 <nil> <nil> map[] 0x4001313860 true 1 0x40002943c0}

Gotcha. I didn’t know whether ‘upstream’ DNS/mDNS queries and responses would show up in the packet capture or not.

I’m not familiar enough with the app’s architecture to know what the logs should look like, but in hindsight, it makes sense that closing client shouldn’t be happening immediately. Not sure what would be causing that, though.

[re: setting the log level] Not yet. Good call though. We should include this in the release builds, too.

Okay. Just wanted to check in case it would help with tracking this down.

You mean exclude? Yeah, that should let Android’s built-in mDNS support kick-in for just the excluded app.

🤦 Yeah, I meant ‘exclude’. Not sure what happened there - I think I was testing the ‘bypass’ options as well, just to be on the safe side (they didn’t affect anything), then got mixed up and wrote the wrong one down. Sorry about that.

I think there’s some stupid bug in our code. I already spent an hour today without making any progress. I intend to spend some more time tomorrow. Let’s see.

Thank you for looking into this. Let me know if there’s anything else I can do to help track this down.

…would it be possible to add a setting to allow .locals to be treated the same as other domains like they were before?

Possible but it adds yet another knob in our app and yet another if condition in the code… I’d only want to add it if it helps despite Rethink getting mDNS to work (in some happy future).

If a program explicitly makes an mDNS query itself, then turning on that setting does allow it to work.

Gotcha. That’s how I’d expect Do not route Private IPs to work… So, no surprises here.

I’ll admit, Go isn’t a language that I’ve gotten around to learning yet.

Hm. For me, Go was one of the easiest languages to learn. Fastest I got proficient in. It is a mix of limited versions of both JS + Python.

The packet capture from Rethink shows the normal-DNS query coming from dig, but not the mDNS query that should be getting sent from Rethink itself. Does that indicate what the problem is?

Yep. This means, the mdns transport we’ve wired in isn’t sending out the queries at all. And this would be right as I see the mdns transport is in fact not doing anything, neither does it error out, but closes immediately within a millisecond (instead of waiting for 3 seconds). This is what appears in the logs as

I mdns: closing client {true true 0x4000314e10 0x4000314e18 <nil> <nil> map[] 0x4001313860 true 1 0x40002943c0 

Is there any way I can set the log level to include these, without having to switch to a debug build of the Rethink app?

Not yet. Good call though. We should include this in the release builds, too.

Setting an app to ‘bypass’ allows it to resolve .local names successfully (through Android’s mDNS client, I think?).

You mean exclude? Yeah, that should let Android’s built-in mDNS support kick-in for just the excluded app.

Is there anything else you need me to look for in the logs that might be helpful?

I think there’s some stupid bug in our code. I already spent an hour today without making any progress. I intend to spend some more time tomorrow. Let’s see.

Doesn’t seem to be indicating a real error though.

Yep, that “error” doesn’t matter, but I’ve fixed it, anyway.