iPhone not appearing as audio zone

[wlgreg]

Hi Aaron,

Thanks for taking the time to take a look! As far as I can tell, everything seems to be running udp-proxy-2020 service is running, I can ping my iPhone from the wireguard machine when it's connected via VPN. A few more notes:

1. Wireguard and udp-proxy-2020 are running on a Raspberry Pi 4. Appears in pcap logs as wireguard.udm-local (local IP 10.0.1.112)
2. Roon Rock (dedicated NUC) appears in logs as rock.udm-local (local IP 10.0.1.25)
3. Router is 10.0.1.1 (different from the wireguard machine, but needed wireguard port forwarding rules are already in place)
4. UDP-proxy version is udp-proxy-2020-0.0.11-linux-armv7
5. UDP-proxy is started via systemd script with: /usr/bin/udp-proxy-2020-0.0.11-linux-armv7 --port 9003 --interface eth0,wg0 --cache-ttl 500 --pcap --pcap-path /home/pi/udp/logs
6. systemctl status shows no errors
7. no difference when using --no-listen flag
8. iphone connects to Wireguard VPN, and I can access Roon (as well as other local resources). The iPhone just doesn't show as an audio zone.

I've included logs with this ticket. Please let me know if anything obvious jumps out at you.

Also, based on some other comments, I was under the impression that ump-proxy-2020 does work with a dedicated Roon Rock install like I have (with wireguard installed on a separate device), but if that's not the case, then please let me know.

Again, very much appreciate you taking a quick look.

-Greg W
Archive.zip

[synfinatic]

So spent 5min looking at things and everything looks good. Sounds like you've got everything configured correctly and I don't see any indication of issues in the pcaps.

Before I dig deeper into the pcaps which can take a while, can you try:

1. Reboot your phone
2. Turn off wifi
3. Turn on Wiregard VPN (while on cellular)
4. Start Roon

[wlgreg]

Thanks for the quick response!

I tried the iPhone reboot sequence you specified, but no luck. I also restarted the udp-proxy-2020 service, but no luck with that either. I tried a few other things (rebooting Wireguard machine, disabling PiHole) just on the off chance they'd help, but again, no luck.

Please let me know if there are any other debugging steps I can take which might be helpful. Thanks so much for your assistance (and I fully realize that this is likely really low on your priority list)!

EDIT: I also tried from my MacBook (tethered to my iPhone cellular and wireguard tunnel activated on MacBook). Same thing, MacBook does not show up as an audio zone. I don't know if this is a helpful data point or not, but figured I'd share!

[synfinatic]

well at least it's consistent :)

btw, you should probably remove the --pcap flag or you might find you run out of disk space on your RasPI if it's a small SD card. Will have to spend some more time looking more carefully at the pcaps and comparing them to what I see on my own home network.

[wlgreg]

Flag removed and service restarted! Thanks for the reminder!

[jvican]

Just wanted to say that I experienced the same problem in #81 In my case, I'm running this in an image inside Proxmox.

I'd love to see the follow-up to this ticket since I expect I'll also be able to use any future solution.

[synfinatic]

@jvican Sorry, no idea what "proxmox" is.

[jvican]

It's just a hypervisor - shouldn't have anything to do with this. I've tried running udp-proxy-2020 inside both a virtual machine with Linux and a container. My case is similar to @wlgreg's so solving his should solve mine.

[synfinatic]

@jvican all virtualization technologies do strange things to networking and depending on their configuration, may prohibit something like udp-proxy-2020 from working correctly.

Sorry, I just don't have the time or means to test or support every possible networking configuration under the sun. I can barely even properly support the Docker solution I have. Not to mention Roon refuses to share the details of their networking protocol so I'm left looking at raw bytes and trying to guess what is wrong with or without pcaps.

[synfinatic]

@wlgreg , i'm curious if you have tested this with the latest iOS Roon client. The release notes say they fixed an issue which sounds very much like what might be happening: https://community.roonlabs.com/t/roon-1-8-build-943-is-live/201152

[wlgreg]

Hey Aaron,

Gave it a try today from work with the newest iOS build and, unfortunately, no difference. This weekend, I'll give everything (core, wireguard box, router, idDevices) a reboot just to see if that has any impact. Thanks!

[synfinatic]

Bummer... FYI, I did ask today during the webinar if they would be open to releasing any documentation on the Roon Discovery protocol and they said they were not willing to do that. I suppose if a bunch of people ask politely in the forums, it's always possible (but frankly unlikely) they would do it.

Until then, will have to see if I can dig deeper and figure out what is going on. Got a bunch of other projects on my plate and not sure how much work this is going to be so I can't really make any promises at this time.

[synfinatic]

I don't even want to think about how many years it's been since I've written C, but apparently I haven't forgotten everything. Anyways this should make it much easier to understand what is going on.

[synfinatic]

Okay, I think I see the problem. This is a portion of the packet capture showing packets coming in and out of eth0 on the RasPi:

Notice the iPhone (10.6.0.2) is sending a series of Queries to the broadcast address (10.0.1.255) on your LAN and that your Roon Core (10.0.1.25) is replying in the 3rd packet (packet 20). I know this reply is for this query, because the TID (transaction ID) in the Roon query and reply matches. But the IP address the Roon Core is sending the packet to is 10.0.1.112 and not the address of your iPhone (10.6.0.2). This means that the Core is learning the wrong IP address for your iPhone. If I look in the entire pcap file, I see the same pattern- all of the replies are to 10.0.1.112. This would explain why the Core doesn't "see" your iPhone as an audio endpoint. It needs to be able to connect to your phone to do that, but it will end up using the wrong IP address so that will fail.

So at this point I don't have enough information to know why that is happening. My only guess right now is that your RasPi is doing NAT and there are packets that aren't showing up in the packet captures and the Core is getting confused. The way I would normally debug this further is run tcpdump on the Core, but since I believe you are using the Roon Appliance I don't believe that is possible?

You can however verify you don't have any NAT rules installed on your RasPi with the following command iptables -t nat --list

The other option is this is a bug in the Roon Core specific to "Roon OS" that doesn't exist normally. Perhaps rebooting the Core will fix it.