Project

General

Profile

Bug #5677

Sat>Ip Server on 2nd NIC / 2nd Subnet not found by Tvheadend

Added by cy clic about 1 month ago. Updated 28 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
General
Target version:
-
Start date:
2019-07-06
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.2.8-32~g2d020e8f2
Affected Versions:

Description

I have an hts server with 2 nic each with different subnets.
Gateway is on subnet 1.
Inspection of ip route output seem correct.
Ping of a sat>ip server in subnet 1 finds that device and
Ping of sat>ip server in subnet 2 finds the other device.
Ping -I each nic "positively" confirms the same.
However
Tvheadend finds the sat>ip server in subnet 1 but
does not find server in subnet 2.

History

#1

Updated by cy clic about 1 month ago

Same on HTS Tvheadend 4.3-1801~g7f952c2ed

#2

Updated by cy clic about 1 month ago

cy clic wrote:

Tvheadend finds the sat>ip server in subnet 1 but
does not find server in subnet 2.

I have not been able to identify anything wrong with configuration.

For clarification-
On the tvheadend server (TvH) there are 2 nics :
eth0 @192.168.1.x - leading to nas, kodi clients, etc, + default GW.
eth1 @192.168.10.1 - to a "private" subnet
dhcp-dnsmasq for 192.168.10.0/24 running on tvH server.
intent -- separate satip traffic from the rest.

TvH correctly (via eth0) finds unwanted sat>ip server on 192.168.1.y
TvH does not (via eth1) find wanted sat>ip server on 192.168.10.z
No desktop on TvH server (usually headless).
192.168.10.z is correctly setup from reserved MAC.
TvH console with wget can read both satip description.xml
So connections/communications seem ok.
Sat>ip 2x server hardwares has been swapped around - no change.

Do you know why TvH finds satip on eth0 but not on eth1?
Is there a way to specify address-range of wanted satip server?
(Like there is for client access to TvH)
Is there a need to specify interface for satip server?

#3

Updated by cy clic about 1 month ago

To demonstrate that the there is access to/from the sat>ip server I knocked up a script to demonstrate:
-------------------------- cat sed-uuid

echo "Hello"
echo "Run via ssh to server running tvheadend which is blind to local satip"
echo "Firstly access a sat>ip server via etho elsewhere out on the LAN"
echo "identical satip hardware - just different uuid - even been swapped"
ping -c 3 192.168.0.51 | grep icmp_seq
wget --no-verbose -O eth0-192.168.0.51-description.xml 192.168.0.51:8000/description.xml
echo -n "eth0-192.168.0.51-description.xml : " && cat eth0-192.168.0.51-description.xml | sed "
s/^.*uuid/uuid/g
s/<.*$/\n/g"
echo "Secondly the desired sat>ip server on its 100% private eth1 subnet"
ping -c 3 192.168.10.50 | grep icmp_seq
wget --no-verbose -O eth1-192.168.10.50-description.xml 192.168.10.50:8000/description.xml
echo -n "eth1-192.168.10.50-description.xml: " && cat eth1-192.168.10.50-description.xml | sed "
s/^.*uuid/uuid/g
s/<.*$/\n/g"
echo "bye bye"

-------------------------- ./sed-uuid

Hello
Run via ssh to server running tvheadend which is blind to local satip
Firstly access a sat>ip server via etho elsewhere out on the LAN
identical satip hardware - just different uuid - even been swapped
64 bytes from 192.168.0.51: icmp_seq=1 ttl=64 time=0.909 ms
64 bytes from 192.168.0.51: icmp_seq=2 ttl=64 time=0.906 ms
64 bytes from 192.168.0.51: icmp_seq=3 ttl=64 time=0.851 ms
2019-07-11 12:10:33 URL:http://192.168.0.51:8000/description.xml [1239/1239] -> "eth0-192.168.0.51-description.xml" [1]
eth0-192.168.0.51-description.xml : uuid:20e20de2-1dd2-11b2-8e99-ebcdff038f38
Secondly the desired sat>ip server on its 100% private eth1 subnet
64 bytes from 192.168.10.50: icmp_seq=1 ttl=64 time=0.947 ms
64 bytes from 192.168.10.50: icmp_seq=2 ttl=64 time=0.902 ms
64 bytes from 192.168.10.50: icmp_seq=3 ttl=64 time=0.894 ms
2019-07-11 12:10:35 URL:http://192.168.10.50:8000/description.xml [1239/1239] -> "eth1-192.168.10.50-description.xml" [1]
eth1-192.168.10.50-description.xml: uuid:2df0b786-1dd2-11b2-9973-afffb291836c
bye bye


Note that I do not need to specify the interface for ping & wget for them to find the ip>sat server. Also the tvheadend server itself hosts the dhcp which the sat>ip server uses to get its own ip address.

Am I doing anything wrong?
Surely tvheadend must be able use a sat>ip server on its own eth1 interface (and for which there is a sound technical motive)?

#4

Updated by Dave Pickles about 1 month ago

Sat>ip uses UPnP for service discovery, which in turn uses IP multicast. Maybe there is an issue with the handling of multicast packets across your networks?

#5

Updated by Jaroslav Kysela about 1 month ago

TVH has not have a support for multiple LANs for PnP yet. Use --satip_xml option to define the SAT>IP server statically on the second subnet.

#6

Updated by cy clic 28 days ago

Jaroslav Kysela wrote:

TVH has not have a support for multiple LANs for PnP yet. Use --satip_xml option to define the SAT>IP server statically on the second subnet.

Thanks to Dave and yourself for the feedback.
I confirm that --satip option does activate the second (eth1) interface e.g.
/etc/default/tvheadend -->
TVH_ARGS="--satip_xml http://192.168.4.50:8000/description.xml" did not do the job however
OPTIONS="--satip_xml http://192.168.4.50:8000/description.xml u hts -g video" did work,
But restart did not work -
reboot was necessary.

Afterwards, satip servers were available on both eth0 (as before) and on eth1 (the private subnet).
This setup has been working for 4 days using all 8 tuners on the private eth1 subnet ip>sat server without any problem.
The dual gigabit Ethernet connection shows a visible improvement in performance especially zapping.
Success.
It would be very desirable to have the process of normal satip server discovery working as the current setup is in effect "hardwired" so not so useful for a "production environment".

Many thanks - good luck with the discovery.

#7

Updated by Flole Systems 28 days ago

I'd say that automatic discovery is not suitable for a "production environment", you want static addresses and definitely don't want to rely on UPNP.

Also available in: Atom PDF