Hej,
nu tycker jag att det är dags att reda ut varför kortet med gul pil bara fungerar ihop med mgcamd1.30d. Det är ju ett jävla tjatande om det utan att någon kan förklara varför.
Så det vore kanon om någon som har ett gult kort kunde göra lite loggar med mgcamd1.30d och sedan en logg med 1.31x. Så kan jag återkomma med en förklaring! Tyvärr har jag själv bara ett kort med blå pil, annars hade det varit förklarat sedan länge.
Vilken typ av loggar vill du ha då?
Behövs väl nått mer än mgcamds egna eller..?
Det största felet många datoranvändare gör, är att de inte vet vad de gör, men de gör det ändå !
Det jag har sett när jag jämfört loggar är att cw:s ändras från NewCS till 1.30c-1.31.
Med 1.31 stämmer cw 1 helt, cw 2 första tre paren. cw 1 första tre paren, cw 2 helt. cw 1 helt cw 2 första tre paren och så vidare.
Med 1.30d stämmer cw 1 helt, cw 2 inga alls. cw 1 inga alls cw 2 helt. cw1 helt, cw 2 inga alls och så vidare.
Ecm.info har jag tagit ut med ett "bonnascript" så tidsaxeln stämmer inte helt med NewCS log.
Vill du ha några andra loggar så säg bara till vilka du vill ha.
För övrigt verkar Oscam fungera med valfri Mgcamd.
var hittar ni dom där pilarna på korten?
Längst fram som visar vilket håll man ska stoppa in kortet i läsaren.
Finns ingen på gamla kort.
Att det är ett annat ca-id innebär ju (för klienten iaf) att det är ett helt separat ca-system, med en annan uppsättning ecms i streamen på ett eget ca-pid vid sidan om det gamla. Att samma implementationer sen verkar fungera på serversidan indikerar ju att det i grunden är samma system, men med någon enklare extra obfuskering som gör det inkompatibelt med äldre versioner (avsiktligt).
Utan att ha tittat närmare på loggarna så finns det väl följande alternativ:
- Dummy cws, vissa svar från korten är decoys (klienten behöver kunna känna igen och ignorera dessa).
- Omkastad ordning (alla cws är äkta men klienten ska inte använda dom i den ordning dom kommer från korten).
- Post-processing av cws på klientsidan.
- Kombinationer av ovanstående.
Tack för loggarna, något förvirrande namngivning men jag tror jag förstod vilket som var vad. Loggarna gav lite info om symptomen men ingen info om varför. För att förstå varför krävs loggning av själva ecm:n, inte bara svaren (CW). Lite mer detaljerad loggning ifrån 1.30c/d och 1.31 krävs för detta. Bäst vore ju om man kunde får loggning ifrån två boxar sammtidigt, alternativt att man gör ett skript som startar mgcamd_x, väntar 3 sek, dödar mgcamd_x och sedan startar mgcamd_y för att hinna snappa upp samma ecm men det känns som överkurs.Ursprungligen postat av ab12cd34
Men att oscam fungerar tyder ju på att newcs är problemet, inte mgcamd!
Du kan plocka ecms ur båda ca-pidsen (090f och 093e) direkt ur streamen med dvbsnoop, och sen peta in dom i newcs via webif.
Kör dvbsnoop på PAT (pid 0x00), välj ut en service (sid benämns Program_number) och kika sen på dess PMT pid.
Där ser man vilka CA pids som är associerade med just den kanalen.
För att sen kolla på själva datan just nu i respektive pid kan man köra med: -n 1 -npd -ph 2 pid
Där pid är önskat CA pid.
Om newcs stöd för 093e varit perfekt (och den kompenserat för den extra obfuskeringen direkt på serversidan) så skulle ju resulterande cw bli detsamma med ecms från båda versionerna.
Om du tar aktuell ecm ur båda ca-pidsen ungefär samtidigt (just efter ett byte så man hinner) och provar båda manuellt mot newcs så bör det framgå vad exakt som brister... om man har access till en med respektive kort-typ dvs.
Oscam har säkert nån motsvarande test-feature för att manuellt mata in en ecm (om inte kan man ju ordna en iom fri source).
Oki tack för svaret, för jag har ingen pil på mitt iaf
Så med oscam behöver man inte mgcamd 1.30a-d utan där fungerar alla cams?
Rust Never Sleeps
Behörigheter för att posta
Svara med citat