NAA and IPv6 stop working together

Audio Gear Talk HQ Player
1

I just struggled for over one hour with a configuration collapse that appears to have something to do with IPv6 option. The setup, which had been working perfectly for the last year:

  • Mac Mini M1 running HQP Desktop, set to connect to NAA IPv6
  • UP Gateway running NAA image
  • Holo Spring 2 KTE
  • Roon on a Ubuntu Server PC
  • UniFi network controlled by a UniFi Dream Machine

This setup was working yesterday. Then, thanks to the high winds we had today on the Northern California coast that cause tree branches to hit power lines, we had two short power outages. We have an automatic backup generator, but it takes a few seconds to start, and in the meanwhile all computers and network gear lose power and reboot. Everything seemed to have got back up, but when I tried to play to HQP via Roon, I got an error message that HQP was not responding, even though I could see HQP Desktop up and running on the Mac mini. After a lot of messing around, including installing the latest NAA image, rebootings, and logfile inspection, I concluded that the the HQP IPv6 option, which had been working fine for the last year, seemed to be the problem. After turning that off and going through another round of rebootings, music again!

I’m puzzled why the IPv6 option worked for so long and now fails. As far as I can see, my network/router configurations have been unchanged since I set it all up November 2021, and there haven’t been any updates for the last few months.

2

After getting IPv4 working, you re-tried re-ticking IPV6? And still failed again ?

3

Maybe some update got installed as result of reboot? Either in networking gear or somewhere else?

Another possibility is that devices came up in different order than before.

On Mac Mini, if you don’t use WiFi, please check that it is turned off. MacOS is a bit tricky with IPv6 at times, but IPv6 is nice in a way that even if network infra doesn’t support it, the devices still auto-configure common local network without IP conflicts. This can happen because the 48 bit MAC can completely fit in 64-bit IPv6 address.

1 Like
4

Mac Mini WiFi is off, has been since the beginning. As far as I can see, nothing got updated, it would have taken a lot longer than what I observed when power came back (the glitch between power out and generator kicking in is around 30 seconds). I’m stumped.

5

Possibly restarting both NAA OS and macOS could help, now that the network infrastructure, including internet connection are up again.

But you can also check with “ifconfig” that both have some IPv6 address configured for the relevant interface.

6

I’ve tried restarts, no improvement. Here’s what HQPlayer 4.21.1 logs when I try IPv6 NAA:

# 2023/02/22 14:29:48  clNetEngine::Disco(): clSocket::SendTo(): sendto(): No route to host
# 2023/02/22 14:29:52 NAA output clNetEngine::Disco(): clSocket::SendTo(): sendto(): No route to host

However, my Mac Mini has IPv6 configured according to ifconfig. The NAA endpoint is an UP Gateway with the latest NAA image from naa-431-x64ramfs.7z.

7

Seems like some hiccup in macOS. Please check the lines under heading “NAA output network interfaces” in the log. It should list just two items and both with both IPv4 and IPv6. First likely “en0” which is your wired Ethernet, and second “lo0” which is the local loopback interface.

8 
  2023/02/22 16:05:37 Network interfaces:
  2023/02/22 16:05:37   if[en0] ipv4=192.168.2.211 ipv6=fe80::62:3a8c:c552:95ac%en0 idx=6
  2023/02/22 16:05:37   if[lo0] ipv4=127.0.0.1 ipv6=::1 idx=1
  2023/02/22 16:05:37 Listen discovery on en0
# 2023/02/22 16:05:37 clControlServerThread::Start(): clSocket::SetOption(): setsockopt(..., 41,12, ...): Can't assign requested address
  2023/02/22 16:05:37 IPv6 support disabled due to failure
  2023/02/22 16:05:37 Set filter: 39 / 40
  2023/02/22 16:05:37 Set oversampling: 42 / 44
  2023/02/22 16:05:37 Set dither: 5
  2023/02/22 16:05:37 Set modulator: 13
  2023/02/22 16:05:37 AutoSDM disabled
  2023/02/22 16:05:37 Audio engine is normal
  2023/02/22 16:05:37 IntegratorM: FIR2
  2023/02/22 16:05:37 Audio engine SDM mode enabled
  2023/02/22 16:05:37 Automatic output rate switching enabled
  2023/02/22 16:05:37 Set volume: -3 +
* 2023/02/22 16:05:37 Control server allow remote control
  2023/02/22 16:05:38 NAA output network interfaces:
  2023/02/22 16:05:38   if[en0] ipv4=192.168.2.211 ipv6=fe80::62:3a8c:c552:95ac%en0 idx=6
  2023/02/22 16:05:38   if[lo0] ipv4=127.0.0.1 ipv6=::1 idx=1
  2023/02/22 16:05:38 NAA output discovery from en0
# 2023/02/22 16:05:38 NAA output clNetEngine::Disco(): clSocket::SendTo(): sendto(): No route to host
  2023/02/22 16:05:38 NAA output connect to 192.168.2.124:43210 [ipv4]
  2023/02/22 16:05:38 NAA output network endpoint: Holo Audio UAC2.0 Gen2 Standard: USB Audio (hw:CARD=Standard,DEV=0)
  2023/02/22 16:05:38 NAA output discovered 1 Network Audio Adapters
+ 2023/02/22 16:05:38 NAA output connect to 192.168.2.124:43210 [ipv4]
9

For some reason it gives “No route” when sending packet to a multicast address. I guess there’s an IPv4 default route on en0 for internet access. But maybe there’s no suitable route in routing table for IPv6.

“netstat -r -n” will show all routes, but it is pretty lengthy. There should be pretty universal fe80 routes on the link. Maybe also “route -n monitor” and then try IPv6 discovery would show something?

10

I don’t know how to parse this, I grew up with IPv4, but maybe it makes sense to you. From the Mac Mini:

% netstat -r -n | grep '^fe80'
fe80::%lo0/64                           fe80::1%lo0                     UcI               lo0       
fe80::1%lo0                             link#1                          UHLI              lo0       
fe80::%anpi0/64                         link#4                          UCI             anpi0       
fe80::80d2:45ff:fef1:6157%anpi0         82:d2:45:f1:61:57               UHLI              lo0       
fe80::%anpi1/64                         link#5                          UCI             anpi1       
fe80::80d2:45ff:fef1:6158%anpi1         82:d2:45:f1:61:58               UHLI              lo0       
fe80::%en0/64                           link#6                          UCI               en0       
fe80::13:c7a6:6aaf:972d%en0             90:9c:4a:b6:cf:f5               UHLWIi            en0       
fe80::62:3a8c:c552:95ac%en0             14:98:77:83:13:be               UHLI              lo0       
fe80::207:32ff:fe95:dd4%en0             0:7:32:95:d:d4                  UHLWI             en0       
fe80::838:a329:6c3b:2c2b%en0            3c:22:fb:a:68:33                UHLWI             en0       
fe80::c70:a80f:81bd:8ff5%en0            48:bd:e:0:ce:f8                 UHLWI             en0       
fe80::7c2d:72ff:fe66:41db%awdl0         7e:2d:72:66:41:db               UHLI              lo0       
fe80::7c2d:72ff:fe66:41db%llw0          7e:2d:72:66:41:db               UHLI              lo0       
fe80::%utun0/64                         fe80::9498:ef17:ae04:8728%utun0 UcI             utun0       
fe80::9498:ef17:ae04:8728%utun0         link#16                         UHLI              lo0       
fe80::%utun1/64                         fe80::84fa:767b:452d:bb32%utun1 UcI             utun1       
fe80::84fa:767b:452d:bb32%utun1         link#17                         UHLI              lo0       
fe80::%utun2/64                         fe80::ce81:b1c:bd2c:69e%utun2   UcI             utun2       
fe80::ce81:b1c:bd2c:69e%utun2           link#18                         UHLI              lo0

And here’s what route -n monitor says when I try to turn on IPv6 NAA:

got message of size 68 on Wed Feb 22 19:59:58 2023
RTM_DELMADDR: multicast group membership removed from iface: len 68,
sockaddrs: <GATEWAY,IFP,IFA>
1.0.5e.40.0.c7 en0:14.98.77.83.13.be 239.192.0.199
got message of size 68 on Wed Feb 22 20:00:02 2023
RTM_NEWMADDR: new multicast group membership on iface: len 68,
sockaddrs: <GATEWAY,IFP,IFA>
1.0.5e.40.0.c7 en0:14.98.77.83.13.be 239.192.0.199
11

I think this should do it…

And there is only IPv4, but no IPv6 (HQPlayer is dual-stack)… I’m sort of out of ideas right now why the IPv6 message send returns “no route” and doesn’t go anywhere…