Bug #3437
TVHeadEnd can't access a stream from itself if Access Entries - Network prefix is modified
0%
Description
I have a situation where TVHeadEnd needs to be able to see its own output in order to do additional processing on a received stream (I am trying to use a solution from a web page at http://freetoairamerica.wordpress.com/2015/09/03/fixing-the-audio-on-live-tv-from-a-certain-network-which-shall-remain-nameless/) and if I try to use a Network prefix to restrict access to my local network (such as 192.168.10.0/24) then TVHeadEnd can't access itself, probably (I would guess) because it appears to be coming from 127.0.0.1. If the Network prefix is changed to 0.0.0.0/0 then it all works. Anyway I would think that TVHeadEnd should be able to communicate with itself no matter what is in the ACL. I opened a thread on this at https://tvheadend.org/boards/5/topics/19211 asking if there is some way to specify both addresses in the Network prefix field but I'm think that TVHeadEnd should have some kind of internal rule that allows access from itself no matter what rule is used for the Network prefix.
General comment, the term "Network prefix" is a bit confusing, why not just use a heading like "Allowed IP addresses" or something that more clearly indicates the usage of this field? Not a big deal, just a suggestion.
History
Updated by saen acro almost 9 years ago
Updated by Question:
Why not using internal transcoding with URL with include profile, then use some re-streaming software as ASTRA to serve to Web clients?
/tested working/
Updated by K Shea almost 9 years ago
Updated by A. I have no idea how
B. I have absolutely zero interest in adding yet another piece of software ("re-streaming software as ASTRA", which I have never heard of) to the mix.
If there is a better way to do this using just TVHeadEnd and ffmpeg I would be very interested in hearing about it.
Updated by saen acro almost 9 years ago
https://cesbo.com/en/astra/quick-start/#cmd-relay
re-streaming feature is perfect used with most iptv servers for MAG stb's
Updated by K Shea almost 9 years ago
Already told you I am not interested in adding another piece of software to the mix, and this is a bug report, not a discussion forum. Beyond that, I think you may have the mistaken idea that I'm trying to receive a channel in Europe, when I'm actually in North America and trying to receive a channel here.
Updated by saen acro almost 9 years ago
Then just permit 127.0.0.1 or use local C group addresses.
But better use correct network rules.
h3.
Explanation of your case is very confusing
Updated by Jaroslav Kysela almost 9 years ago
Updated by - Status changed from New to Invalid
It's very unclear the purpose, but I agree that it does not seem like a bug at all. The 'network prefix' was renamed to 'allowed networks' in the development version of TVH.
Updated by K Shea almost 9 years ago
I don't know what could be confusing about it. At its heart the problem is that if you try to use a Network prefix to restrict access to a local network (such as 192.168.10.0/24) then TVHeadEnd can't access itself. The reason I filed the bug report it because it seems to me that no matter what rule is used in that field, TVHeadEnd should assume that 127.0.0.1 (or "localhost" or whatever it sees itself as) is allowed to connect. Otherwise you create the situation where a simple typo could make the web interface inaccessible to anyone, even if you can open a web browser on the machine running TVHeadEnd (which I can't because it's a server only).
And the secondary reason is that the help screen does not give any clue whether it is possible, or if so what the correct syntax would be, to specify two different addresses or address ranges in that field. My ASSUMPTION is that once it finds a rule matching the username and password it won't check for any other entries for that same username and password, so if you have multiple rules it will only see one, and I don't know if it would use the first or the last on the list. That's why I don't just experiment - I am afraid of locking myself out of the system completely!
sean acro, you keep trying to solve my specific issue and that is not the reason I created this report. If you want to discuss that, there is a thread open at https://tvheadend.org/boards/5/topics/19211 but again the reason I am trying to do this should not matter. I don't know if you are shilling for that software you keep trying to get me to introduce into the mix, but using that to solve this issue is not an option I'd even remotely consider. If you MUST continue (I'd recommend you don't), please take it to the forum, but I don't know how I could have stated the basic problem any more clearly.