Hooverdan96
commented
3 years ago Confirmed connections:
random port (tcp) --> 8003 @ 216.218.230.212 (Silicondust server, assuming program guide, other info?)
65001 (udp) discovery, (tcp) control, but haven't observed that.
5002, 5004 (udp)
80 (tcp?)--> webpages (not sure whether this is inbound or outbound, i.e. tuner responds via port 80 to dvr engine vs. the other way around)
5000 (udp) LIRC for IR on HD Homerun
if port=port_number specified in conf file, it will listen on/use that port (looks like tcp only), i.e. for this project 59090 and seems to be using it during recording (and LiveTV stream buffering), e.g.:
tcp 0 449424 192.1.0.221:59090 192.1.0.234:61557 ESTABLISHED 0 80782420 20663/hdhomerun_rec
other forums' entries: 5353 (udp) using mDNS - not observed yet 554 (udp)
When opening all of the above ports (without net=host) then discovery of tuner already fails ...
only sending a discovery request to docker ip:
Recording: sending discover using local ip 172.17.0.1 (I assume, it essentially sends to localhost)
response is then received:
Recording: discover response from XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX http://172.17.0.1:59090 <--- DVR ID
when net=host, then it's sending a discovery request to the host IP (e.g. 192.16.0.221)
Recording: sending discover using local ip 192.1.0.221
response is then received:
Recording: discover response from XXXXXXXX http://192.1.0.234:80 <---- Tuner ID
but not sure from which port this discovery request originates (might be a random port) .. have to catch it in flagranti
macvlanmight be the only alternative to net=host
split out from issue #8
despite managing udp port 65001 and opening a tcp port, still seems not enough ... when running container with --net=host, then no issue ... let's see whether anybody else has solved this (I seem to see a few containers out there, where only udp port is opened, but haven't tried those.