Extreem veel EMM's sinds 20/09/09

[Catastrofus]

Origineel bericht van: DRG

kijk maar eens in de webinterface van CCcam, je zult zien dat er meer EMM's (kaartupdates) zijn dan ECM's (beelddecodering)
normaal http://boxipadres:16001

Code:

+---------+---------------+------------+------------+-----------+---------------+--------+----------------------+| Username| Host          | Connected  | Idle time  | ECM       | EMM           | Version| Last used share      |+---------+---------------+------------+------------+-----------+---------------+--------+----------------------+|dm800    |192.168.1.100  |01d 16:36:23|00d 00:00:21|6009 (5986)|300816 (300659)|2.1.2   | Nederland 2 (ok)     |+---------+---------------+------------+------------+-----------+---------------+--------+----------------------+

Niet meer dus, want ze zijn gestopt met de emm-vloed. Had best wel wat impact op m'n 8000 in het voormalig @home gebied...

Gert.

[dream-on]

vraag me af of dit ook voor de storing heeft gezorgd of zou het puur toeval zijn geweest? ik heb hier zondag en maandag de grootste problemen gehad met ziggo. altijd heel slechte verbinding of helemaal geen.

Maar nu is hier gelukkig weer alles als vanouds.

[Catastrofus]

Origineel bericht van: dream-on

vraag me af of dit ook voor de storing heeft gezorgd of zou het puur toeval zijn geweest? ik heb hier zondag en maandag de grootste problemen gehad met ziggo. altijd heel slechte verbinding of helemaal geen.
Maar nu is hier gelukkig weer alles als vanouds.

Klopt, bij mij haperde sinds zondag-ochtend ieder kabelkanaal na een tijdje. Even zappen naar ned1 hielp weer even. Het kan geen toeval zijn, eigenlijk. Maar gelukkig vielen er ook weer wat "ziggo gecertificeerde" decoders om in het voormalig @home gebied...

Gert.

[Catastrofus]

Origineel bericht van: dream-on

vraag me af of dit ook voor de storing heeft gezorgd of zou het puur toeval zijn geweest? ik heb hier zondag en maandag de grootste problemen gehad met ziggo. altijd heel slechte verbinding of helemaal geen.
Maar nu is hier gelukkig weer alles als vanouds.

Ik vraag mij af waarom mijn dm8000 zo veel problemen had met al die emms, terwijl mijn dm7025, die afhankelijk is van de dm8000 vwb de ziggo-kaart (interne share), gewoon zonder haperingen beeld had. Ik weet dat er ong 2 emms per sec binnen kwamen maar kan daar zelfs een 8000 niet tegen?

Gert.

[ArChie]

Origineel bericht van: Catastrofus

Ik vraag mij af waarom mijn dm8000 zo veel problemen had met al die emms, terwijl mijn dm7025, die afhankelijk is van de dm8000 vwb de ziggo-kaart (interne share), gewoon zonder haperingen beeld had. Ik weet dat er ong 2 emms per sec binnen kwamen maar kan daar zelfs een 8000 niet tegen?

Ik neem aan dat de DM8000 de cardserver is? Zoja, dan vermoed ik dat de cardserver alle EMM's die langskomen uitprobeerd bij de softCAM. Maar enkele van al die EMM's zijn ook daadwerkelijk voor jouw smartcard bestemd wat de DM8000 volgens mij niet op voorhand weet. De softCAM moet een EMM eerst decrypten. Daarna kan pas worden uitgezocht of die EMM voor jouw smartcard bestemd is.

[Catastrofus]

Origineel bericht van: ArChie

Origineel bericht van: Catastrofus

Ik vraag mij af waarom mijn dm8000 zo veel problemen had met al die emms, terwijl mijn dm7025, die afhankelijk is van de dm8000 vwb de ziggo-kaart (interne share), gewoon zonder haperingen beeld had. Ik weet dat er ong 2 emms per sec binnen kwamen maar kan daar zelfs een 8000 niet tegen?

Ik neem aan dat de DM8000 de cardserver is? Zoja, dan vermoed ik dat de cardserver alle EMM's die langskomen uitprobeerd bij de softCAM. Maar enkele van al die EMM's zijn ook daadwerkelijk voor jouw smartcard bestemd wat de DM8000 volgens mij niet op voorhand weet. De softCAM moet een EMM eerst decrypten. Daarna kan pas worden uitgezocht of die EMM voor jouw smartcard bestemd is.

Yep, dat klopt. Ik had begrepen dat een emm altijd werd verzonden met een ecm, blijkbaar niet dus. Maar toch, ik heb een slecht gevoel over deze vloedgolf van emms, deze kan niet per ongeluk ontstaan.

Gert.

[ArChie]

Origineel bericht van: Catastrofus

Yep, dat klopt. Ik had begrepen dat een emm altijd werd verzonden met een ecm, blijkbaar niet dus.

Nee, de EMM pakketten zijn bedoeld om de geregistreerde abonnementen op je smartcard bij te werken en leveren per kanalen pakket één van de benodigde decryptie sleutels op die nodig zijn om de ECM pakketten te kunnen decrypten. Die ECM pakketten horen weer bij een bepaald kanaal en zijn nodig omdat ze de decryptie sleutels bevatten die nodig zijn om de encryptie van data stream pakketten te kunnen verwijderen zodat de MPEG decoder in de ontvanger ze kan gaan verwerken voor weergave.

Citaat:

Maar toch, ik heb een slecht gevoel over deze vloedgolf van emms, deze kan niet per ongeluk ontstaan.

Uiteraard was dat een één of ander experiment van Ziggo en Irdeto. Zoiets gebeurd echt niet per ongeluk en zondag waren er al de eerste meldingen van problemen. Dus als iemand al een foutje had gemaakt met de instellingen van het Irdeto Conditional Access System (CAS) dan zouden ze wel erg dom zijn bij Ziggo als het bijna vier dagen moet totdat zij ook na alle aanwijzingen op de forums weten dat er iets mis is. Verder komt er weer zoals gebruikelijk weer geen enkele verklaring terwijl er toch diverse klanten waren die bijna hun PVR's bij het grofvuil hadden gezet. Gewoon een meerdaags experiment dat eerst afgerond moest worden van Ziggo zich weinig aantrekkend van het feit dat ze met dat experiment klanten hinderden.

[Catastrofus]

Origineel bericht van: ArChie

Origineel bericht van: Catastrofus

Yep, dat klopt. Ik had begrepen dat een emm altijd werd verzonden met een ecm, blijkbaar niet dus.

Nee, de EMM pakketten zijn bedoeld om de geregistreerde abonnementen op je smartcard bij te werken en leveren per kanalen pakket één van de benodigde decryptie sleutels op die nodig zijn om de ECM pakketten te kunnen decrypten. Die ECM pakketten horen weer bij een bepaald kanaal en zijn nodig omdat ze de decryptie sleutels bevatten die nodig zijn om de encryptie van data stream pakketten te kunnen verwijderen zodat de MPEG decoder in de ontvanger ze kan gaan verwerken voor weergave.

Citaat:

Maar toch, ik heb een slecht gevoel over deze vloedgolf van emms, deze kan niet per ongeluk ontstaan.

Uiteraard was dat een één of ander experiment van Ziggo en Irdeto. Zoiets gebeurd echt niet per ongeluk en zondag waren er al de eerste meldingen van problemen. Dus als iemand al een foutje had gemaakt met de instellingen van het Irdeto Conditional Access System (CAS) dan zouden ze wel erg dom zijn bij Ziggo als het bijna vier dagen moet totdat zij ook na alle aanwijzingen op de forums weten dat er iets mis is. Verder komt er weer zoals gebruikelijk weer geen enkele verklaring terwijl er toch diverse klanten waren die bijna hun PVR's bij het grofvuil hadden gezet. Gewoon een meerdaags experiment dat eerst afgerond moest worden van Ziggo zich weinig aantrekkend van het feit dat ze met dat experiment klanten hinderden.

Ok, resumerend, een EMM (subscriber info) heb je nodig om een ECM te decrypten. Een gedecrypte ECM bevat de key om een een kanaal te kunnen decrypten zodat je beeld hebt. Dit alles simpel gezegd. Korrekt?

Blijkbaar ging door de vloedgolf van emms CCcam, van de dm8000, over de rooie. Rest mij de vraag waarom mijn client (de dm7025) geen enkel probleem (haperingen e.d.) had. Hij kijkt wel naar de gegevens die de dm8000, die de ziggo kaart bevat, binnen krijgt.

Gert.

[ArChie]

Origineel bericht van: Catastrofus

Ok, resumerend, een EMM (subscriber info) heb je nodig om een ECM te decrypten. Een gedecrypte ECM bevat de key om een een kanaal te kunnen decrypten zodat je beeld hebt. Dit alles simpel gezegd. Korrekt?

Ja, op hoofdlijnen komt het daarop neer. Zo werkt het in principe voor ieder CAS. De manier waarop al die sleutels op smartcard, EMM en ECM toegepast worden verschilt per CAS, maar uiteindelijk levert het een sleutel op waarmee de data stream pakketten van het weer te geven kanaal gedecrypt kunnen worden.

Citaat:

Blijkbaar ging door de vloedgolf van emms CCcam, van de dm8000, over de rooie. Rest mij de vraag waarom mijn client (de dm7025) geen enkel probleem (haperingen e.d.) had. Hij kijkt wel naar de gegevens die de dm8000, die de ziggo kaart bevat, binnen krijgt.

Ik heb geen idee hoe dat card server / card client gebeuren werkt aangezien ik zelf nog nooit gebruik heb gemaakt van een dergelijke constructie. Kan jij bijvoorbeeld aan de logging van een card client zien of die uberhaupt wel EMM berichten verwerkt en zoja, of die afkomstig zijn van de card server of dat de card client die zelf uit de Transport Stream haalt en aanbied aan de card server? Of verwerkt de card client helemaal geen EMM berichten meer omdat dat de taak is van de card server om de smartcard up to date te houden en stuurt de card client alleen nog maar ECM berichten van het te bekijken kanaal naar de card server zodat die in combinatie met de smartcard de benodigde key uit die ECM berichten kan halen? Ik heb geen idee.

[Catastrofus]

Origineel bericht van: ArChie

Origineel bericht van: Catastrofus

Ok, resumerend, een EMM (subscriber info) heb je nodig om een ECM te decrypten. Een gedecrypte ECM bevat de key om een een kanaal te kunnen decrypten zodat je beeld hebt. Dit alles simpel gezegd. Korrekt?

Ja, op hoofdlijnen komt het daarop neer. Zo werkt het in principe voor ieder CAS. De manier waarop al die sleutels op smartcard, EMM en ECM toegepast worden verschilt per CAS, maar uiteindelijk levert het een sleutel op waarmee de data stream pakketten van het weer te geven kanaal gedecrypt kunnen worden.

Citaat:

Blijkbaar ging door de vloedgolf van emms CCcam, van de dm8000, over de rooie. Rest mij de vraag waarom mijn client (de dm7025) geen enkel probleem (haperingen e.d.) had. Hij kijkt wel naar de gegevens die de dm8000, die de ziggo kaart bevat, binnen krijgt.

Ik heb geen idee hoe dat card server / card client gebeuren werkt aangezien ik zelf nog nooit gebruik heb gemaakt van een dergelijke constructie. Kan jij bijvoorbeeld aan de logging van een card client zien of die uberhaupt wel EMM berichten verwerkt en zoja, of die afkomstig zijn van de card server of dat de card client die zelf uit de Transport Stream haalt en aanbied aan de card server? Of verwerkt de card client helemaal geen EMM berichten meer omdat dat de taak is van de card server om de smartcard up to date te houden en stuurt de card client alleen nog maar ECM berichten van het te bekijken kanaal naar de card server zodat die in combinatie met de smartcard de benodigde key uit die ECM berichten kan halen? Ik heb geen idee.

Ik ga de beschikbare logs even door worstelen, maar mijn gevoel zegt de laatste optie. To be continued.

Gert.

[Rigolo]

Archie,

 

De cardclient haalt de EMM berichten uit de datastroom en geeft deze door aan de cardserver (als de gebruiker daar rechten toe heeft, en als de cardclient is ingesteld om deze door te sturen)

 

De cardserver krijgt dus het complete EMM bericht en stuurt deze naar de smartcard. Deze geeft antwoord (GOED/NIET GOED) en bij een GOED worden de entitlements bijgewerkt. Om nou te zorgen dat het zelfde bericht niet meerdere keren door verschillende clients door gestuurd worden en ook verwerkt houdt de server meestal een cache bij van de ontvangen EMM berichten. Komt er precies een zelfde EMM bericht dan wordt deze niet doorgestuurd naar de kaart maar wordt het oude antwoord terug gestuurd naar de client.

 

De client stuurt ook de ECM's door naar de cardserver als de client weet dat die cardserver ook dat type ECM's kan verwerken. De cardserver geeft dan ook bij de initele communicatie tussen de client en de server door voor welke CAID's en welke entitlements hij zaken kan verwerken. Het ECM bericht wordt naar de smartcard gestuurd, daar wordt een antwoord bepaald, en dit antwoord wordt terug gestuurd naar de client die op basis van dat antwoord de DVB datastroom kan ontsleutelen. Ook hier wordt er gebruik gemaakt van caching zodat niet elk ECM bericht dat binnen komt naar de smartcard gestuurd wordt maar dat dit maar 1 keer gebeurt. Stel dat je dus 3 clients actief hebt die alle 3 het zelfde kijken dan ontvang je als cardserver dus ook 3 keer het zelfde ECM bericht. 1 wordt naar de smartcard gestuurd, de rest vanuit de cache beantwoord.

 

Wat je nu zag gebeuren tijdens deze EMM flood was de (in mijn geval) NewCS keurig de EMM bleef aanbieden aan de smartcard maar dat deze voor 99.9% van de gevallen een NIET GOED terug gaf. Omdat de smartcard zo druk bezig was met het verwerken van al die EMM berichten was er bijna geen tijd meer om de ECM berichten ook nog eens goed te verwerken. Als deze dan achter gaan lopen gooit de client denk ik de data packetten die het niet kan decoderen omdat het geen Key ontvangt weg. Hierdoor ontstaat dus hikken en haperen. Daarnaast zit er in NewCS blijkbaar een memory leak omdat het geheugen van mijn NSLU2 snel volliep waardoor NewCS ook nog eens ophielt met werken. Maar een dagenlijks restart van NewCS lost dat ook weer op.

 

Ik hoop dat ik het goed en helder uitleg. Als er iemand anders is die mijn fouten kan corrigeren is dat natuurlijk altijd fijn om te horen

 

Hein

[Catastrofus]

Origineel bericht van: Rigolo

Archie,

De cardclient haalt de EMM berichten uit de datastroom en geeft deze door aan de cardserver (als de gebruiker daar rechten toe heeft, en als de cardclient is ingesteld om deze door te sturen)

De cardserver krijgt dus het complete EMM bericht en stuurt deze naar de smartcard. Deze geeft antwoord (GOED/NIET GOED) en bij een GOED worden de entitlements bijgewerkt. Om nou te zorgen dat het zelfde bericht niet meerdere keren door verschillende clients door gestuurd worden en ook verwerkt houdt de server meestal een cache bij van de ontvangen EMM berichten. Komt er precies een zelfde EMM bericht dan wordt deze niet doorgestuurd naar de kaart maar wordt het oude antwoord terug gestuurd naar de client.

De client stuurt ook de ECM's door naar de cardserver als de client weet dat die cardserver ook dat type ECM's kan verwerken. De cardserver geeft dan ook bij de initele communicatie tussen de client en de server door voor welke CAID's en welke entitlements hij zaken kan verwerken. Het ECM bericht wordt naar de smartcard gestuurd, daar wordt een antwoord bepaald, en dit antwoord wordt terug gestuurd naar de client die op basis van dat antwoord de DVB datastroom kan ontsleutelen. Ook hier wordt er gebruik gemaakt van caching zodat niet elk ECM bericht dat binnen komt naar de smartcard gestuurd wordt maar dat dit maar 1 keer gebeurt. Stel dat je dus 3 clients actief hebt die alle 3 het zelfde kijken dan ontvang je als cardserver dus ook 3 keer het zelfde ECM bericht. 1 wordt naar de smartcard gestuurd, de rest vanuit de cache beantwoord.

Wat je nu zag gebeuren tijdens deze EMM flood was de (in mijn geval) NewCS keurig de EMM bleef aanbieden aan de smartcard maar dat deze voor 99.9% van de gevallen een NIET GOED terug gaf. Omdat de smartcard zo druk bezig was met het verwerken van al die EMM berichten was er bijna geen tijd meer om de ECM berichten ook nog eens goed te verwerken. Als deze dan achter gaan lopen gooit de client denk ik de data packetten die het niet kan decoderen omdat het geen Key ontvangt weg. Hierdoor ontstaat dus hikken en haperen. Daarnaast zit er in NewCS blijkbaar een memory leak omdat het geheugen van mijn NSLU2 snel volliep waardoor NewCS ook nog eens ophielt met werken. Maar een dagenlijks restart van NewCS lost dat ook weer op.

Ik hoop dat ik het goed en helder uitleg. Als er iemand anders is die mijn fouten kan corrigeren is dat natuurlijk altijd fijn om te horen

Hein

Ik vind het, in ieder geval, een duidelijk en informatief antwoord.

Gert.

[ArChie]

Origineel bericht van: Rigolo

Ik hoop dat ik het goed en helder uitleg.

Bedankt voor deze toelichting. Weer wat geleerd.

[Catastrofus]

Origineel bericht van: Rigolo

Archie,

De cardclient haalt de EMM berichten uit de datastroom en geeft deze door aan de cardserver (als de gebruiker daar rechten toe heeft, en als de cardclient is ingesteld om deze door te sturen)

De cardserver krijgt dus het complete EMM bericht en stuurt deze naar de smartcard. Deze geeft antwoord (GOED/NIET GOED) en bij een GOED worden de entitlements bijgewerkt. Om nou te zorgen dat het zelfde bericht niet meerdere keren door verschillende clients door gestuurd worden en ook verwerkt houdt de server meestal een cache bij van de ontvangen EMM berichten. Komt er precies een zelfde EMM bericht dan wordt deze niet doorgestuurd naar de kaart maar wordt het oude antwoord terug gestuurd naar de client.

De client stuurt ook de ECM's door naar de cardserver als de client weet dat die cardserver ook dat type ECM's kan verwerken. De cardserver geeft dan ook bij de initele communicatie tussen de client en de server door voor welke CAID's en welke entitlements hij zaken kan verwerken. Het ECM bericht wordt naar de smartcard gestuurd, daar wordt een antwoord bepaald, en dit antwoord wordt terug gestuurd naar de client die op basis van dat antwoord de DVB datastroom kan ontsleutelen. Ook hier wordt er gebruik gemaakt van caching zodat niet elk ECM bericht dat binnen komt naar de smartcard gestuurd wordt maar dat dit maar 1 keer gebeurt. Stel dat je dus 3 clients actief hebt die alle 3 het zelfde kijken dan ontvang je als cardserver dus ook 3 keer het zelfde ECM bericht. 1 wordt naar de smartcard gestuurd, de rest vanuit de cache beantwoord.

Wat je nu zag gebeuren tijdens deze EMM flood was de (in mijn geval) NewCS keurig de EMM bleef aanbieden aan de smartcard maar dat deze voor 99.9% van de gevallen een NIET GOED terug gaf. Omdat de smartcard zo druk bezig was met het verwerken van al die EMM berichten was er bijna geen tijd meer om de ECM berichten ook nog eens goed te verwerken. Als deze dan achter gaan lopen gooit de client denk ik de data packetten die het niet kan decoderen omdat het geen Key ontvangt weg. Hierdoor ontstaat dus hikken en haperen. Daarnaast zit er in NewCS blijkbaar een memory leak omdat het geheugen van mijn NSLU2 snel volliep waardoor NewCS ook nog eens ophielt met werken. Maar een dagenlijks restart van NewCS lost dat ook weer op.

Ik hoop dat ik het goed en helder uitleg. Als er iemand anders is die mijn fouten kan corrigeren is dat natuurlijk altijd fijn om te horen

Hein

Ik zat hier even over na te denken maar ik gebruik geen NewCS icm CCcam maar, enkel CCcam, maar bij mij haperde het beeld/opnames ook. NewCS is niet hetzelfde als CCcam toch? Nee, volgens mij niet en bij mij hielp een restart van CCcam maar voor even net zoals het schakelen naar een niet gecodeerd kanaal zoals ned 1.

Gert.

[Rigolo]

Origineel bericht van: Catastrofus

.... ik gebruik geen NewCS icm CCcam maar, enkel CCcam

CCcam is een cardserver en cardclient in 1 programma. NewCS is alleen maar de server en heeft dus een client nodig (newcamd, CCcam, sasc-ng etc)

Hein