Przegląd rozwiązywania problemów z CCcam: Napraw zawieszanie się obrazu& Błędy FBL

Jeśli korzystasz z konfiguracji CCcam lub OScam, a obraz ciągle się zacina, ten przegląd rozwiązywania problemów z cccam pozwoli ci zaoszczędzić mnóstwo czasu. Zawieszanie się obrazu to nie jeden problem — to objaw mający około pięciu różnych przyczyn źródłowych, a większość ludzi spędza godziny na restartowaniu dekodera zamiast przeczytać tę jedną linijkę logu, która od razu powiedziałaby im, co dokładnie jest nie tak. Od lat prowadzę serwery share z przerwami i poniższy proces diagnostyczny to dokładnie ten, którego używam za każdym razem, gdy linia przestaje działać.

Zanim więc dotkniesz CCcam.cfg lub oscam.server, ustalmy, co tak naprawdę mówi ci log. To część, którą pomija każdy inny przegląd rozwiązywania problemów z cccam.

Jak odczytać zawieszenie obrazu w CCcam, zanim tkniesz konfigurację

Zawieszanie się obrazu to nie diagnoza. To objaw. Dekoder się zawiesił, ponieważ coś w łańcuchu ECM trwało zbyt długo albo całkowicie zawiodło — ale samo „zawieszanie się” niczego ci nie mówi o tym, czy usterka leży w twojej konfiguracji, sieci, karcie twojego peera, czy w martwej linii. Najpierw musisz zajrzeć do logu.

Zawieszenie a czarny ekran a poszarpany obraz — trzy różne usterki

Te zjawiska są nagminnie wrzucane do jednego worka, a nie powinny być. Zawieszenie oznacza, że ECM (Entitlement Control Message) zostało zażądane i ostatecznie dotarło, ale za późno — dekoder wyczerpał ważne słowo kontrolne, zanim pojawiło się nowe, więc zatrzymuje ostatnią klatkę. Czarny ekran zwykle oznacza, że w ogóle nie wróciła żadna odpowiedź ECM albo że żądany CAID nie jest obsługiwany przez nic z twojej listy kart. Poszarpany obraz — widoczne zakłócenia, a nie zamrożona klatka — zwykle oznacza, że dostałeś z powrotem DCW (słowo kontrolne), ale niewłaściwe, co wskazuje na niezgodność CAID/dostawcy albo uszkodzony klucz.

Pomyl te rzeczy, a spędzisz weekend na dostrajaniu limitów przeskoków, podczas gdy prawdziwym problemem jest twój kabel LNB.

Włączanie szczegółowego logowania: debug 4 i ścieżka do logu CCcam

Twoja konfiguracja CCcam znajduje się w/etc/CCcam.cfg (lub/usr/keys/CCcam.cfg w niektórych obrazach enigma2). Aby uzyskać przydatny wynik diagnostyczny, ustaw:

DEBUG : 4

Poziom debugowania 4 daje ci pełne logowanie żądań/odpowiedzi ECM, a nie tylko zdarzenia połączenia. Bez tego zobaczysz komunikaty o połączeniu/rozłączeniu peera, ale nic o faktycznym dostarczaniu kluczy — co jest bezużyteczne przy diagnozowaniu zawieszania się obrazu.

W OScam odpowiednik znajduje się w/etc/oscam/oscam.conf w sekcji[global]:

logfile = /var/log/oscam.log

Jeśli korzystasz z webif (zwykle na porcie 8888 albo takim, jaki ustawiłeś w sekcji[webif]), strona statusu readera daje ci te same dane o czasach ECM w znacznie czytelniejszej tabeli — teraz sprawdzam to, zanim w ogóle zajrzę do surowego pliku logu.

Odczytywanie czasów odpowiedzi ECM w logu (jak wygląda „dobrze”)

Zdrowa linia logu CCcam wygląda mniej więcej tak:

[03:14:22] ECM (0100:000000) from (CCcam) client PeerName, cw: 142 ms

Te 142 ms to czas odpowiedzi ECM — odstęp między wysłaniem żądania a otrzymaniem control worda. Wszystko poniżej mniej więcej 250-300 ms jest komfortowe. Między 300-800 ms zaczniesz od czasu do czasu widzieć drobne zacinanie się na kanałach z krótkimi crypto-periodami. Powyżej 800 ms, konsekwentnie, zobaczysz widoczne zamrażanie obrazu — dekoder po prostu wyczerpuje ważny klucz, zanim dotrze kolejny. Jeśli crypto-period kanału wynosi 8-10 sekund, a twój czas ECM zbliża się do tej wartości, dostajesz twarde zamrożenie w każdym cyklu, jak w zegarku.

To najbardziej przydatna umiejętność w każdym przeglądzie rozwiązywania problemów z cccam: skoreluj znacznik czasu zamrożenia na twoim telewizorze z linią ECM z tej samej sekundy w logu. Dziewięć razy na dziesięć wartość ms mówi ci wszystko.

Mapowanie zamrożenia na CAID/ID dostawcy

Każda linia ECM zawiera parę CAID:providerID — w powyższym przykładzie0100:000000. Zapisuj, które kombinacje CAID/dostawca się zamrażają, a które nie. Jeśli to zawsze ten sam CAID (powiedzmy 0100 dla Cryptoworks lub 0500 dla Viaccess), oznacza to, że problem dotyczy konkretnie peera lub lokalnej karty obsługującej ten CAID — nie całej twojej konfiguracji. To różnica między „moja linia nie działa" a „jedna konkretna karta za moją linią jest przeciążona", i to zmienia to, co naprawiasz.

Najczęstsze przyczyny źródłowe (uszeregowane według częstotliwości występowania)

W kolejności tego, jak często faktycznie widzę je w praktyce, oto co psuje twój sygnał.

Martwe lub dławione C-linie i jak powstaje FBL (Freeze Box Loop)

To przyczyna numer jeden, z dużą przewagą. C-linia w twoim CCcam.cfg:

C: 185.xx.xx.xx 12000 myuser mypass

...może być „aktywna" na poziomie TCP (gniazdo łączy się bez problemu), podczas gdy karta za nią jest całkowicie przeciążona lub peer ograniczył (dławi) twoje konto. Twój box żąda ECM, nie otrzymuje ważnego DCW na czas, żąda ponownie, nadal go nie dostaje, i żąda ponownie. To jest FBL — Freeze Box Loop — i z zewnątrz wygląda identycznie jak martwa linia, tyle że połączenie tak naprawdę nigdy nie zrywa się. Sprawdź log: jeśli widzisz powtarzające się żądania ECM dla tego samego CAID bez odpowiadającej im linii odpowiedzi „cw:", albo czasy odpowiedzi, które po prostu wciąż rosną, karta tego peera jest albo martwa, albo przeciążona, albo po cichu przestała obsługiwać ten ID dostawcy.

Limity hopów i reshare po cichu zabijające widoczność twojej karty

CCcam.cfg pozwala ograniczyć, przez ile hopów karta może być reshare'owana:

F: friendname 12000 user pass 1 0 { 1,2,3 }

Liczby w nawiasach klamrowych to limity hopów reshare dla CAID. Karta na hopie 0 jest lokalna — jest fizycznie w twoim boxie. Hop 1 oznacza jednego peera dalej. Przy hopie 3 lub większym, ten klucz został przekazany przez trzy oddzielne serwery, zanim do ciebie dotarł, a każdy hop dodaje opóźnienie i nowy punkt awarii. Widziałem karty na hopie 4, które technicznie „działały", ale z czasami ECM przekraczającymi 1200 ms — całkowicie bezużyteczne przy czymkolwiek z szybkim crypto-periodem.

Niedopasowanie CAID/dostawcy i brakujący ecm.info

Czasami czytnik myśli, że obsługuje CAID 0500, ale rzeczywisty ID dostawcy pod spodem się zmienił, albo twój plik CCcam.providers wymienia ident, który już nie pasuje do tego, co zwraca karta. W OScam sprawdźecm.info w katalogu logów — zapisuje on każde żądanie ECM z CAID, ID dostawcy i informacją, czy przyszła ważna odpowiedź. Jeśli widzisz stałe „not found" przy CAID, który myślałeś, że jest obsługiwany, twój plik dostawców jest nieaktualny.

Jitter sieciowy, MTU i pułapka timeoutu NAT na routerze

CCcam domyślnie używa portu TCP 12000. OScam zwykle uruchamia własny protokół w zakresie mniej więcej 8888 dla webif, przy czym newcamd typowo działa na portach 988x, jeśli mostkujesz protokoły. Jeśli tabela NAT twojego routera przetrzymuje bezczynne połączenie TCP tylko przez pewien czas (typowy domyślny czas to gdzieś w okolicach 300-600 sekund na routerach konsumenckich), a CCcam nie wysyła keep-alive wystarczająco często, linia zrywa się po cichu — twój box myśli, że nadal jest połączony, router nie, a ECM-y idą w próżnię, dopóki nie nastąpi ponowne połączenie. Konkretnie na liniach PPPoE/ADSL niedopasowania MTU (narzut PPPoE zjada 8 bajtów, więc często potrzebujesz 1492 zamiast 1500) mogą fragmentować pakiety i sporadycznie uszkadzać dane ECM — to objawia się sporadycznym zamrażaniem, które w ogóle nie ma nic wspólnego z twoim dostawcą.

Przeciążona karta: głębokość kolejki ECM i przypisywanie 'sid'

Jeśli udostępniasz własną kartę wielu użytkownikom niższego szczebla, fizyczna karta może dekodować tylko ograniczoną liczbę równoczesnych żądań ECM, zanim kolejka się zapcha. Obserwuj, ile aktywnych SID-ów (identyfikatorów usług/strumieni) trafia do pojedynczego czytnika w twoim logu lub na stronie statusu webif. Pojedyncza przeciążona karta obsługująca 15 równoczesnych kanałów dla różnych użytkowników pokaże rosnące czasy ECM u wszystkich — to często stoi za zamrażaniem, które zdarza się tylko o określonych porach dnia, jak w godzinach największej oglądalności wieczorem, gdy wszyscy oglądają jednocześnie.

Naprawianie tego: zmiany w konfiguracji, które faktycznie zatrzymują zamrażanie

Kiedy już wiesz, co pokazuje log, oto co naprawdę robi różnicę.

Dostrajanie CCcam.cfg: CACHE EX, GHOST CARDS OFF i zalecane timeouty

Kilka dyrektyw w CCcam.cfg naprawdę pomaga:

CACHE EX : 1

CACHE EX włącza buforowanie ECM, dzięki czemu powtarzające się żądania tego samego klucza w krótkim oknie czasowym nie obciążają ponownie peera.GHOST CARDS OFF powstrzymuje CCcam przed reklamowaniem kart, które widzi jako reshare'owane przez peera, ale które w rzeczywistości nie są wiarygodne — karty widma (ghost cards) to jeden z głównych powodów FBL, bo twój box myśli, że ma szybką ścieżkę do CAID, który w rzeczywistości jest trzy skoki dalej i wolny.MINIMUM CW : 1 po prostu wymusza, żeby control word nie był pusty, zanim zostanie zaakceptowany, odfiltrowując śmieciowe odpowiedzi od niestabilnego peera.

Odpowiedniki w OScam: istotne ustawienia [cache] i dvbapi

Prawdziwa przewaga OScam tkwi tutaj w loadbalancerze. W oscam.conf:

[global]

lb_mode = 1 to tryb "najszybszy reader" — OScam aktywnie śledzi czasy odpowiedzi dla każdego CAID/providera na wszystkich twoich readerach i kieruje żądania do tego, który jest teraz najszybszy, zamiast ślepo walić w tego, który jest wymieniony jako pierwszy.lb_retrylimit (w ms) mówi mu, żeby zrezygnował z wolnego readera i przełączył się na kolejny najlepszy, zamiast tam siedzieć i czekać. To jedno ustawienie naprawia więcej zamrożeń niż jakakolwiek modyfikacja CCcam.cfg, jaką kiedykolwiek zrobiłem, bo CCcam nie ma odpowiednika — po prostu dalej pyta tego samego peera, niezależnie od tego, jak wolny był historycznie.

Ograniczanie złego peera zamiast jego usuwania

Jeśli peer serwuje CAID, którego nikt inny nie ma, ale jest wolny, nie usuwaj go od razu — ogranicz swoje poleganie na nim. W OScam obniż jego priorytet w[reader] za pomocąlb_weight parametru, żeby loadbalancer sięgał po niego dopiero wtedy, gdy nic szybszego nie jest dostępne, zamiast traktować go jako równorzędną opcję.

Migracja zamrażającej się linii z protokołu CCcam do OScam

To najczystszy sposób, żeby ustalić, czy problem leży w protokole, czy w samym peerze. Dodaj readera typu cccam w oscam.server, wskazującego dokładnie na tego samego hosta i te same dane logowania:

[reader]

Jeśli ta sama fizyczna linia zachowuje się teraz lepiej pod loadbalancerem OScam niż pod surowym CCcam, problemem nigdy nie był peer — to CCcam ponawiał połączenie do złego readera bez żadnej logiki backoff. To naprawdę przydatna wskazówka w każdym przeglądzie rozwiązywania problemów z cccam, bo mówi ci, czy naprawić swój stos protokołów, czy poszukać zupełnie innego źródła kart.

Weryfikacja poprawki kontrolowanym testem zmiany kanałów

Nie ufaj wrażeniu "wydaje się lepsze". Wybierz dwa kanały znane z dużego ruchu ECM (krótki crypto-period, duża oglądalność) i przełączaj się między nimi 20 razy pod rząd, obserwując log lub kolumnę czasu ECM w webif. Przed poprawką zanotuj średni czas w ms i liczbę zamrożeń. Po poprawce powtórz dokładnie ten sam test. Jeśli średni czas ECM spadł, a liczba zamrożeń wyniosła zero przy 20 przełączeniach, poprawka zadziałała. Jeśli nadal przekracza 800 ms na którymkolwiek kanale, jeszcze tego nie rozwiązałeś — wróć do logu.

Jak ocenić, czy linia lub provider są warte utrzymania

Częścią każdego prawdziwego przeglądu rozwiązywania problemów z cccam jest decyzja, czy dalej walczyć ze złą linią, czy ją odciąć. Oto jak ocenić to obiektywnie, zamiast na wyczucie.

Obiektywne metryki: uptime %, średni czas ECM, częstotliwość zamrożeń

Ustal poprzeczkę i trzymaj przy niej każdą linię. Utrzymujący się czas odpowiedzi ECM powinien wynosić średnio poniżej mniej więcej 400 ms dla CAID-ów, które faktycznie oglądasz. Uptime — czyli to, że połączenie pozostaje nawiązane i faktycznie serwuje ważne DCW, a nie tylko jest połączone przez TCP — powinien wynosić powyżej 99% mierzonych przez tydzień, a nie w ciągu jednego dobrego wieczoru. Zdarzenia zamrożenia na najbardziej obciążonych kanałach powinny występować co najwyżej kilka razy dziennie, a nie co godzinę. Jeśli linia nie jest w stanie osiągnąć tych wartości w dłuższym okresie testowym, to już nie jest problem konfiguracji — to jest problem samej linii.

Zielone flagi w konfiguracji peer (lokalne karty, niski hop, stabilne IP)

Godna zaufania konfiguracja pokazuje karty na hopie 0 lub 1 — czyli faktycznie lokalne lub oddalone o jeden hop, a nie odsprzedane przez cztery warstwy reshare. Adres IP endpointu jest stabilny przez tygodnie, a nie rotuje. Obsługiwane CAID są udokumentowane i zgadzają się z tym, co faktycznie pojawia się w Twoim logu ecm.info. To techniczne odciski palca kogoś, kto prowadzi prawdziwą, dobrze utrzymaną konfigurację kart, a nie farmę reshare.

Czerwone flagi przewidujące przyszłe zamrażanie obrazu

Uważaj na adresy IP zmieniające się co kilka dni bez ostrzeżenia, listy kart wyglądające na nieprawdopodobnie duże jak na to, co powinno być małą prywatną lub małą firmową konfiguracją, oraz wartości hop, które się nie zgadzają — karta deklarująca hop 1, która zachowuje się tak, jakby była cztery hopy głębiej w timingu Twojego ECM. Każdy z tych sygnałów przewiduje zamrażanie, zanim jeszcze się zacznie, ponieważ wszystkie wskazują na niestabilność wyżej w łańcuchu, nad którą nie masz wglądu ani kontroli.

Jak technicznie wygląda legalna relacja z dostawcą

Żeby było jasne, chodzi tu o testowanie własnych kart abonamentowych i legalną interoperacyjność między własnym sprzętem — udostępnianie między kartą, którą posiadasz, a drugim boksem we własnym domu, lub weryfikację relacji biznesowej z udokumentowanym, licencjonowanym dostępem do kart. Legalna techniczna relacja daje Ci pojedynczy stabilny endpoint, udokumentowaną listę CAID/dostawców, którą możesz zweryfikować względem własnego wyjścia ecm.info, oraz uczciwe raportowanie hopów, które możesz niezależnie potwierdzić we własnych logach. Jeśli czegokolwiek z tego nie da się zweryfikować z Twojej strony, to jest prawdziwa czerwona flaga — nie samo zamrażanie.

Co nie działa (przestań na to marnować czas)

To rzeczy, które ludzie próbują najpierw i prawie nigdy niczego nie naprawiają, ponieważ nie odnoszą się do tego, co faktycznie pokazuje log.

Restartowanie boksa w pętli zamiast czytania logu

Reboot czyści aktywne połączenia i resetuje timery, więc czasem przez dziesięć minut wygląda lepiej. To nie jest naprawa — to zbieg okoliczności związany z timingiem. Leżące u podstaw opóźnienie ECM lub martwy peer nadal tam są; po prostu tymczasowo zresetowałeś cykl FBL. Jeśli zrobisz reboot i nie sprawdzisz logu, wrócisz tu za godzinę z dokładnie tym samym problemem i zero dodatkowych informacji względem punktu wyjścia.

Bezmyślne podnoszenie limitów hop/reshare

Podniesienie limitu hop z 2 do 4 sprawia, że widocznych jest więcej kart, jasne — ale każda z tych nowo widocznych kart jest z definicji dalej i wolniejsza. To odwrotność naprawy. Zamienia "brak dostępnej karty" na "dostępna wolna karta", a wolne karty to dokładnie to, co powoduje zamrażanie, które próbujesz rozwiązać. Jeśli gonisz za limitami hop, sprawdź najpierw wartość ms ECM — karta hop-1 przy 900 ms jest gorsza niż karta hop-2 przy 200 ms.

Skopiowane z forów "poprawki" CCcam.cfg

Cudzy zrzut konfiguracji zawiera jego C-linie, jego CAID, jego ustawienia hop dopasowane do jego relacji peer — nic z tego nie pasuje do Twojej konfiguracji. Wklejenie czyjegoś CCcam.cfg na swój po prostu zastępuje działające linie martwymi i niepotrzebnymi CAID, nie robiąc nic z faktycznym problemem peer lub sieci powodującym Twoje zamrażanie.

Obwinianie czaszy/konwertera LNB, gdy log pokazuje opóźnienie ECM

To pojedyncza, najczęstsza błędna diagnoza, jaką widzę. Zamrażanie podczas złej pogody, lub zamrażanie, które wydaje się podążać za deszczem, rzeczywiście może być problemem sygnału — prawdziwym spadkiem SNR z czaszy lub LNB. Ale to objawia się jako zaszumiony lub całkowicie utracony obraz ze spadającymi odczytami siły/jakości sygnału w statusie tunera, a nie czyste cykle zamrożenia i wznowienia przy normalnym poziomie sygnału. Jeśli Twój log pokazuje żądania ECM wychodzące i wracające z opóźnieniem — wyraźną wartość ms rosnącą powyżej 800 — Twoja czasza jest w porządku. Nie przestawiaj LNB z powodu problemu z timingiem card-sharingu.