IPTV werkend op igmpproxy (Debian bookworm)

FREEDOM TV
1

Hallo,

Vandaag is m’n lijn opgeleverd (fiber). Internet was redelijk simpel komende vanaf xs4all. Op linux poff xs4all en pon freedom (config stond allang klaar) en op tijd klaar voor koffie.

TV Ging echter minder makkelijk. Het was best wel een uitdaging om dat CD ding werkend te krijgen zonder dat deze heel internet over dendert. (ACS server niet bereikbaar melding omdat ie daar ‘ergens’ z’n software vandaan wil halen helpt niet) Wat me opviel was dat ik enkele dingen naar internet (pppoe interface via vlan 6) open moest zetten om 'm überhaupt werkend te krijgen:

Oude KPN gaten (xs4all, geen flauw idee wat dicht kan):

  • ntp
  • http en https

Nieuw gat:

  • tcp/7643 (hier over haalt ie z’n eerste software download)

Dat kan vast ook ingeperkt naar een adres range, maar ik had niet genoeg geduld om dat ook nog te gaan testen.

Daarnaast moest ik ook 217.166.225.0/24 opnemen als altnet in de upstream definitie. Daar kwam de live stream vandaan blijkbaar. (een adres, maar ik het het hele /24 segment gepakt, just in case) Een tcpdump gaf een berg verkeer op vlan4 zonder dat deze bekend was.

Ik zag ook dat er erg veel verbindingen naar 185.24.172.0/24 gaan. Hoort dat niet ook via vlan4 te lopen?

Voor de gebruiker zonder FritxBox is de documentatie nog niet compleet genoeg blijkbaar. Kan deze geupdate worden zodat gebruikers weten wat ze moeten instellen om de ontvanger te beperken tot TV kijken only? (en wat er per gewenste app als netflix oid open moet?) Als opvolger van het security bewuste xs4all vind ik ‘zet alles maar open’ voor de TV ontvanger niet echt handig. (hangt hier in een eigen vlan)

Groeten,

KoffieNu

4 likes
2

Ik heb zelf geen TV via het internet maar hier wel af en toe meegelezen.

Het verkeer wat via VLAN 4 gaat is multicast verkeer. Als er andere mogelijkheden van de ontvanger gebruikt worden dan gaat dat over de internet verbinding (VLAN 6).

Het domein m7be2.solocoo.tv is voor streaming zoals terugkijken en halverwege starten. In de APP wordt ook m7cdn.io gebruikt. Dat maakt de range kleiner.

3

Je hebt er nog een paar nodig, naast de software download is er ook een soort licentie server,
De TV gids, en alle Streaming loopt over PPPoE. Alle begin gemist, terug kijken, opnames bekijken, en enkele zenders zijn Streams.
185.24.172.32 :8050 /udp
rest TCP
18.193.34.170 : 7643
18.193.34.170 : 80
18.193.34.170 : 443
104.18.20.226 : 80
104.18.30.182 : 80
104.18.31.182 : 80
151.101.38.133 : 80
185.24.172.21 :443
185.24.172.45 : 443
185.24.172.61 : 12700
185.24.172.71 : 443
34.211.38.36 : 443
35.155.60.123 : 443
35.160.213.88 : 443
35.163.86.242 : 443
35.167.44.87 : 443
35.81.0.135 : 443
44.229.186.215 : 443
52.222.138.108 : 80
52.58.161.128 : 10444
Het lijstje is wat groot dus ik vermoed dat er subnetten achter zitten mogelijk / stream of afhankelijk DNS queries naar actieve servers.

DNS Queries:

0.europe.pool.ntp.org
acs.entone.com
agama.solocoo.tv
amm5.solocoo.tv
browserjs.core.cloud.vewd.com
cdsstatic.solocoo.tv
cdsvideolive.solocoo.tv
cdsvideopvr.solocoo.tv
cdsvideoreplay3.solocoo.tv
cpemgt
cpemgt.entone.com
crl.globalsign.com
ensight-cmd.aminoengage.com
ensight-cmd31.aminoengage.com
ensight-cmd33.aminoengage.com
idx.solocoo.tv
log.core.cloud.vewd.com
m7be2.solocoo.tv
ocsp.globalsign.com
ocsp.usertrust.com
ocsp2.globalsign.com
queue.solocoo.tv
rtspresellercds2.solocoo.tv
static-content.solocoo.tv
static.solocoo.tv
stun.aminoengage.com
tvapi.solocoo.tv
vmxiptv.solocoo.tv
vmxott.solocoo.tv
www.googleapis.com
zerossl.ocsp.sectigo.com

VLAN 4 is voor Lineair TV kijken en gebruikt multicast. Daarvoor is wel een Multicast proxy nodig op een Router en IGMP Snooping in evt. swirches.

Ik heb TV’s, STB ook in een eigen TV-LAN gestopt. en met behoorlijk strakke filter ingesteld.

4

Bedankt voor het lijstje, maar het lijkt hier toch minder goed te gaan. Bij KPN had ik juist problemen met multicast en wilde pauzeren als igmpproxy een herstart nodig had en had ik uitdagingen met live. Nu werkt live kijken prima (streams uit 217.166/16, kpn netwerk, snapnie) en wil pauzeren en opnames kijken (als ik die zou kunnen vinden) niet, zelfs niet met verkeer van ontvanger naar internet ongelimiteerd.

De TV ontvanger zit in een eigen vlan, TV is dom (scherm only). Meer poorten open zetten en de ontvanger herstarten levert overigens minder zenders beschikbaar op. (melding ‘zit niet in abonnement’, vaag)

5

Als je een Multicast pauzeert (dat kan dus niet, want niet heel NL gaat dan op pauze), moet je STB de link overzetten naar een Stream.
(Multicast heeft geen retransmit, geen pauze etc.)

Afzender adressen in Multicast zijn niet heel relevant, en het kan zijn dat een duplicaat DC van KPN is gebouwd in een eigen DC, of dat CD gebruik maakt van KPN servers, dan wel een adres reeks huurt van KPN wie zal het zeggen.

6

Afzender adres 217.166.0.0/16 moest ik wel in de altnets van upstream opnemen om multicast werkend te krijgen (anders neemt igmpproxy de stream niet aan).

I.t.t. de KPN providers komt bij CD de stream voor de rest via internet (vlan6) en daar gaat het hier nu nog niet goed, zelfs niet met ongelimiteerd verkeer uit naar internet voor de TV ontvanger. Ik kom er maar niet achter of ik nou een config fout heb (lijkt me sterk met ongelimiteerd verkeer vanaf ontvanger vlan naar buiten en alle gerelateerde verbindingen mogen naar binnen) of dat het niet werkt door een CD issue.

Edit: tcpdump geeft hier mooi de overgang van multi naar unicast:

14:41:04.327557 IP 217.166.225.110.49152 > 224.0.251.110.8220: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2206162
14:41:04.329086 IP 217.166.225.110.49152 > 224.0.251.110.8220: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2206163
14:41:04.330954 IP 217.166.225.110.49152 > 224.0.251.110.8220: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2206164
14:41:04.331442 IP 10.10.89.42 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:41:04.332167 IP 217.166.225.110.49152 > 224.0.251.110.8220: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2206165
14:41:04.333997 IP 217.166.225.110.49152 > 224.0.251.110.8220: BCM-LI-SHIM: direction unknown, pkt-type unknown, pkt-subtype unknown, li-id 2206166
14:41:04.459144 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [S], seq 3625839839, win 29200, options [mss 1460,sackOK,TS val 14930286 ecr 0,nop,wscale 7], length 0
14:41:04.462484 IP 185.24.175.210.554 > 10.10.89.42.33021: Flags [S.], seq 703065003, ack 3625839840, win 28960, options [mss 1460,sackOK,TS val 2768040274 ecr 14930286,nop,wscale 7], length 0
14:41:04.463473 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [.], ack 1, win 229, options [nop,nop,TS val 14930291 ecr 2768040274], length 0
14:41:04.469362 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [P.], seq 1:109, ack 1, win 229, options [nop,nop,TS val 14930297 ecr 2768040274], length 108: RTSP: DESCRIBE rtsp://rtspresellercds1.solocoo.tv:554/bbcfirstsd.ts RTSP/1.0
14:41:04.472686 IP 185.24.175.210.554 > 10.10.89.42.33021: Flags [.], ack 109, win 227, options [nop,nop,TS val 2768040284 ecr 14930297], length 0
14:41:04.473509 IP 185.24.175.210.554 > 10.10.89.42.33021: Flags [P.], seq 1:398, ack 109, win 227, options [nop,nop,TS val 2768040285 ecr 14930297], length 397: RTSP: RTSP/1.0 200 OK
14:41:04.474367 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [.], ack 398, win 237, options [nop,nop,TS val 14930302 ecr 2768040285], length 0
14:41:04.474688 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [P.], seq 109:253, ack 398, win 237, options [nop,nop,TS val 14930302 ecr 2768040285], length 144: RTSP: SETUP rtsp://rtspresellercds1.solocoo.tv:554/bbcfirstsd.ts RTSP/1.0
14:41:04.478216 IP 185.24.175.210.554 > 10.10.89.42.33021: Flags [P.], seq 398:616, ack 253, win 235, options [nop,nop,TS val 2768040289 ecr 14930302], length 218: RTSP: RTSP/1.0 200 OK
14:41:04.518325 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [.], ack 616, win 245, options [nop,nop,TS val 14930346 ecr 2768040289], length 0
14:41:04.563402 IP 10.10.89.42 > 224.0.0.22: igmp v3 report, 1 group record(s)
14:41:04.589480 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [P.], seq 253:413, ack 616, win 245, options [nop,nop,TS val 14930416 ecr 2768040289], length 160: RTSP: PLAY rtsp://rtspresellercds1.solocoo.tv:554/bbcfirstsd.ts RTSP/1.0
14:41:04.593444 IP 185.24.175.210.554 > 10.10.89.42.33021: Flags [P.], seq 616:727, ack 413, win 243, options [nop,nop,TS val 2768040405 ecr 14930416], length 111: RTSP: RTSP/1.0 200 OK
14:41:04.594376 IP 10.10.89.42.33021 > 185.24.175.210.554: Flags [.], ack 727, win 245, options [nop,nop,TS val 14930422 ecr 2768040405], length 0
14:41:04.594851 IP 185.24.175.210.10000 > 10.10.89.42.2002: UDP, length 1328
14:41:04.597428 IP 185.24.175.210.10000 > 10.10.89.42.2002: UDP, length 1328
14:41:04.601174 IP 185.24.175.210.10000 > 10.10.89.42.2002: UDP, length 1328

In het begin multicast, werkt prima, daarna pauzeer ik en wordt het unicast. Daar gaat het fout, Moet ergens in mijn igmpproxy config zitten, maar ik kan de fout niet vinden.

Config:

quickleave

phyint eth0 disabled
phyint eth1 disabled

phyint freedom disabled

phyint vlan42 disabled

phyint vlan4 upstream  ratelimit 0  threshold 1
        altnet 185.24.175.0/24
        altnet 185.41.48.0/24
        altnet 217.166.0.0/16

phyint vlan44 downstream  ratelimit 0  threshold 1
        altnet 10.13.44.0/24

Disabled op alle interfaces behalve vlan 4 en vlan44 (intern). Hij pakt de switch niet op. (config werkte met kpn iptv, optie over het hoofd gezien?)

Edit: Opnames (gevonden) zijn af te spelen en door te spoelen. Kan ik in elk geval om de niet werkende pauze optie heen werken. (nu nog de grote vraag, waarom wil die pauze niet) Morgen weer een dag.

7

Zodra je pauzeert KAN de multicast niet meer PUNT. Multicast is dat methode waarbij een server EEN reeks pakketten uitstuurt voor ALLE ontvanger in het net. Elke router (IGMPProxy) en Switch (IGMPSnooping) onderweg zorgt voor vermenigvuldiging naar afnemende interfaces indien nodig.
Elk pakket wordt ook maar een maal per kabel verzonden. Bij ontvangst fouten, dikke pech, er zijn geen retaransmits etc.

Als het anders zou werken betekent het dat als er ERGENS op de pauze knop gedrukt wordt dat ALLE ontvangers in pauze stand zouden komen.
Zodra je de pauze weer opheft zou je de multicast weer op kunnen pakken op het moment waar die dan is (niet echt pauze)… maar ook een skip in de stream.
Of het kan omgebouwd worden naar een single private stream… en dat is wat je ziet gebeuren.
Poort 554 is een RTP stream. waarme je je abonneert op de filmstream:
hier verzonden op poort 10000, naar een onderhandelde poort 2002 op de STB.

Unicast wordt NIET door de MC proxy afgehandeld. De data stream is de UDP 10000 → 2002. (in dit geval) die moet niet geblokkeerd worden.

8

Daar ligt mijn uitdaging, die switch man multicast naar unicast gaat niet goed. Bij de KPN connectie was dit niet echt een uitdaging, maar nu ging het fout. DNAT van alles uit KPN/CD netwerk op udp/10k naar de ontvanger heeft geholpen voor ‘start gemist’ (en dan kunnen we ook spoelen)

De laatste horde is de multi/uni switch bij pauzeren. Ik zou verwachten dat dat dezelfde stream zou zijn.

Edit: Check, pauze is dezelfde stream en werkt (met wat geduld, start is traag).

9

De start zou wel een traag kunnen zijn omdat een bepaalde time marker gevonden moet worden om verder te gaan.
De begin gemist stream zal uit een recording komen die eerst ook nog vastgelegd zal moeten worden.

10

De trage start zal inderdaad wel het opzoeken zijn.

Wat me ook opvalt is dat ik streams vanuit het KPN netwerk krijg (uit 172.166.224/225/226.0 heb ik al langs zien komen), maar deze netwerken niet over vlan4 gerouteerd worden, alleen de CD netwerken. Zou dat de reden zijn dat de streams die van multicast naar unicast switchen vanaf dat netwerk niet automagisch goed gaan en ik expliciet verkeer inkomend met source poort udp/10k moet toestaan? (er is geen gerelateerde verbinding voor connection tracking) Leuke om eens uit te testen.

Edit: getest, nop, inkomend met source poort udp/10k moet genat worden. Ah well.

11

Als je dan vanuit een KPN netwerk een PUSH krijgt op poort 10000 dan moet er toch een uitgaande verbinding (2002–>10000) tegenover staan?

Toevoeging: is ondertussen de laatste regel hier weg omdat dat over het algemene internet gaat…VLAN 6?

phyint vlan4 upstream  ratelimit 0  threshold 1
        altnet 185.24.175.0/24
        altnet 185.41.48.0/24
        altnet 217.166.0.0/16
12

Zou ik ook verwachten, maar kan 'm niet vinden. De stream komt vanaf dezelfde server via vlan4. Dat is juist het rare.

Nop, zonder kan ik geen TV kijken. De multicast voor o.a. BBC first en Spike komen vanaf het KPN netwerk via vlan4. Ik kan 'm waarschijnlijk naar 172.166.224.0/22 aanpassen, want ik heb alleen netten 224-226 gezien tot nu toe. (in elk geval voor de zenders die wij als achtergrond op hebben staan)

13

Als die push ook op vlan4 binnenkomt dan lijkt het meer erop dat alles op vlan4 binnenkomt één op één doorgedrukt wordt naar de Amino en dat die dan eventueel een filtering toepast.

Het verkleinen van de range naar /22 is inderdaad beter.

14

Lijkt er inderdaad wel op dat alles door de fritzbox 1 op 1 door wordt gemept. Dat doet mijn vuurmuur natuurlijk niet, wat ik niet verwacht wordt ook niet doorgelaten. Verkeer vanaf udp 10k en de juiste range is nu aan de verwachte groep toegevoegd en wordt geforward.

Het lijkt er haast op dat de ontvanger het verzoek naar de CD servers doet, de CD server sommige streams bij KPN aanvraagt en die servers daarna via multicast het externe ip adres op vlan4 in de groep opneemt en deze de stream te zien krijgt. (oid, geen flauw idee hoe dat multicast echt werkt) Als je dan op pauze drukt is het logisch dat de CD server het verzoek krijgt en daarna dup vanaf de KPN severs wordt gepusht naar de juiste poort. (en dan zegt mijn firewall ‘doei, dat is een nieuwe connectie’) Met stateless icmp/udp lijkt mij dat prima mogelijk. (Ik moet echt dieper is deze protocollen duiken, vorige eeuw voor het laatst gedaan)

15

Als het van één server alleen naar jouw IP adres / ontvanger gaat dan is dat een unicast. en IGMP etc. doet daar niets mee. ICMP doet weer wat anders.

Zit niets anders op inderdaad nieuwe verbindingen van de /22 range komende over vlan4 te accepteren en door te zenden naar de settopbox.

16

Dat is inderdaad de enige oplossing gebleken. Ik vind de driehoek oplossing best wel smerig, maar als het werkt zal het de meeste mensen een worst wezen. Vuurmuur aanpassen en ach, de ontvanger staat toch geïsoleerd in z’n eigen vlan.

17

Je zou kunnen kijken of je ook buiten de vlan4 kunt pingen, er van uitgaand dat Freedom controleerd wat van buiten Freedom via vlan4, jouw router kan bereiken.

18

Hier de CD APP op Android gestart en gekeken wat er van adressen gebruikt worden. Ik zie hier alleen 185.24.172.X & 185.24.175.0 en als BBC first aanzet dan komt dat ook uit dit bereik en niet uit een KPN netwerk.

Aanvulling op de lijst van Noci:185.24.172.11

Freedom zal wel zelf de UDP streams regelen/inkopen bij de KPN. De WebAPP voor TV’s functioneren hetzelfde als de APP en gebruiken dan ook geen UDP of uni/multicast. Dat doet alleen de settopboxen.

De enige UDP die ik heb is een uitgaande naar 224.0.0.7:8001 en dat zal wel de cast zijn naar een ander device zoals een TV of Android dongle in het lokale netwerk/WiFi.

Update: tijdens het testen bleek dat France24 een paar seconden werkt en dan langer niet en dan weer een paar seconden. Het lijkt mij dat het grabben van de stream bij CD niet goed gaat of dat die niet goed het netwerk in gaat.

19

Gisteravond had ik ook een storing op BBC first, elke x seconden (± 5) even een freeze in de multicast stream. Geforceerde switch naar unicast (pauze en play) en het was weg. Er zat gisteren duidelijk iets niet lekker in het multicast verhaal.

20

Ik gebruik alleen unicast en had hetzelfde probleem. Dan zou ik het toch verder upstream zoeken (dichter bij de bron).

Ik keek mee in de firewall/router en er was geen aanwijzing dat de router het veroorzaakte. Nu werkt France24 weer perfect en snel nog even naar BBC first gegaan en die deed het ook prima.