I have a Deco router which is anchored at 192.168.68.68
The ChannelsDVR service is currently running under a rootless container which... does its own thing for networking.
If it's doing its own NAT translations... and replacing the source IP address?!?... then that might explain things a bit.
So you forwarded the port to which IP?
A regular docker container would not behave in this way. I'm not sure how your container environment has networking configured. It seems like it's using a reverse proxy.
This is the setup script I'm using currenty:
#!/bin/bash
export TZ=`cat /etc/timezone`
export VIDEODEVICES=`find /dev -type c -name video* -printf "--device=%p "`
# remove any existing container
/usr/bin/podman --cgroup-manager=cgroupfs stop -t 10 channelsdvr
/usr/bin/podman --cgroup-manager=cgroupfs rm channelsdvr --force
podman create \
--label "io.containers.autoupdate=registry" \
--name channelsdvr \
--conmon-pidfile=/run/channelsdvr/conmon.pid \
--publish 8089:8089/tcp \
--userns keep-id \
--group-add keep-groups \
--device=/dev/dri/renderD128 \
${VIDEODEVICES} \
-e TZ=${TZ} \
-v /etc/localtime:/etc/localtime:ro \
-v ~/config:/channels-dvr:Z \
-v /media/archive/dvr:/dvr:z \
-v ~/Database:/dvr/Database:z \
-v ~/Streaming:/dvr/Streaming:z \
-v /media/archive/media:/media:ro \
docker.io/fancybits/channels-dvr:latest
Ah, found this in the podman instructions:
10.0.2.100. If the application requires the real source IP address, e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for rootless containers when connected to user-defined networks.One question I have is... if I change this, will I lose access as 192.168/16 will no longer be considered "local" ?
(And also... a little weirded out by an address misconfiguration causing a security fault in my system)
yay I've just lost local access to the DVR now
what's the address for remote administration again?
EDIT: nevermind got in with an OAuth code. something has changed though it looks.
I'm guessing you hit the Troubleshooting page when you had remote access enabled (which will notice that you are exposing your DVR with a proxy that is hiding the source IPs and will require authentication for everything connecting from that IP).
You'll see under Settings -> General that the IP has been flagged in the "Remote Streaming" section.
ah yes I see that now. Heh, actually happy to see that actually.
I guess the question now is whether it's possible to manually specify the (list of) local networks in ChannelsDVR.
With your current network configuration, your DVR cannot distinguish between local end remote networks, because everything is coming from 10.0.2.100. Once you resolve that so that the actual source IPs are coming through (the easiest way is likely to use something like --net=host), all of this should be resolved.
Will it consider 192.168/24 to be "local" with an interface on a different subnet, or are you saying this needs to be on the same subnet in order to function?
RFC says its local
I actually use Podman as root with macvlan networking; that way each pod shows up as a separate device in the network.
I personally find using rootless containers to be more trouble than it's worth because of situations like this.
ok kewl, if that's what ChannelsDVR uses then I just need to switch the port manager over.
...and if it doesn't, then i switch to host networking (at least I won't need the avahi service definition anymore)
We have some fixes in the works to mark internal IPs as needing authentication sooner (the thing that prevents this sort of setup from giving full access to the internet) and also the HTTPS restriction you requested earlier. We'll follow up when they make it into a pre-release build.
Thank you, that was the one possible takeway I could come up with after this was resolved (or the fact that I'm hours into damage mitigation mode before the fire alarms go off -- not the first time).
Currently waiting for a movie to finish recording, after which I will be seeing if adding this line to my podman create command resolves this issue for me:
--network slirp4netns:port_handler=slirp4netns
Latest pre-release build has this HTTPS check.
Kewl, ChannelsDVR restarted, "HTTP Logging" now shows the expected IP addresses, and connecting without the WiFi is now just giving "not authenticated" messages.
I'm thinking Eric gets the green checkmark for this thread as being the most helpful 