Talking to Roon from another VLAN (I got it working)

Either of you @scottyk or @Robert_Schuff have any luck with my docker container for the UDMPro?

Do you know if anyone ended up getting this to work on the UDM Pro? I have wireguard installed and can connect to Roon remotely, however the endpoint on the phone is not showing up. Happy to test for you if needed

Hi @Aaron_Turner,

Thanks for all the hard work here, this is awesome.

I’ve recently been trying to get this to work on my UDM using your docker container, but it’s not quite working. I fixed the typo here (udp-proxy-2020/40-udp-proxy-2020.sh at main · synfinatic/udp-proxy-2020 · GitHub), which I can submit a PR for, but then when I try to start the container using podman, I get this error:

standard_init_linux.go:207; exec user process caused "exec format error"

I’ve seen this error when working with docker before, usually if the architecture isn’t right. Any ideas from here?

Oh, glad someone finally tested that. I got tired of waiting so I merged and of course there’s a bug. :slight_smile:

Your idea that you’re using the wrong binary is probably correct. I believe you should be using the Linux-ARM64 binary: https://github.com/synfinatic/udp-proxy-2020/releases/download/v0.0.6/udp-proxy-2020-0.0.6-linux-arm64-static

What kind of phone? I don’t use wireguard, but works fine with OpenVPN & iOS and Mac.

At least with iOS, I’ve noticed Roon sometimes gets confused and you need to fully restart the Roon app (double click home button and then swipe up on the Roon app).

Sorry, dunno about Android- hopefully someone else will chime in.

Wow, thanks for the prompt response.

I was under the impression that docker/podman automatically selected the correct architecture, but I see that the docker image here (Docker Hub) only has AMD64. Just now, I tried to build the ARM64 Docker image locally but I’m running into build errors. If it works for you, can you push your ARM64 build to that repository?

For reference, here is the error I’m getting:

STEP 4: RUN apt-get install -y     binutils-aarch64-linux-gnu     linux-libc-dev-arm64-cross     gccgo-10-aarch64-linux-gnu     gcc-10-aarch64-linux-gnu     golang-1.14-go     libgo14-arm64-cross     libgcc-10-dev-arm64-cross     libc6-arm64-cross     libc6-dev-arm64-cross
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package gccgo-10-aarch64-linux-gnu
E: Unable to locate package gcc-10-aarch64-linux-gnu
Error: error building at STEP "RUN apt-get install -y     binutils-aarch64-linux-gnu     linux-libc-dev-arm64-cross     gccgo-10-aarch64-linux-gnu     gcc-10-aarch64-linux-gnu     golang-1.14-go     libgo14-arm64-cross     libgcc-10-dev-arm64-cross     libc6-arm64-cross     libc6-dev-arm64-cross": error while running runtime: exit status 100

And after looking at the relevant packages (Ubuntu – Package Search Results -- gcc-10-aarch64), it seems that this package isn’t available for the ARM64 architecture. A bit confused here.

oh… right. uh, that’s kinda embarrassing. I shoulda known that. :slight_smile:

Anyways, I’ll have to dig into this and see what happens. It’s probably one of those things that takes either 10min or 10hrs to fix since I already have a cross-compile toolchain for arm64, but honestly no idea if I can just use that for this or not.

Small update here: I built the ARM64 Dockerfile on my AMD64 computer and pushed it to this repo: Docker Hub. It still gives me the same error when I run it on the UDM.

I believe that the docker build isn’t made quite right. It’s built to crosscompile as if we only export the binaries, but rather the docker build command needs to use docker buildx (Docker Buildx | Docker Documentation). If buildx isn’t used, then the docker image will only work on the architecture it was built on. If you try to use buildx (or just build on ARM64 directly, like I did originally), then you’ll error out because the cross-compile binaries aren’t available on ARM64. To replicate my original error, you can run this command:

docker buildx build --platform linux/arm64 -f Dockerfile.arm64 .

At any rate, I tried downloading the binary raw and running it on the UDM (just to see if it works). Unfortunately I’m getting this error:

FATAL[0000] l2tp0: has an invalid layer type: Linux SLL

I’m using a L2TP VPN, as that’s the only one supported by UDM afaik. I started to look into what Linux SLL is, but I’m reaching the end of my network foo. Perhaps the code doesn’t work unless we’re using OpenVPN?

I don’t think that L2TP will work. Last time I checked I thought it doesn’t expose a network interface (e.g. eth0). It did work when I was using Wireguard (on a USG).

When I run ifconfig, I get this block in the result:

l2tp0     Link encap:Point-to-Point Protocol
          inet addr:10.255.255.0  P-t-P:192.168.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:613 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:157686 (153.9 KiB)  TX bytes:142427 (139.0 KiB)

I thought that this block indicated that it exposed a network interface, but perhaps my lack of networking knowledge is showing (I’m definitely one of the 99% of software devs that doesn’t know enough about networking that @Aaron_Turner refers to lol).

So I ended up doing the docker thing a little differently… would appreciate someone could verify:

As for Linux SLL… Yeah, that’s fake: SLL - The Wireshark Wiki :frowning:

Basically there are times when libpcap doesn’t return the actual L2 headers- instead it just makes things up. That’s Linux SLL. So there’s no way of knowing the original data and injecting it back onto the network since I don’t know what the L2 header should look like.

Your newly constructed Docker image is the correct architecture when I pull it from Dockerhub to use it on my UDM. Thanks for the fix :slight_smile:

From here, the issue I’m running into is this SLL error I posted earlier. It’s a fatal error, so the docker container crashes out a few seconds after startup. Based on your description, I’m gathering that L2TP won’t work at all (i.e. no fix for this one). Is that right? If so, I’ll try using Wireguard.

Glad to hear it!

So yeah, no way to get L2TP working. Site-to-Site IPSec VPN is supported… but not very useful for most people. Wiregard should work from what I’ve heard from people testing, but I haven’t tested it personally.

I am having some trouble getting Wireguard set up. Do you mind sharing your config or any gotchas you ran into along the way? Are you connecting from iOS?

Update: I got it to work. :slight_smile:

For future readers: I was able to get remote play working with the UDM using Wireguard, leaning heavily on the boostchicken/udm-utilities repo. To connect to iOS, I downloaded the Wireguard application.

I am definitely a Wireguard noob, so I relied heavily on this article for the configuration of Wireguard on both my server and my client.

So far, it works really well. Sometimes I need to restart the Roon application if it’s not working quite right, but haven’t had any long-term issues. Really awesome. Big thank you to @Aaron_Turner and @Nepherte!

2 Likes

Glad to see you got it working, I used the wireguard from the link below which runs in kernel mode so it should work faster than wireguard-go GitHub - tusc/wireguard-kmod: WireGuard for UDM series routers.
I ended up getting roon to work on android, I needed to keep Roon open for about 5 mins before the phone endpoint decided to show up.

I’ve seen long delays like that before. While I haven’t tried wireguard or the UDM, you might want to try:

  1. Restarting roon on your phone/PC.
  2. Restarting your Roon Core/server

And see if either of those speeds up the process.

Just in case people here aren’t following the other thread, there are now udp-proxy-2020 binaries for NetGate SG-1100, SG-2100, and SG-3100 series firewalls (aka FreeBSD ARM64 and ARMv7).

You can (for now) download these binaries here. In the future, the binaries will be available as part of every official release which is always listed here.

1 Like

FYI, there is a new release of udp-proxy-2020 available which fixes a critical issue with the SG5100 (and possibly other devices). If you’re experiencing difficulty with Roon discovering your core or audio outputs it’s worth an upgrade. As always updates are available here.