Route instellingen voor multicast IPTV (Concepts ICT)

[viper]

Ik heb hier via Concepts ICT (en Glashart) digitale (IP)TV dat werkt via multicast streams

Wat ik wil is een servertje met twee netwerkkaarten: 1 voor het internet (achter mijn router 192.168.1.x) en 1 voor het digitale TV.

Mijn router deelt prima op mijn ene netwerkkaart via DCHP een 192.168.1.x ip adres uit en daarmee kan ik internetten.

Ik kan op mijn tweede NIC een 'speciaal' DCHP request sturen en dan krijg ik van concepts braaf een ip adres in de 10.x.x.x range op mijn tweede netwerkkaart. Na het openen van VLC kan ik dan ook prima digitale TV kijken.
Het probleem is echter dat mijn default route ook wordt ingesteld op een 10.x.x.x ip adres, waardoor het 'internet niet meer werkt' aangezien het netwerkverkeer naar de verkeerde netwerkkaart geroute wordt.

Als ik echter de default route van mijn iptv NIC weg haalt werkt mijn digitale TV niet meer. Op zich logisch, want het is onbekend waar het (multicast) verkeer heen moet.
Volgens de route manpage zou

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 

de juiste routes toevoegen aan de routing tabellen waardoor het volgens mij weer zou moeten werken.
Als ik echter na het toevoegen van deze route VLC start op UDP://@233.81.233.161:10294 krijg ik echter geen beeld.
Ik zie wel via wireshark dat er via IGMP geabbonneerd wordt op wat multicast addressen en ik zie hier ook MPEG TS pakketten binnen komen op de IPTV netwerkinterface, maar het lijkt alsof zie niet bij VLC aankomen..

De enige manier om het weer werkend te krijgen is het toevoegen van de default route naar mijn IPTV NIC
Enig idee hoe ik dit opgelost krijg?

[CyBeR]

Policy Routing: http://www.policyrouting.org/iproute2-toc.html

Overigens is dat in combinatie met meerdere DHCP-interfaces me nog nooit gelukt, maar je kunt je dhcp interface in je main tabel laten en een tweede routing tabel aanmaken voor je normale internet met statische adressering.

[ Voor 65% gewijzigd door CyBeR op 01-03-2010 22:41 ]

[viper]

Ik kan natuurlijk mijn interne netwerk gewoon statisch configureren.
Heb even dat iproute document doorgelezen, maar zou nog steeds niet weten welke routing regels ik zou moeten maken..
Heb net ff klein C progje geschreven dat zelf een multicast socket opent en alle data die binnenkomt uitspuugt naar stdout. Op mijn werk hebben we ook een IPTV stream en als ik de inhoud van de stream in een file pipe kan ik gewoon TV kijken via VLC, dus dat werkt..

Zal vanavond eens kijken wat ik precies binnen krijg op deze socket, aangezien wireshark wel udp/mpg pakketten voorbij ziet komen. Hiermee kan ik uitsluiten of het aan VLC of touch de routing ligt..

[CyBeR]

viper schreef op dinsdag 02 maart 2010 @ 14:18:
Ik kan natuurlijk mijn interne netwerk gewoon statisch configureren.
Heb even dat iproute document doorgelezen, maar zou nog steeds niet weten welke routing regels ik zou moeten maken..

je hebt twee routetabellen nodig. Een heb je al (je main table), een maak je nieuw aan met ip route add <blah> table <nummer>. Daarna kun je met ip rule selecteren wanneer die tabel gebruikt moet worden in plaats van je normale tabel. Bijvoorbeeld:

code:

ip rule add prio 100 from 10.0.0.0/8 lookup 100

Om, als de source van een packet in 10.0.0.0/8 ligt de routing tabel met nummer 100 te gebruiken. Echter, omdat je iptv-nic dhcp gebruikt zul je dat truukje waarschijnlijk precies andersom moeten uitvoeren.

[ Voor 7% gewijzigd door CyBeR op 02-03-2010 14:24 ]

[TrailBlazer]

In principe zou je helemaal geen route over je "Tv nic" nodig hebben. Je stuur een multicast op je locale segment op je op de TV-stream te aboneren en dat is het wel. Ik denk dat er buiten het multicast verkeer nog wat keepalive verkeer (unicast) naar iets van Concepts ICT gaat. Even met wireshark kijken wat er allemaal over je TV Nic heen gaat buiten multicast misschien.

[viper]

TrailBlazer schreef op dinsdag 02 maart 2010 @ 14:29:
In principe zou je helemaal geen route over je "Tv nic" nodig hebben. Je stuur een multicast op je locale segment op je op de TV-stream te aboneren en dat is het wel. Ik denk dat er buiten het multicast verkeer nog wat keepalive verkeer (unicast) naar iets van Concepts ICT gaat. Even met wireshark kijken wat er allemaal over je TV Nic heen gaat buiten multicast misschien.

Ik bedacht me gisteravond inderdaad dat het heel raar is dat zodra ik mijn default route naar mijn IPTV nic weghaalt het beeld per direct stopt..
Volgens mij is onderdeel van multicast is dat de multicast router regelmatig pollen of er nog iemand geïnteresseerd is in de stream. Zodra er iemand op reageert weet de router genoeg..
Ben dus benieuwd welk protocol er voor zorgt dat er unicast vekeer naar de bron moet.
Zal ook vanavond ff kijken wat er nog aan unicast voorbij komt..

[TrailBlazer]

Eureka momentje.
Wat wel eens zou kunnen is dat een RPF/ IP spoofing check misgaat op het moment dat je de default route weghaalt. Je krijgt dan namelijk een datastroom binnen op een nic van een source terwijl dat volgens de routing table helemaal niet achter die NIC zit. ip spoofing even uitzetten in de kernel voor die nic mischien of even een static route voor de concepts ICT sources voor de multicast stream toevoegen.

[ Voor 21% gewijzigd door TrailBlazer op 02-03-2010 15:20 ]

[viper]

TrailBlazer schreef op dinsdag 02 maart 2010 @ 15:19:
Eureka momentje.
Wat wel eens zou kunnen is dat een RPF/ IP spoofing check misgaat op het moment dat je de default route weghaalt. Je krijgt dan namelijk een datastroom binnen op een nic van een source terwijl dat volgens de routing table helemaal niet achter die NIC zit. ip spoofing even uitzetten in de kernel voor die nic mischien of even een static route voor de concepts ICT sources voor de multicast stream toevoegen.

Naar aanleiding van de keep alive opmerking ben ik ff gaan googlen en inderdaad bij reverse path filtering uitgekomen..Net ff rp_filter op 0 gezet in de kernel, werkt nu inderdaad zoals verwacht.
Gedeeld eureka momentje dus..:)