Minor networking annoyance (Ubuntu Server 22.04.1 LTS)

Whenever I reboot my server after Ubuntu updates, hqplayerd starts but gets stuck in networking limbo where Roon can talk to it but it seems stuck talking to the NAA endpoint and play does not advance. I have had this issue for quite a while, it’s not a huge deal but I had a bit of time to dig into logs today and found the following:

2023/02/05 10:13:42  network Audio IPv6 support enabled
  2023/02/05 10:13:42  discovery from 0.0.0.0
# 2023/02/05 10:13:42 clNetEngine::DeviceLookup(): clNetEngine::Disco(): clSocket::SendTo(): sendto(): Network is unreachable

Restarting hqplayerd clears the issue:

2023/02/05 10:14:33  network Audio IPv6 support enabled
  2023/02/05 10:14:33  discovery from 0.0.0.0
& 2023/02/05 10:14:33  discovered network audio: name='naa' version='Signalyst Network Audio Daemon 4.2.0'  @192.168.2.204:43210
& 2023/02/05 10:14:33  discovered network audio: name='naa' version='Signalyst Network Audio Daemon 4.2.0'  @192.168.2.204:43210
  2023/02/05 10:14:34  discovery from ::
  2023/02/05 10:14:35  connect to 192.168.2.204:43210 [ipv4]
  2023/02/05 10:14:35  network endpoint: Holo Audio UAC2.0 Gen2.1 Enhanc: USB Audio (hw:CARD=Enhanc,DEV=0)

Obviously there’s some race condition between the Ubuntu network stack startup and hqplayerd endpoint discovery, but I don’t know what to try to correct it. Suggestions?

1 Like

This issue can happen when network is configured through DHCP, depending on the network management service in use.

hqplayerd service has dependency to network-online.target

However, if the network configuration service reaches that target before DHCP setup has completed, hqplayerd service is started before the network setup is complete. And the process as obsolete network setup and the discovery doesn’t work.

Issue is pronounced by the fact that there has been different network configuration systems in use over time, and Desktop and Server OS have traditionally have used a different one. (if you upgrade from earlier distro version, your earlier system persists)

This can work fool proof with systemd-networkd (but for that you need to modify the service file on Ubuntu). But Ubuntu has used first the Debian networking scripts, then NetworkManager on Desktop and now NetPlan on most recent…

If you setup fixed IP for the server, instead of DHCP, this issue shouldn’t happen. DHCP is problematic, because it is run asynchronously, and depending on DHCP server can have 10 second or more delay.

3 Likes

Thanks Jussi,
I’ve also had problems with my Linux server like this, including delay starting. I will swap to a fixed IP address in my router.

Instead of assigning fixed IP on your router DHCP, you need to assign a fixed IP on Ubuntu configuration. As long as DHCP is in use, there’s an asynchronous delay.

Usually routers have a configurable DHCP address range. For example from .100 to .254 or something similar (C-class, /24 prefix). This leaves the range from .2 to .99 for fixed IP’s. So usually one would manually allocate one IP outside of the DHCP range for fixed IP devices. You of course can still assign a fixed IP from DHCP range and configure it as fixed IP on your server. But technically such would be more correctly “give me same address every time from DHCP spool” case.

Did a bit more research and network-online.target is supposed to mean that the interface has an IP address, which it only gets from DHCP… Looks like network-online.target doesn’t even mean that, at least not in my Ubuntu configuration. More investigation needed.