Posts: 5
Joined: Jan 2013
Reputation:
0
I've done some more digging and discovered that the UDP multicast stream actually starts - when using tcpdump I see entries like this:
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
17:35:05.418080 IP (tos 0x40, ttl 60, id 23401, offset 0, flags [none], proto UDP (17), length 1344)
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
17:35:05.420978 IP (tos 0x40, ttl 60, id 23411, offset 0, flags [none], proto UDP (17), length 1344)
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
17:35:05.423917 IP (tos 0x40, ttl 60, id 23421, offset 0, flags [none], proto UDP (17), length 1344)
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
17:35:05.426860 IP (tos 0x40, ttl 60, id 23429, offset 0, flags [none], proto UDP (17), length 1344)
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
17:35:05.429806 IP (tos 0x40, ttl 60, id 23438, offset 0, flags [none], proto UDP (17), length 1344)
172.17.141.81.5000 > 239.10.2.10.5000: [udp sum ok] UDP, length 1316
however, it doesn't display anything.
I've also tried with tvheadend and got a similar result. On the network I see that the stream starts, yet tvheadend says no input detected.
I am not sure where else to look to be honest - is it a kernel issue?
Posts: 5
Joined: Jan 2013
Reputation:
0
I've figured out what the problem was - it seems in the new version the firewall is set much more aggressively, only allowing access from the local network. Since multicast streams are obviously not from the local network, they get blocked.
an iptables -F seems to solve the problem.