I’ve thought up several directions to go for further investigation:
Logs are always useful; Is it a correct assumption that the log from which you found “
DNS resolution is currently unavailable” was that displayed on the balena cloud dashboard for the device, with timestamps after the most recent boot, that is, while it is unreachable on your dev environment’s LAN? There may be more of use in the logs to search for (or, posting them, with any info you wouldn’t post to a forum removed).
At the very least, if your device is sending logs home, it has an IP address on the network, since the API requests POSTing the logs to the cloud are in the application layer, requiring IP packets
If logs are sending, how goes SSH? Could you connect to the host and run
ip a s to check the addresses assigned (if any) to
You could also just run
balena scan (Balena CLI Documentation - balena scan) to find the device on the local network. It may be that your static allocation (a config in the device itself, in its networkmanager profile, if I’m not mistaken?) did not work and it’s been given a random address by DHCP.
DHCP / static IP allocation issues in my experience are most directly investigated using one of tcpdump / wireshark / tshark capturing during the time the device is booted, while connected to eth / has its wifi card/drivers all ready to go. For wifi you can capture on a dev machine on the same network / in promiscuous/monitor mode, and for eth you’ll need a LAN tap / star (you mentioned having a network switch on the desk and some cables, so if you have an ethernet use-case, you’d be in luck possibly to have the means to sniff eth traffic.
These many directions may turn up something useful.