[bug]: Tor/IP address work perfectly, but LAN interfaces stop working.

[BitcoinMechanic]

Prerequisites

• [X] I have searched for existing issues that already report this problem.

EmbassyOS Version

0.3.1~1

Device

Laptop/Desktop

Device OS

MacOS

Device OS Version

12.5

Browser

Firefox

Browser Version

103

Current Behavior

In situations I haven't figured out how to repro, but in both cases after the Embassy has been on for a few days nothing will load except Tor stuff and connecting via IP.

I had this issue on my prod and test boxes, and I believe @k0gen has had this issue too now.

This might be an issue with my network but I'm doubting that more now that someone else has had it.

Expected Behavior

LAN/SSH stay operational.

Steps to Reproduce

Run 0.3.1~1, use Embassy as normal. Check LAN/SSH after some days have passed.

Anything else?

No response

[BitcoinMechanic]

I currently have this issue on my test box. I won't disturb it in case investigation is possible.

[MattDHill]

@gStart9 this might be related to your introspection Embassy DNS and DCHP. Mind posting what you know here?

Could also be related to #1036.

Could also jut be some ish with your network @BitcoinMechanic.

[gStart9]

I am able to reproduce this -- I can resolve my embassy-xxxxxxx.local on my local network just fine but can't reach the .local for photoview or filebrowser (name will not resolve). I'm pretty certain that was working on 0.3.0 but not sure about 0.3.1.

This is also a problem inside the embassy. Ultimately DNS requests go to embassyd, which is resolving the main embassy-xxxxxxx.local just fine, and eg. lnd.embassy it is also resolving just fine, however, these very long, service-specific .locals are not resolving, even embassyd doesn't know about them (Note the lack of an "ANSWER SECTION"):

root@embassy-b933afa4:~# dig myreallyreallyreallyreallyreallylongphotoviewurl.local @127.0.0.1

; <<>> DiG 9.16.27-Debian <<>> myreallyreallyreallyreallyreallylongphotoviewurl.local @127.0.0.1
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28359
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;myreallyreallyreallyreallyreallylongphotoviewurl.local.	IN A

;; Query time: 19 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 03 22:51:54 UTC 2022
;; MSG SIZE  rcvd: 80

AFAICT, the DNS progression (quite logically if Embassyd prioritizes the .local and .embassy names it needs to resolve that aren't resolvable via the DNS protocol), is to ask embassyd's DNS server running on 127.0.0.1:53, which will ask via MDNS and presumably the hosts file, etc), then whatever DNS server was assigned from DHCP. In any event, I told dig to ask embassyd's DNS server @127.0.0.1 and it gave no answer back for the A record. Whereas embassy-xxxxxx.local and (eg) lnd.embassy do resolve just fine:

root@embassy-b933afa4# dig embassy-b933afa4.local @127.0.0.1

; <<>> DiG 9.16.27-Debian <<>> embassy-b933afa4.local @127.0.0.1
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27517
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;embassy-b933afa4.local.		IN	A

;; ANSWER SECTION:
embassy-b933afa4.local.	0	IN	A	10.99.99.11

;; Query time: 31 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 03 22:51:40 UTC 2022
;; MSG SIZE  rcvd: 78

[BitcoinMechanic]

To be clear though, being able to access embassy-xxxx.local is more than I can do. I can only access that via IP.

[k0gen]

For me this was more or less the same like in @gStart9 case that I've mentioned in #1036. Essentially embassyd (embassy::net::mdns:) was overloaded with publishing and adding new CNAME entries for new addresses. Stopping faulty service and rebooting fixed it.

[BitcoinMechanic]

This gets things up and running again: sudo service embassyd restart

[dr-bonez]

should be fixed by #1729