Unable to visit server via its local address to perform initial setup

Channels DVR Server
#1

I use macvlans on my Docker host instead of having everything run on the "host" IP.

When I go to http://x.x.x.x:8083 in my browser (where x.x.x.x is the unique IP address on the macvlan docker network), I just get the message:

Please visit this server via its local network IP to perform initial setup.

This isn't possible; I can't initiate a web connection from within the Docker container... which has its own unique IP address...

To get around this and get the DVR container configured, I had to: stop the container, change my compose configuration from the macvlan interface to host networking, restart the container, use SSH port forwarding to make localhost:8089 on my MacBook forward to port 8089 on my Docker server, open localhost:8089 in my browser, click the button, stop the container, and switch the networking back to the macvlan interface, and finally restart the container.

Also, is it normal to then get asked for an "Authorization Code" to access the server?!

I'm posting because I think the "first touch" experience could be better... :smile:

Shouldn't it be adequate enough to check that the source IP address is part of the local subnet, instead of only matching the "host" IP? Definitely would've saved me a lot of hassle...

P.S. It may be better to make this a simple number indicator with +/– buttons once the number of cores is over 30 or something... :wink:

CleanShot 2021-09-01 at 20.55.23@2x
CleanShot 2021-09-01 at 20.55.23@2x2514Ă—118 31.3 KB

#2

The docs mention host networking explicitly, which is the only thing we've tested with. host networking is also generally required for bonjour to work correctly, which improves the first-run client experience.

It is not normal to get the authorization code prompt, that would only happen if the DVR though the connection was coming from the internet (i.e. not rfc1918).

#3

macvlan networking has all the benefits of host mode networking (including access to broadcast traffic, as required for Bonjour) while allowing dedicated IP addresses for each container. This also alleviates worries about conflicting port numbers in host mode.

Is there a way to change what is considered "local" traffic? Again, I'm surprised that connections from the host's local subnet (easily obtained by running ip route) isn't automatically considered "local". There are more reserved address spaces than just those listed in RFC1918 (such as the blocks in RFC5737).

Since I don't use a common subnet, that must be why I'm getting "Authorization Code" prompts locally... :disappointed:

Any chance you can add support to automatically determine the local subnet (via ip route, for example), or add an option to specify a comma-separate list of subnets that should be considered "local" in the settings?

#4

What netblock are you currently using? We've expanded our list of accepted local subnets in the past and would be willing to add more.

#5

198.18.0.0/15

But rather than maintaining a hard-coded list, why not automatically permit the host's local subnet (or at least have a checkbox in the settings to do so)? It's easy enough to determine programmatically...

(Thanks for the suoer-quick responses, BTW!)

#6

It's not that trivial when you have to make sure it works on windows and bsd and android. Some minimal linux environments don't even include tools like ip, ifconfig or route.

#7

Out of curiosity, is there a specific reason why you aren't using RFC1918 addresses?

#8

Very fair point!

I was specifically referring to when you are running in a Docker container (which is something you have a lot of "control" of), so you should be able to do something like:

local_subnet=$(grep -sq docker /proc/1/cgroup && ip route | awk '/scope link/ {print $1}' || false)

and then things would "just work" (including the initial setup issue I ran into).

Thanks again for the conversation!

#9

I need to VPN into "random" networks whose network configurations are not known to me in advance and/or I don't have control over. There is no telling what private subnets are already in use in those situations, and I don't want to risk an overlap/conflict. It just helps eliminate a possible source of weirdness or confusion.

This is the first time I've run into it being an issue though!

#10

The netblock has been added to the next prerelease. Enjoy benchmarking your DVR :wink:

2 Likes
#11

Out of curiosity... is this preventing me from being able to activate "Channels Plus" in the iOS and Apple TV apps?

I tap At Home, it asks for the IP address, I enter it, tap Save, and it says:

Error
Channels DVR Server was not found at x.x.x.x

If I tail the channels-dvr-http.log file, I can see requests from the various devices doing a GET /status, but it's returning 403 errors... :neutral_face:

#12

Yes, the IP that your client is coming from must be in our list of private net blocks for “At Home” connections to work. You’re seeing the 403 because it’s not coming from an IP in our private net block list and does not have the out-of-home authentication headers being passed.

What netblock are you using for your clients?

#13

tmm1 said above he already added the netblock; seems like I have to wait for the next update.

Any idea how long that will be? (I just started my free trial month yesterday…)

#14

You have to click Check for Updates > Prerelease

#15

Sweet! Updating to the pre-release worked! :tada:

And I didn't even have to type in any IP addresses... the clients just magically connected (I presume via Bonjour, which works just fine in macvlan Docker networks.)

Thanks again for the prompt replies! :+1: As a long-time (and still active) MythTV user, I'm very interested to see how the Channels DVR compares over the coming weeks.

3 Likes
#16

I'm brand new here, trying to set up Channels DVR. Same situation as eddyg-- non-RFC1918 local subnet, to avoid conflicts with VPN to other locations that use RFC1918 addresses. This is the first thing I've ever encountered that cares about addresses but doesn't allow any configuration.

I'm trying to install the DVR headless on Linux. I only get as far as "Please visit this server via its local network IP to perform initial setup." I haven't even gotten to any configuration page.

I'm puzzled that there isn't an optional local config file that would allow to specify a subnet address for local network. That wouldn't require any OS-specific network code.

My network is 199.165.142/24. Any chance to have that added (or a config file)? Thanks.

#17

If you're configuring it remotely, I assume you have SSH access to the server. I wonder if setting up a port forward via SSH would help? That way you can access 127.0.0.1:8089 from your desktop computer, and SSH will forward that request to the remote client's loopback, which ought to be your DVR's web UI.

ssh -L 8089:127.0.0.1:8089 host

Or, if you are using TVE in Channels, you will have Chromium installed; if you are running an OS with an X server such as Linux or macOS, you can use the -X option to SSH to use your local X server to display the remote Chromium:

local_host$ ssh -X remote_host
remote_host$ chromium-browser "http://127.0.0.1:8089"

An additional idea: how about adding an RFC1918 address as an alias to the interface solely for that particular machine? That way you can maintain your non-RFC1918 network, but still have "local" access for your DVR?

#18

Great suggestions. The SSH tunnel is working to get me into the web interface to start the config process. It's now downloading the guide. If I run into any further issues, I will try the second interface alias with an RFC1918 address. Thanks for the help!

#19

Glad it's working for you. (I was going from memory from a similar past experience with a different product/context, so I wasn't sure it would work.)

However, due to the RFC1918/local issues, I think you may need the 'inet alias` part for local clients.