mDNS not resolving when used in host field

[dabell-cc]

Hi, I have an agent that won't connect.
I have a hub running with 1) an agent on the same machine (localhost) and 2) an agent on another machine in the same subnet - e.g 192.168.1.1/24.
I added both with 'host' field as .local, where is the corresponding output of uname -n.

The hub is running fine, and the agent on the same machine (hostname1.local) shows up fine.
The agent on the second machine (hostname2.local) is marked as offline, unless I go into the Systems record and modify the host field to the current ipv4 address (192.168.1.x) then it pops up and shows data.

A few things I've tried:

• pinging from the hub machine to the agent machine using using ping hostname2.local <- resolves and response time <5ms
• checking that the port is open and name resolves using nmap -sT -p45876 hostname2.local <- resolves and open

I have a fuzzy understanding of mDNS vs DNS, but seeing as the other two methods of testing a connection worked, I expected beszel-hub to handle it as well.
As I've subsequently been reading, using .local might not be a great idea, but it works well enough for many purposes.

[henrygd]

Are you using binaries?

Check the logs page at /_/#/logs -- you should be able to search for "Failed to connect" to see what the connection error is. Otherwise look for any other relevant error.

I'm not a DNS expert either, but if nmap / ping resolves the hostname then I'm not sure why this would not.

[dabell-cc]

Yes I am using the binaries, both machines in my setup are Debian 12, in case that turns out to be relevant later.

For a second I thought you meant the logs were in that path from the hub's working directory. 😁

Anyway, once I hit the relevant webpage, the error message in the log is this:
dial tcp: lookup hostname2.local on 192.168.1.1:53: no such host

I'll set up another example tomorrow (I've been moving hosts between subnets/vlans, etc) and see if I can't get some better info about what might be going on (especially why nmap/ping get resolved, but this call wasn't). Most of the hits I get online for the dial tcp: no such host end with 'modifying my system to manually link the hostname to the ip fixed it!' which is counter to my desire to have mDNS do that part for me.

I'm sure it's going to end up being something about how my network responds - I'll probably end up comparing the network activity between beszel and nmap with wireshark.

Thanks for all the help you're offering (I've been reading through some other folks' issues) and the nice-to-read documentation, this is a great utility that I was really pleased to have read about on the selfhosted sub-reddit a couple days ago.

[dabell-cc]

Is there a quick way to flush the log messages?
Also, a way to force the mDNS request over and over?

My initial impression is that the mDNS query isn't sent out on the network at all.
This contrasts with me manually ssh-ing from the hub machine to the agent machine, mDNS query and response clearly show up with wireshark from a third machine.

[henrygd]

I found a reddit post that mentions it could be due to the pure Go DNS resolver. We don't build Beszel with cgo because we need to cross compile for a bunch of different platforms. So the agent would be using the pure Go resolver by default.

https://www.reddit.com/r/golang/comments/xd8zr6/strange_behavior_of_programmatic_mdns_lookup_on/

The only way to test this theory would be to build the agent hub yourself using cgo. We have a guide for compiling, but you'd need to change CGO_ENABLED=0 to CGO_ENABLED=1 in the makefile or example command.

Is there a quick way to flush the log messages?

Click the cog to open the "Logs settings" dialog, then set retention to zero. That should clear all existing logs. I think it will also show live events and not save them to the DB, but I haven't tested that.

Also, a way to force the mDNS request over and over?

Try pausing and unpausing the system from the table.

[dabell-cc]

change CGO_ENABLED=0 to CGO_ENABLED=1 in the makefile

Re-building the Hub does get the address resolution of .local to work, no compilation required for the agent.
I suppose this makes it an issue with Go and their DNS resolver.
For completeness I used go version go1.23.4 linux/amd64 and npm: '9.2.0', node: '18.19.0' to build, not sure if any other versions are relevant for those looking to reproduce.

Looks like that answers the original question though: if mDNS support is needed then manual compile is the way to go.
Could be made a simple-enough step with CGO_ENABLED ?= 0 in the Makefile to allow easier overriding, versus the forced values currently there.

By the way, I'm not a webdev, didn't have go or node installed, etc - I do have some familiarity with makefiles, and the instructions for manual compile were very easy to follow. Seriously, well done on the documentation side of this project.

I had some weird behavior, running ./beszel_linux_amd64 serve --http "0.0.0.0:8091" where the 8091/_/#/settings Application URL showed http://localhost:8090, and changing the log retention would dump me back to /_/#/ but that isn't related to the mDNS issue, so I'm not going to pursue it here.

[dabell-cc]

I've been reading a little more and it seems from this golang issue that it might be the cross-compile in general, rather than the cgo flag.

[henrygd]

Thanks for the updates, and I appreciate the feedback on the docs.

For native compilation we should be able to leave cgo enabled by default. I'll add CGO_ENABLED=0 to the commands for cross compiling instead.

Will do a bit more research on this when I can.