NEW: DVR Server + Tailscale integration, for easier Away from Home access (Experimental)

Thanks, yeah - I definitely get that it's a beta feature, I'm mentioning also because I am willing and able to help troubleshoot this if someone needs logs, but on the otherhand, if it's been looked at, and determined to be just a fact of how some of this is implemented and it isn't going to change, I'd stop mentioning it..

If a dev sees this, wants logs or some other way I can help, I'm happy to do so.

As for running it as a docker, I'm less familiar than I'd like to be with dockers themselves.. I do run some containers on my UnRaid systems, and I'm close to giving it a shot with this, but with channels being so important on the "Family acceptance factor" scale, for now I've left it as a windows VM where I'm more familiar, and if something goes wrong, I can more easily correct it due to familiarity.. I do get that there's an argument to be made that the docker is more reliable, and that's probably true.. I will get there, it's just going to take time!
Thanks for all your info and help!

1 Like

This has been resolved in the latest pre-release that will be available in a few minutes. When you log out of Tailscale in Channels DVR Server, and log back in, it will use the same hostname and will also retain the same IP address.

AWESOME! This is great news!! This feature has been amazing.. Definitely available if there's anything I can do to troubleshoot or send logs for any further testing of this!!

Thanks so much!

3 Likes

This Tailscale support has been released as generally available. Thanks for everyone’s help!

If this happens again, please submit diagnostics as soon as you notice it and let us know here.

If you could update to the latest pre-release coming out shortly v2023.09.21.2118 and then submit diagnostics, I may be able to get more useful details about what's going on now.

This is done:
d2621746-f09b-4f40-8f30-87968bbf3d56
Let me know if you need me to send the email as well.
FWIW, when I did the update, it did cause me to need to reconnect tailscale, but as you said would happen, it did keep the same hostname this time. It only generated a new hostname twice out of maybe 10 restarts..

Thank you for the diagnostics. We have a build coming out shortly that may help — can you try out v2023.09.21.2256 and once it updates and you login, restart the DVR once more and let us know if it loads without needing to re-authenticate?

It looks like we had an issue with Windows that was preventing us from persisting the Tailscale information we needed to across restarts.

1 Like

Thanks for the quick response!!
I upgraded, and it needed me to reconnect to tailscale, which I did, then I used the services control panel to restart the channels DVR service, and it needed me to re-connect again, so I dont think it worked for me. I uploaded more diags: 68b88d30-3342-4413-8cc1-01d741dbd4d0

I also tried it twice, because I thought perhaps I didn't wait long enough to let it reconnect to tailscale in the background, but even after 4 minutes now it is still not connected (I've refreshed the admin webpage several times).

Happy to run wireshark or fiddler traces, or forward logs from windows if it will help..
-Steve

One other comment - I do notice on the diags screen it tells me I dont have firewall rules in place for channels DVR but when I look at the firewall rules, they're there:

Also, regarding a DNS error about using google DNS, I dont think it's relevant here, but just for full disclosure, I'm running an active directory domain here at home, and have a very "non standard" DNS setup to say the least. If you think DNS may be an issue, I'll revert at least the channels server to something more traditional, but DNS is working for everything else..
(Long version of the story is that I have my virtual DCs setup with secondary NICs which are configured with 1.1.1.1 and 1.1.0.1 which are real public DNS servers. By advertising those routes from my domain controllers, I can let my member workstations use "1.1.1.1" as DNS and still be accessing my local active directory for proper internal name resolution, while at the same time if the DC's go down (it is an unreliable home lab afterall), the route advertisements go away, and my various hosts around the house revert to the REAL 1.1.1.1 on the internet and continue to work.)

Hello,

I have an issue with tailscale - as soon as I enable tail scale I cant even watch my playlists locally as it essentially overwrites the IP address Channels uses.. I have a TVHeadend server where I essentially manage all of my channels from different sources and pass a curated custom M3U list to Channels on a local IP address.

As soon as I enable Tailscale - it throws the following error when streaming - or modifying the playlist settings and hitting save.

Replaced IP address below with LOCAL_LAN_IP and TAILSCALE_IP
This isn't how it should work with tailscale and I dont have this issue with any other tailscale service I use.

Error message:

 invalid source url: Get "http://LOCAL_LAN_IP:9981/playlist/channels.m3u": read tcp TAILSCALE_IP:46419: connection reset by peer

Version of Channels - 2023.09.21.2256 - Pre-Release Channel.

Please go to Support -> Troubleshooting -> Submit Diagnostic Logs from the web interface of the DVR and let us know when it's been submitted so we can have a better idea of what was going on.

thanks for reply Eric, logs submitted f8e153f2-d3ee-4cd8-a304-fb2f4064ee77 ill email support

It looks like there’s something funny going on with your subnet routes and how we have our Tailscale integration setup. I’m very surprised this wouldn’t Just Work. Can you confirm that other Tailscale clients that aren’t on the same network as the 10.0.0.0/8 hosts are able to reach that .40 endpoint over Tailscale?

Yep my thoughts too!
My whole tailnet is able to reach the 10.0.0.0/8 subnets.
The .40 is reachable (I’m actually away from home now, and able to hit the .40 on my phone over Tailscale.

But what I don’t understand is why is it even messing with the playlist creation/addition etc? That shouldn’t even be a problem since that’s on the LAN to the server…
That Tailscale address should just be used for listening to rather than changing the entire ip table of the container?

I also don’t understand why no one else numbed into this yet :joy:

1 Like

Because the way we’ve hooked into Tailscale with our integration is taking any IP that is exposed as a route over Tailscale and sending it over the tunnel. What should be happening is the connection should go over Tailscale to the tunnel to the subnet router and then to the destination (because we don’t have an easy way to identify what is local and what isn’t).

We currently tunnel anything that is exposed over Tailscale via Tailscale, but it may make sense to only try to connect to IPs in the main Tailscale netblock over Tailscale.

I’m guessing there aren’t a lot of folks that have enabled the subnet routing on Tailscale…

I’ll see about adjusting the logic when I get a chance…

Thanks for the responses Eric much appreciated, I’ve got an alternative work around at the moment but glad it’s just not me going crazy and doing something dumb!
Let me know if I can be of help to test this when you guys get around to it, happy to help.

Looks like the Windows issue with reconnecting is a bug in Tailscale that we will need to figure out how to fix or work around.

1 Like

This should fix the Windows auto-login issue.

3 Likes

I just started with T-Mobile, Will tailscale work with Western digital?

1 Like

Are you talking about a Western Digital NAS -- or what exactly?

One of the great things about Tailscale is that it is unaffected by multiple layers of NAT (Network Address Translation), which includes things like the CGNAT use by most cellular providers.

If you are talking about a WD NAS, basically anything that runs Windows, macOS, or Linux can run Tailscale. In addition, Tailscale is available in various app stores for install on phones and tablets. Though not totally mandatory, Tailscale is at its best when run directly on the device.

1 Like