Serwer CCcam Channels: Konfiguracja, Setup & Rozwiązywanie Problemów

Jeśli patrzysz na czarny ekran lub zamrożony obraz po uruchomieniu CCcam, jesteś we właściwym miejscu. Zrozumienie, jak kanały serwera cccam faktycznie działają na poziomie protokołu — nie tylko "dodaj C-line i miej nadzieję" — to właśnie rozróżnia niezawodny setup od frustrującego. Ten poradnik zakłada, że masz zainstalowany CCcam, masz skonfigurowaną co najmniej jedną C-line lub kartę lokalną, a określone kanały albo brakuje, albo się zawieszają, albo odbijają się od deszyfrowania.

Jak CCcam Mapuje Karty na Kanały

Oto coś, czego większość przewodników całkowicie pomija: CCcam nie ma pojęcia "kanałów" w taki sposób, w jaki robi to Twój EPG. Nie przechowuje listy "Sky Sports HD, BBC One, Eurosport." To, co przechowuje, to zestaw numerycznych krotek — CAID, ID dostawcy i SID — i dopasowuje żądania ECM do tych krotek. Jeśli krotka pasuje i karta potrafi deszyfrować, otrzymujesz słowo kontrolne. Jeśli nie, czarny ekran.

Co oznacza „Kanał" na Poziomie Protokołu

Na poziomie DVB każdy zaszyfrowany kanał transmituje pakiet ECM (Entitlement Control Message) obok strumienia wideo. Ten ECM zawiera CAID identyfikujący, który system CA go zaszyfrował. Twój odbiornik wysyła ten ECM do CCcam, który kieruje go na kartę, która rozpoznaje CAID. Karta go deszyfruje i zwraca słowo kontrolne. To słowo kontrolne dekoderuje wideo.

Tak więc „kanał nie działa" prawie zawsze oznacza, że routing ECM gdzieś się nie powiódł — albo CAID nie został dopasowany, albo karta nie miała uprawnień, albo odpowiedź trwała zbyt długo. To jest model mentalny, który musisz mieć.

CAID, ID Dostawcy i SID: Trzy Identyfikatory, Które Mają Znaczenie

Te trzy liczby całkowicie definiują dostęp do kanałów w CCcam:

• CAID — Conditional Access ID. Identyfikuje dostawcę CA. Na przykład 0x0500 to Viaccess, 0x0600 to Irdeto, 0x1800 to Nagravision. To jest pierwszy filtr w łańcuchu routingu.
• ID Dostawcy — Podprzestrzeń w systemie CA. Pojedyncza karta z CAID 0x0500 może posiadać ID dostawcy 032830, 042800 i 040810 — każdy reprezentujący innego operatora lub bukiet.
• SID — Service ID. Rzeczywisty identyfikator kanału w transpondzie. To jest to, co mapuje na "ten konkretny kanał" na liście kanałów Twojego odbiornika.

CCcam kieruje żądanie ECM poprzez dopasowanie najpierw CAID, potem ID dostawcy, a następnie próbę deszyfrowania. SID nie jest używany do routingu — to poziom subskrypcji karty, który określa, czy słowo kontrolne wraca prawidłowe dla danego SID.

Jak CCcam Buduje Wewnętrzną Listę Kanałów z Podłączonych Kart

Gdy CCcam się uruchamia i karta jest włożona (lub C-line się łączy), CCcam odczytuje ATR karty i wykonuje początkową kontrolę uprawnień. Buduje wewnętrzną tabelę, do których CAID i ID dostawcy karta odpowiada. Ta tabela jest tym, co widzisz w t

Co ważne, CCcam nie wylicza z góry każdego SID-a, który może odszyfrować karta. Odkrywa to dynamicznie tylko wtedy, gdy nadejdzie żądanie ECM. Dlatego web UI pokazuje CAIDy i dostawców — nie wstępnie utworzoną listę kanałów. Nie będziesz wiedzieć, że konkretny SID jest uszkodzony, dopóki nie spróbujesz go wybrać.

Różnica między poziomem pakietu karty a dostępem do surowych CAID-ów

To łapie wielu ludzi. Karta może prezentować CAID 0x0919 (Nagravision) i mieć widoczny identyfikator dostawcy 000000 — ale mieć tylko podstawową subskrypcję. Kanały premium na tym samym CAID-zie i dostawcy zwrócą nieprawidłowe słowo kontrolne lub w ogóle nie odpowiedzą, ponieważ karta po prostu nie ma uprawnień.

CCcam nie może ci powiedzieć z wyprzedzeniem, które SID-y są w ramach subskrypcji karty. Spróbuje odszyfrowania i zaloguje błąd. To jedyny sposób, aby się dowiedzieć — spróbuj odszyfrowania i przeczytaj odpowiedź ECM w dzienniku.

Konfiguracja CCcam do udostępniania określonych kanałów

Główny plik konfiguracyjny znajduje się pod adresem /etc/CCcam.cfg na większości systemów Linux i odbiorników Enigma2. Wszystko, co kontroluje, które kanały są udostępniane, filtrowane lub blokowane, znajduje się tutaj. Przejdziemy przez dyrektywy, które naprawdę mają znaczenie.

Składnia CCcam.cfg do filtrowania kanałów i CAID-ów

Podstawowa struktura używa dyrektyw wielkimi literami, po których następuje dwukropek i wartość. Odstępy są elastyczne. Komentarze używają #. Oto minimalny działający przykład obsługujący kontrolę na poziomie CAID:

# /etc/CCcam.cfg
PORT: 12000
NEWCAMD PORT: 15050 01020304050607080910111213141516
C: peer.example.com 12000 username password
IGNORE CAID: 0500
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0919 PROVID: 000001
SHARE LIMIT: 1
DEBUG: 1
HTTP PORT: 16001

Linia IGNORE CAID: 0500 mówi CCcam aby odrzucić wszelkie żądania ECM lub udostępnienia dotyczące Viaccess (0500). Linie PROVIDE CAID umieszczają na białej liście określone kombinacje CAID/dostawcy. Jeśli używasz obu, IGNORE ma pierwszeństwo dla swoich wymienionych CAID-ów.

Używanie dyrektyw IGNORE i PROVIDE do umieszczania na białej liście lub czarnej liście CAID-ów

Jeśli chcesz pozwolić na wszystko z wyjątkiem jednego systemu CA, użyj IGNORE. Jeśli chcesz ścisłego umieszczenia na białej liście, połącz IGNORE CAID: ALL z jawnymi liniami PROVIDE. Słowo kluczowe ALL jest rzeczywistą dyrektywą — instruuje CCcam, aby odrzucić wszystkie CAIDy nie jawnie udostępnione.

IGNORE CAID: ALL
PROVIDE CAID: 0919 PROVID: 000000
PROVIDE CAID: 0600 PROVID: 000000

To zabezpiecza twój serwer tylko do tych dwóch kombinacji CAID/dostawcy. Wszystko inne — w tym klient żądający kanałów Viaccess — zostaje silent upuszczone. Przydatne, gdy udostępniasz konkretną kartę i nie chcesz ujawniać niepowiązanych CAID-ów od upstream'owych peerów.

Ograniczenie udostępniania do określonych identyfikatorów dostawców

Filtrowanie identyfikatora dostawcy jest bardziej precyzyjne niż filtrowanie CAID. Możesz mieć kartę z CAID 0x0500 i trzema identyfikatorami dostawców — jeden dla e```html ach subscription package. If you only want to share one package, specify only that provider ID in the PROVIDE directive and IGNORE the rest:

IGNORE CAID: 0500
PROVIDE CAID: 0500 PROVID: 032830

To ujawnia tylko pakiet dostawcy 032830 w Viaccess, blokując inne identyfikatory dostawców z tej samej karty. Czyste i skuteczne dla współdzielenia częściowych subskrypcji.

Ustawianie SHARE LIMIT i Hop Count w celu kontrolowania propagacji kanałów

Dyrektywa SHARE LIMIT kontroluje, ile przeskoków w dół udostępnianie może podróżować. Ustawienie go na 0 oznacza, że tylko Twoja lokalna karta jest udostępniana — bez ponownego udostępniania kart, które otrzymałeś od upstream peers. Ustawienie na 1 oznacza, że udostępniasz lokalną kartę jeden skok w dół. Wyższe wartości pozwalają na więcej przeskoków.

SHARE LIMIT: 1

Dyrektywa RESHARE na poziomie użytkownika działa inaczej — kontroluje, czy konkretny połączony klient może dalej ponownie udostępniać to, co otrzymuje od Ciebie. Wartość 0 oznacza brak ponownego udostępniania; 1 oznacza, że mogą ponownie udostępniać jeden skok. To ma znaczenie, jeśli widzisz, że Twoje kanały serwera cccam pojawiają się na serwerach, których nie uprowadziłeś.

Wyjaśnienie plików CCcam.providers i CCcam.channelinfo

Te dwa pliki mylą ludzi, ponieważ wyglądają funkcjonalnie, ale nie są. Oba są tylko kosmetyczne.

/usr/share/CCcam/CCcam.providers mapuje identyfikatory dostawców na czytelne dla człowieka nazwy operatorów. To sprawia, że Twoje logi mówią „Viasat" zamiast „042800". To absolutnie nic nie wpływa na to, które kanały się odszyfrowują. Ta sama historia dla /usr/share/CCcam/CCcam.channelinfo — mapuje SID na nazwy kanałów dla czytelności dzienników. Przydatne do debugowania, nieistotne dla deszyfrowania.

Format channelinfo to jeden wpis na linię: SID w formacie szesnastkowym, a następnie nazwa kanału. Na przykład:

1234 BBC One HD
5678 Sky Sports 1

Umieść plik tam, gdzie CCcam.cfg się do niego odwołuje. Jeśli go brakuje, CCcam po prostu wraca do rejestrowania surowych wartości szesnastkowych.

Weryfikacja kanałów, które może odszyfrować Twój serwer

Nie powinieneś zgadywać, czy Twój serwer może odszyfrować kanał. CCcam daje Ci wbudowany interfejs HTTP i dane wyjściowe dziennika, które mówią Ci dokładnie, co się dzieje — jeśli wiesz, jak je czytać.

Czytanie interfejsu internetowego CCcam (port 16001) w celu inspekcji aktywnych identyfikatorów CAID

Domyślnie CCcam uwidacznia interfejs sieciowy na porcie 16001. Upewnij się, że Twój CCcam.cfg ma:

HTTP PORT: 16001

Następnie wejdź na http://<your-receiver-ip>:16001 w przeglądarce. Zobaczysz sekcje dotyczące połączonych kart, aktywnych klientów, udziałów i historii ECM. Sekcja kart jest punktem wyjścia — zawiera listę identyfikatora CAID każdej karty, identyfikatora dostawcy, liczby przeskoków i poziomu ponownego udostępniania.

Jedna ważna pułapka: jeśli uruchamiasz CCcam za NAT i przekazujesz port 12000 dla połączeń klientów, port 16001 jest oddzielny i potrzebuje własnej reguły przekazywania. Wiele osób przekazuje port klienta CCcam, ale zapomina ``````html port HTTP, a następnie zastanawiają się, dlaczego nie mogą widzieć interfejsu web z poza sieci LAN.

Interpretacja sekcji „Karty" i „Udziały" w interfejsie web

Sekcja kart pokazuje hop=0 dla fizycznych kart wstawionych lokalnie. Hop=1 oznacza, że karta znajduje się jedną linię C dalej, hop=2 oznacza dwa przeskoki i tak dalej. W miarę wzrostu liczby przeskoków zwiększa się opóźnienie, a niezawodność ma tendencję do zmniejszania się.

Sekcja udziałów pokazuje, którzy klienci poboczni są podłączeni i do czego mają dostęp. Jeśli klient jest podłączony, ale tabela udziałów nie pokazuje aktywności na konkretnym CAID, oznacza to, że albo go nie żądają, albo twoje filtry go odrzucają, zanim do nich dotrze.

Używanie danych wyjściowych dziennika CCcam do śledzenia nieudanego żądania ECM

Ustaw DEBUG: 1 w CCcam.cfg do podstawowego śledzenia ECM. Aby uzyskać bardziej szczegółowe dane wyjściowe, użyj DEBUG: 3, ale spodziewaj się dużych plików dziennika. Pomyślna odpowiedź ECM wygląda następująco:

ECM 0919/000000/1234 answered in 320ms by card 1

Niepowodzenie wygląda jak jeden z nich:

ECM 0919/000000/1234 - no card found
ECM 0919/000000/1234 - timeout after 3000ms
ECM 0919/000000/1234 - card returned error

"Nie znaleziono karty" oznacza, że żadna karta w twojej puli nie pasuje do tej kombinacji CAID/dostawca — sprawdź swoje filtry IGNORE/PROVIDE. "Timeout" oznacza, że znaleziono kartę, ale nie odpowiedziała w czasie — problem opóźnienia. "Karta zwróciła błąd" zwykle oznacza, że brakuje uprawnień subskrypcji dla tego SID.

Porównywanie SID względem bazy danych kanałów DVB

Jeśli nie jesteś pewien, jaki CAID i SID używa określony kanał, musisz spojrzeć na surowy PMT. Narzędzia dvbsnoop i tzap (część pakietu dvb-apps na Linuksie) pozwalają dostroić transponder i zrzucić informacje o usługach.

tzap -c /etc/channels.conf "BBC One HD"
dvbsnoop -s pmt 1234

Zrzut PMT pokaże wpisy deskryptora CA, w tym CAID i PID ECM. Porównaj te wartości z tym, co CCcam pokazuje w interfejsie web. Jeśli CAID w PMT nie znajduje się w twojej tabeli kart, to jest twój problem.

Testowanie deszyfrowania z jednym znanym kanałem przed skalowaniem

Przed dodaniem wielu linii C lub złożonych reguł filtrowania, przetestuj z jednym kanałem, który powinien działać. Wybierz kanał, którego CAID możesz zweryfikować z PMT, potwierdź, że ten CAID pojawia się w tabeli kart interfejsu web, i spróbuj go dostroić. Uzyskaj jeden kanał deszyfrujący czysty, a następnie rozwijaj. To izoluje problemy konfiguracji od problemów subskrypcji.

Powszechne przyczyny, dla których kanały znikają lub nie są deszyfrowane

To są błędy, które widzę najczęściej, w przybliżonym porządku częstotliwości ich występowania. Każdy z nich ma specyficzną ścieżkę diagnostyczną.

Karta nie ma pakietu subskrypcji dla tego kanału

CAID pasuje, ID dostawcy pasuje, ale kanał jest czarny. Dziennik mówi „karta zwróciła błąd". To problem poziomu subskrypcji — karta po prostu nie ma uprawnienia dla tego SID. Th ```Nie ma na to poprawki w konfiguracji. Albo subskrypcja nie obejmuje tego kanału, albo aktualizacje EMM wygasły (patrz poniżej).

Niezgodność CAID między żądaniem klienta a kartą serwera

Niektóre kanały nadają na wielu identyfikatorach CAID jednocześnie (tzw. overcrypt). Twój odbiornik może żądać kanału za pomocą CAID 0x0606, podczas gdy twoja karta obsługuje tylko CAID 0x0600. Dziennik pokaże "no card found" nawet jeśli teoretycznie masz kartę dla tego kanału. Rozwiązaniem jest sprawdzenie rzeczywistego PMT pod kątem wszystkich deskryptorów CA i weryfikacja, który CAID obsługuje twoja karta. W skonfigurowanych mostach OScam możesz ustawić priorytet CAID — w czystym CCcam może być konieczne wymuszenie na kliencie żądania określonego CAID.

Identyfikator dostawcy przefiltrowany w CCcam.cfg

Sprawdź reguły IGNORE/PROVIDE. Jeśli użyłeś IGNORE CAID: ALL i zapomniałeś dodać linię PROVIDE dla identyfikatora dostawcy, cały ten pakiet zostanie cicho usunięty. Dziennik nie pokaże żadnych prób ECM docierających do tego dostawcy. Porównaj identyfikator dostawcy z interfejsu sieciowego z liniami PROVIDE w konfiguracji.

Liczba przeskoków lub poziom ponownego udostępnienia ustawione zbyt nisko

Jeśli dodałeś linię C do peera, a karty tego peera pojawiają się w twoim interfejsie sieciowym przy hop=1, ale twoi pośredni klienci nie mogą do nich uzyskać dostępu, sprawdź swój SHARE LIMIT. SHARE LIMIT 0 oznacza, że udostępniasz tylko karty hop=0 (lokalne) — karty peera nigdy nie są ponownie udostępniane twoim klientom. Ustaw to na 1, aby umożliwić jeden poziom ponownego udostępniania:

SHARE LIMIT: 1

Sprawdź również wartość RESHARE przypisaną peerowi w konfiguracji linii C. Niektóre kompilacje obsługują poziom ponownego udostępniania dla każdego peera w składni linii C.

Aktualizacje EMM zablokowane — uprawnienia karty nie są odświeżane

To powoli niszczy konfiguracje. Jeśli RECEIVE EMM: no znajduje się w twojej konfiguracji (lub brakuje go w niektórych kompilacjach, które domyślnie są wyłączone), karta przestaje otrzymywać komunikaty aktualizacji uprawnień z transmisji. Z czasem uprawnienia subskrypcji wygasają i kanały przestają się deszyfrować — często zaczynając od pakietów premium.

RECEIVE EMM: yes

Ustaw to i uruchom ponownie CCcam. W zależności od tego, jak długo EMM był wyłączony, może upłynąć kilka minut do godziny, zanim karta otrzyma i przetworzy wszystkie aktualizacje uprawnień. Uprawnienia ograniczone czasowo są szczególnie podatne tutaj — karta, która działała prawidłowo, może cicho przestać deszyfrować kanały w środku sesji, gdy jej przechowywane uprawnienia wygaśną bez odnowienia.

Opóźnienie sieciowe powodujące limity czasu ECM na kanałach szybkiego przełączania

Domyślny limit czasu ECM CCcam wynosi 3000ms. Na szybko przełączającym się odbiorнiku lub podczas szybkiego przełączania się między kanałami, żądania ECM muszą zostać ukończone przed upływem limitu czasu, w przeciwnym razie otrzymasz błąd "timeout". Jeśli połączenie peer ma opóźnienie round-trip 150-200ms, a przetwarzanie karty dodaje kolejne 200-300ms, jest to bliskie granicy.

Możesz dostosować limit czasu w CCcam.cfg:

ECM TIMEOUT: 5000

Zwiększenie tego daje wolnym perom więcej czasu

Różnice protokołu Newcamd lub CS378X podczas bridżowania do OScam

Jeśli łączysz CCcam z OScam za pośrednictwem protokołu Newcamd (skonfigurowanego z NEWCAMD PORT: 15050 <klucz DES> w CCcam.cfg), niezgodności wersji lub niezgodności klucza DES spowodują ciche błędy w określonych CAID. Wpis /etc/oscam/oscam.server w OScam dla połączenia CCcam musi dokładnie odpowiadać wersji protokołu:

[reader]
label = cccam_bridge
protocol = cccam
device = 127.0.0.1,12000
user = username
password = password
caid = 0919,0500

Jeśli niektóre CAID działają przez bridge, a inne nie, sprawdź filtrowanie CAID po obu stronach. OScam ma swój własny filtr CAID na czytelnik, który może blokować CAID niezależnie od własnych filtrów CCcam. Zwróć także uwagę na niezgodności wersji CCcam między serwerem a klientem — starsze wersje CCcam czasami nie powiodą się w negocjacji udostępniania dla określonych systemów CA, gdy obsługa protokołu się rozbieża.

Ocena zdalnego połączenia peera CCcam pod względem pokrycia kanałów

Otrzymanie linii C od peera to dopiero początek. Sama linia C mówi ci prawie nic o tym, jakie kanały serwera cccam są rzeczywiście dostępne przez nią.

Co mówi Ci linia C — i czego nie mówi

Linia C wygląda tak:

C: hostname.example.com 12000 myuser mypassword

To wszystko. Cztery pola: host, port, nazwa użytkownika, hasło. Linia C zawiera zero informacji o tym, które CAID, identyfikatory dostawcy lub SID udostępnia peer. Dowiadujesz się tego dopiero po połączeniu i zbadaniu tabeli udziałów webowego interfejsu. Każdy, kto twierdzi, że oferuje „X kanałów" w opisie linii C, mówi ci o nominalnym pokryciu subskrypcji karty, a nie o tym, co rzeczywiście otrzymasz — te liczby pogorszą się wraz z liczbą przeskoków, obciążeniem serwera i konfiguracją filtra.

Jak przetestować linię C przed zaangażowaniem się w nią

Dodaj linię C do CCcam.cfg, uruchom ponownie CCcam i natychmiast sprawdź port 16001. W ciągu 30-60 sekund karty peera powinny pojawić się w tabeli kart/udziałów. Zwróć uwagę na:

• Jakie CAID się pojawią — czy odpowiadają temu, czego potrzebujesz?
• Jaki jest licznik przeskoków? Hop=1 to dobra rzecz; hop=3 lub więcej to czerwona flaga.
• Sprawdź czasy odpowiedzi ECM w dzienniku dla znanego kanału. Konsekwentnie poniżej 800ms to solidne; powyżej 1500ms spowoduje problemy.
• Obserwuj stabilność połączenia przez 10-15 minut. Jeśli peer regularnie się rozłącza i ponownie łączy, to problem niezawodności.

Ogólne kryteria oceny jakości kanału peera/serwera

Nie ufaj tylko temu, że peer jest dobry, ponieważ się połączył. Oceń to prawidłowo:

• Ping poniżej 200ms do hosta serwera z Twojej sieci
• Czasy odpowiedzi ECM konsekwentnie poniżej 1500ms w dzienniku CCcam
• Karty się pojawiają

Peer reklamujący tysiące kanałów poprzez wiele hopów to niemal zawsze łańcuch ponownego udostępniania z dużym opóźnieniem i wątpliwą niezawodnością. Karty lokalne przy hop=0 lub bezpośredni peery przy hop=1 to to, czego chcesz dla niezawodnych kanałów serwera cccam.

Sprawdzanie czasu działania Peer i czasu odpowiedzi ECM za pośrednictwem interfejsu sieciowego CCcam

Interfejs sieciowy CCcam pokazuje statystyki ECM dla każdego połączenia, jeśli masz aktywne rejestrowanie debugowania. Spójrz na sekcję "clients" pod kątem czasu połączenia i liczby ECM/wskaźnika powodzenia. Peer, który był połączony przez 20 godzin z 5000 ECM i tylko 3 awariami, to solidna opcja. Peer wykazujący 40% wskaźnik timeout w historii ECM to śmiecie — przejdź dalej.

Zrozumienie dostępu do kart wspólnych i dedykowanych oraz jego wpływ na kanały

Dostęp wspólny oznacza, że jedna fizyczna karta obsługuje żądania ECM dla wielu równoczesnych klientów. Każde żądanie ECM jest sekwencyjne na karcie — karta przetwarza jedno na raz. Pod dużym obciążeniem czasy odpowiedzi rosną, a timeout zwiększają się. Dlatego kanały serwera cccam na silnie obciążonym serwerze wspólnym zamarzają podczas szczytowych godzin oglądania, nawet jeśli CAID jest obecny, a subskrypcja jest ważna.

Dostęp dedykowany — gdzie karta obsługuje tylko Twoje połączenie — eliminuje konkurencję o kolejkę. Odpowiedzi ECM pozostają szybkie niezależnie od tego, co się dzieje. Kompromis to koszt i dostępność. Podczas oceny peera zapytaj, czy karta jest wspólna dla wielu użytkowników, czy przydzielona Tobie specjalnie. Odpowiedź wyjaśnia wiele na temat tego, czego doświadczysz.

Jeszcze jedna rzecz, którą warto obserwować: kanały DVB-S2 korzystające z modulacji ACM lub VCM wymagają sprzętu obsługującego kodowanie zmienne. Jeśli karta tunera serwera nie obsługuje ACM, nie może nawet odbierać tych transpondów — oznacza to, że karta jest niedostępna dla tych kanałów, nawet jeśli CAID i subskrypcja są całkowicie prawidłowe. To ograniczenie sprzętu po stronie serwera, a nie problem konfiguracji oprogramowania.