Telewizja satelitarna bez subskrypcji: CCcam& Przewodnik po konfiguracji OScam

Jeśli kiedykolwiek zastanawiałeś się, jak ludzie uruchamiają zestawy telewizji satelitarnej bez subskrypcji na swoim odbiorniku Dreambox lub VU+, odpowiedź prawie zawsze sprowadza się do dwóch programów: CCcam i OScam. Ten przewodnik pomija marketing i przechodzi do rzeczywistego protokołu, plików konfiguracyjnych i kroków rozwiązywania problemów, których potrzebujesz. Zakładaj, że już czujesz się komfortowo z SSH i edytorem tekstu — to nie jest ćwiczenie dla początkujących.

Jak działa udostępnianie kart (CCcam vs OScam)

Podstawowa koncepcja jest prostsza, niż sugeruje żargon. Transmisja satelitarna szyfruje swój strumień za pomocą szybko zmieniającego się klucza — słowa kontrolnego (CW). Aby uzyskać ten klucz, twój odbiornik wysyła ECM (Entitlement Control Message) do serwera, który posiada legalną kartę inteligentną. Karta serwera deszyfruje ECM, wyodrębnia CW i odsyła go z powrotem do twojego odbiornika. Twój odbiornik używa tego CW do dekodowania wideo.

Innym typem wiadomości, który zobaczysz w logach, jest EMM — Entitlement Management Message. EMM nie przenoszą CW bezpośrednio; są używane do aktualizacji uprawnień na samej karcie, dodając lub usuwając dostęp do kanałów. ECM występują nieustannie (co kilka sekund, gdy CW się zmienia). EMM są mniej częste, ale mają znaczenie dla utrzymania aktualności subskrypcji karty.

Wyjaśnienie wymiany słowa kontrolnego i ECM/EMM

Twój odbiornik dostraja się do kanału i trafia na warstwę CA (conditional access). Nie może samodzielnie dekodować, więc przesyła ECM w górę do kogoś, kto posiada kartę. Karta deszyfruje go i zwraca 8-bajtowe CW. Cała podróż tam i z powrotem musi odbyć się w znacznie krótszym czasie niż sekunda — okres CW wynosi zazwyczaj 10 sekund, ale jeśli odpowiedź na ECM zajmuje zbyt długo, następuje zacięcie przed przybyciem nowego CW.

Ten cykl to to, o co chodzi w monitorowaniu "czasu ECM". Szybka karta w lokalnej sieci jest trywialna. Karta znajdująca się za trzema hopami udostępniania z wolną siecią pomiędzy to miejsce, gdzie zaczynają się problemy.

Model klient-serwer: co żąda odbiornik

Odbiornik (lub softcam działający na nim) działa wyłącznie jako klient. Wie, że nie może samodzielnie dekodować strumienia, więc łączy się wychodząco z serwerem udostępniania przez TCP. Wysyła ECM, czeka na CW i dekoduje. Serwer wykonuje rzeczywistą pracę z kartą. Dlatego przekierowanie portów jest kwestią po stronie serwera — klient inicjuje połączenie.

Protokół CCcam vs protokół OScam vs newcamd

CCcam używa własnego zamkniętego protokołu binarnego. Domyślny port to 12000 (TCP). Był dominujący przez lata, ale protokół nie jest udokumentowany, a ostatni oficjalny plik binarny CCcam pochodzi z około 2012 roku. Nadal działa, nadal jest szeroko rozumiany przez odbiorniki, ale nie było aktywnego rozwoju od ponad dekady.

OScam jest open-source i implementuje wiele protokołów jednocześnie na różnych portach. Z pudełka możesz uruchomić protokół cccam na 12000 dla zgodności z odbiornikami, newcamd na porcie według własnego wyboru (5000 jest powszechny) oraz camd35, jeśli to konieczne — wszystko z jednej instancji OScam. Możesz również bezpośrednio podłączyć fizyczne czytniki kart inteligentnych.

Newcamd (Network Camd) to starszy, ale nadal używany protokół z własną warstwą szyfrowania dla handshake. Jest wolniejszy w konfiguracji, ale wspierany przez prawie każdy odbiornik. Większość nowoczesnych konfiguracji domyślnie korzysta z protokołu cccam dla klientów, ponieważ wsparcie dla odbiorników jest uniwersalne.

Dlaczego OScam w dużej mierze zastąpił CCcam w nowych konfiguracjach

OScam odczytuje fizyczne karty inteligentne za pomocą wewnętrznych lub zewnętrznych czytników kart inteligentnych (USB lub szeregowy). Ma na żywo interfejs webowy do monitorowania. Jest aktywnie utrzymywany z commitami w 2025 i 2026 roku. I obsługuje translację protokołów — klient łączący się przez protokół cccam może udostępniać z karty, którą OScam odczytuje natywnie. CCcam nie może tego zrobić. Dla nowej budowy serwera nie ma powodu, aby zaczynać od CCcam.

Konfiguracja serwera OScam: Pliki konfiguracyjne i struktura

Konfiguracja OScam jest podzielona na kilka plików tekstowych. Nie jest wymagane żadne binarne bazy danych ani GUI — tylko pliki, uprawnienia i ponowne uruchomienie. Katalog konfiguracyjny jest ustawiany w czasie kompilacji, co jest pierwszym problemem, gdy uruchamiasz wstępnie zbudowany plik binarny z obrazu Enigma2.

Podstawowe pliki konfiguracyjne: oscam.conf, oscam.server, oscam.user

Trzy pliki wystarczą, aby uruchomić.oscam.conf to główny plik konfiguracyjny — globalne ustawienia, porty protokołów i interfejs webowy.oscam.server definiuje twoje czytniki (fizyczne karty lub połączenia udostępniania w górę).oscam.user definiuje, kto może łączyć się jako klient. Dodatkowe opcjonalne pliki, takie jakoscam.services ioscam.provid pozwalają filtrować według dostawcy/kanalu, ale nie potrzebujesz ich, aby zacząć.

Gdzie znajdują się pliki konfiguracyjne (/etc/tuxbox/config lub /usr/keys)

To zależy całkowicie od wersji. W większości obrazów Enigma2 (OpenPLi, OpenATV) OScam skompilowany dla tego obrazu używa/etc/tuxbox/config/. W niektórych obrazach to/var/keys/. Jeśli OScam cicho nie uruchamia się po instalacji, to prawie zawsze jest powód — plik binarny szuka swoich plików w jednej ścieżce, a ty umieściłeś je w innej.

Znajdź właściwą ścieżkę za pomocą:oscam --help 2>&1 | grep config lub sprawdź skrypt uruchamiający w/etc/init.d/oscam. Możesz również nadpisać przy uruchomieniu:oscam -b -c /etc/tuxbox/config. Gdy już znasz prawdziwą ścieżkę, umieść tam wszystkie swoje pliki konfiguracyjne.

Definiowanie czytnika w oscam.server

Oto minimalny blok czytnika dla fizycznej karty smartcard w wewnętrznym slocie:

[reader]

Numergrupy jest krytyczny — musi odpowiadaćgrupie w odpowiadającymoscam.user koncie, inaczej nie dojdzie do routingu współdzielenia. Wiele osób ustawia czytniki i konta, nie widzi błędów, a mimo to dostaje "brak karty", ponieważ numery grup nie pasują. Sprawdź to najpierw.

Dla zewnętrznego czytnika kart USB, zamieńdevice = /dev/sci0 nadevice = /dev/ttyUSB0 i dostosuj mhz do 368 zazwyczaj.

Tworzenie kont klientów w oscam.user

Każdy klient otrzymuje blok konta:

[account]

au = 1 włącza przesyłanie EMM dla tego klienta (pozwala karcie na aktualizację).monlevel = 0 ukrywa to konto z aktywnej listy klientów w interfejsie webowym — przydatne dla prywatności. Dodaj tyle[account] bloków, ile potrzebujesz, jeden na klienta.

Włączanie interfejsu webowego (httpport)

Dodaj to dooscam.conf pod[webif] blokiem:

[global]

Jeślihttpallowed nie jest ustawione lub jest przypisane do 127.0.0.1, będziesz mógł uzyskać dostęp do interfejsu webowego tylko z localhost — nie z twojej sieci LAN. To powszechny powód, dla którego interfejs użytkownika wydaje się niedostępny, mimo że OScam działa poprawnie.

Podłączanie odbiornika klienta do serwera udostępniania

Twój odbiornik musi wiedzieć, gdzie prosić o dekodowanie. Jeśli używasz softcamu, który odczytuje CCcam.cfg, to jest to jedna linia. Jeśli również uruchamiasz OScam po stronie klienta, to jest to blok czytnika.

Format linii klienta CCcam.cfg (linia C:)

Otwórz/etc/CCcam.cfg na swoim odbiorniku i dodaj linię C:

C: hostname.example.com 12000 myusername mypassword

To wszystko. Pola to: C: (literalnie), hostname lub IP, port, nazwa użytkownika, hasło — oddzielone spacjami. Bez cudzysłowów. Jedna linia na serwer. Klienci CCcam próbują połączeń w kolejności, jeśli masz wiele linii; pierwszy działający serwer wygrywa.

Zauważ, że softcam na twoim odbiorniku musi być uruchomiony, aby to działało. Na Enigma2 uruchom go z menedżera softcamu w menu lub za pomocą/etc/init.d/softcam start.

Klient OScam przez camd35 lub czytnik cccam

Jeśli uruchamiasz OScam na odbiorniku klienta (co ma zalety w monitorowaniu i filtrowaniu), dodaj czytnik dooscam.server:

[reader]

To mówi OScam, aby połączyć się z serwerem za pomocą protokołu cccam. Pojawia się jako czytnik w interfejsie webowym, tak jak fizyczna karta, co znacznie ułatwia diagnostykę.

Pola portu, hostname, nazwy użytkownika, hasła

Hostname może być adresem IP lub domeną. Jeśli serwer jest za dynamicznym IP i używa hostname DDNS, upewnij się, że domena jest poprawnie rozwiązywana z sieci twojego odbiornika. Port 12000 to standardowy port CCcam, ale serwery mogą używać dowolnego portu — potwierdź rzeczywisty port, zanim założysz, że to 12000.

Dane uwierzytelniające są wrażliwe na wielkość liter. Kopiuj i wklej zamiast przepisywać, aby uniknąć literówek. Złe hasło powoduje połączenie, które uwierzytelnia się i natychmiast przerywa — zobaczysz "odrzucone" w dzienniku OScam serwera.

Testowanie połączenia i odczyt czasu ECM

Otwórz interfejs webowy OScam na swoim kliencie lub serwerze podhttp://ip-address:8888. Przejdź do sekcji Czytniki. Działający czytnik pokazuje status "połączony" i zobaczysz, jak liczba ECM wzrasta, gdy przełączysz się na zaszyfrowany kanał.

Czas ECM jest wyświetlany dla każdego czytnika. Poniżej 200 ms jest doskonałe. Poniżej 400 ms jest w porządku do codziennego użytku. Powyżej 1000 ms zobaczysz widoczne zacięcia kanału. Jeśli czytnik pokazuje "wyłączony" lub "błąd" zamiast "połączony", problem leży w danych uwierzytelniających, hoście/porcie lub zaporze — przepracuj te kwestie w tej kolejności.

Rozwiązywanie powszechnych problemów z udostępnianiem kart

Większość problemów mieści się w niewielkiej liczbie kategorii. Oto jak faktycznie je zdiagnozować, a nie tylko restartować rzeczy i mieć nadzieję.

Zacięcia kanałów i wysokie czasy ECM

Jeśli wideo zastyga co 10 sekund lub coś w tym stylu, CW nie dociera na czas. Sprawdź czasy ECM w interfejsie webowym OScam dla odpowiedniego czytnika. Cokolwiek konsekwentnie powyżej 800 ms to problem, który czeka na wystąpienie; powyżej 1000 ms zacięcia stają się regularne.

Przyczyny: zbyt wiele przeskoków udostępniania między źródłową kartą a twoim odbiornikiem, odległość geograficzna i opóźnienie, lub przeciążony serwer w godzinach szczytu. Liczba przeskoków jest widoczna w interfejsie webowym OScam — przeskok 1 oznacza, że serwer, do którego jesteś podłączony, trzyma kartę bezpośrednio. Przeskok 3+ oznacza, że jesteś przynajmniej na trzech serwerach oddalonych od karty, a opóźnienie kumuluje się na każdym kroku.

Sprawdź również utratę pakietów między tobą a serwerem. Wskaźnik utraty pakietów na poziomie 5% niszczy niezawodność ECM, ponieważ żądanie lub odpowiedź zostaje utracona i musi być ponownie wysłana.

'Błąd: czytnik nie połączony'

To prawie zawsze jedna z trzech rzeczy: zły hostname lub port, błędne dane uwierzytelniające lub zapora blokująca połączenie. Sprawdź dostępność portu z twojego odbiornika za pomocąnc -zv hostname 12000 lub z komputera w tej samej sieci LAN. Jeśli port nie odpowiada, problem leży po stronie serwera — albo OScam nie uruchamia swojego nasłuchu cccam, albo port jest zablokowany.

Na serwerze potwierdź, że nasłuch cccam działa, sprawdzającnetstat -tlnp | grep 12000. Jeśli OScam działa, ale port nie jest wymieniony, to[cccam] blok woscam.conf może być brakujący lub port może być 0 (wyłączony).

Zły katalog konfiguracyjny / OScam nie uruchomi się

Uruchom OScam ręcznie w trybie foreground z szczegółowym logowaniem, aby zobaczyć, co robi:oscam -b -c /etc/tuxbox/config -l /tmp/oscam_debug.log. Jeśli wyjdzie natychmiast bez żadnego logu, ścieżka konfiguracyjna jest błędna i kończy działanie cicho przed rozpoczęciem logowania.

Uprawnienia plików również mają znaczenie. Pliki konfiguracyjne powinny być czytelne przez użytkownika procesu oscam.chmod 644 /etc/tuxbox/config/oscam.* ichown oscam:oscam (lub jakikolwiek użytkownik, na którym działa OScam) rozwiązuje problemy z uprawnieniami. Sprawdź za pomocąls -la /etc/tuxbox/config/.

Również: sekcja[global] woscam.conf musi istnieć. Pusty lub źle sformatowanyoscam.conf powoduje, że OScam kończy działanie bez użytecznego błędu.

Problemy z zaporą ogniową i przekazywaniem portów NAT

Jeśli uruchamiasz serwer za domowym routerem, musisz przekierować port TCP 12000 (i 8888, jeśli chcesz zdalny dostęp do sieci) do wewnętrznego adresu IP serwera. Powszechnym błędem jest przekierowanie do niewłaściwego adresu IP w LAN, szczególnie jeśli dzierżawa DHCP serwera się zmienia. Najpierw ustaw statyczny adres IP LAN dla maszyny serwera.

Podwójne ustawienia NAT — gdzie twój ISP daje ci adres NAT klasy operatora przed twoim domowym routerem — są naprawdę problematyczne. Przekazywanie portów przez twój domowy router działa w twoim LAN, ale publiczny adres IP, do którego łączą się twoi klienci, nie jest osiągalny, ponieważ warstwa NAT ISP go blokuje. W tej sytuacji tunel VPN lub odwrotny proxy oparty na VPS (jak tunel WireGuard lub SSH do VPS z prawdziwym publicznym IP) jest jedynym czystym rozwiązaniem.

Testuj osiągalność portu z zewnątrz swojej sieci, używając narzędzia takiego jak canyouseeme.org lub łącząc się przez SSH do VPS i uruchamiając netcat stamtąd. Jeśli port nie jest osiągalny z zewnątrz, żaden klient się nie połączy, niezależnie od tego, jak poprawne są dane uwierzytelniające.

Czytanie logu OScam dla odrzuceń ECM

Włącz szczegółowe logowanie woscam.conf:

[global]

Obserwuj log na żywo za pomocątail -f /tmp/oscam.log. Kluczowe wpisy do poszukiwania:

• ECM odrzucone — karta odmówiła deszyfrowania tego ECM. Zwykle oznacza to, że subskrypcja karty nie obejmuje tego dostawcy lub karta jest przestarzała.
• brak karty — OScam nie znalazł czytnika, który może obsłużyć to ECM. Prawie zawsze jest to niezgodność numeru grupy między czytnikiem a kontem użytkownika.
• klient rozłączony — normalne, ale jeśli zdarza się to natychmiast po połączeniu, dane uwierzytelniające są błędne.
• ponowne uruchamianie czytnika — czytnik został odłączony i OScam próbuje ponownie. Jeśli to się powtarza co 30 sekund, serwer upstream odmawia połączenia.

Problemy z synchronizacją czasu to kolejny powód odrzucania ECM, który jest ignorowany. Jeśli twój STB został zrestartowany i zegar systemowy jest błędny (na przykład, różnica godzinowa, ponieważ NTP jeszcze się nie zsynchronizował), niektóre systemy CA odrzucają ECM na podstawie kontroli znaczników czasowych. Wymuś synchronizację NTP po restarcie:ntpdate pool.ntp.org lub włącz usługę NTP systemu na stałe.

Jak ocenić źródło udostępniania (kryteria ogólne)

Jeśli łączysz się z zewnętrznym źródłem zamiast odczytywać swoją kartę lokalnie, to, co oceniasz, to zasadniczo zdalny czytnik kart. Kryteria są techniczne, a nie marketingowe.

Wskaźniki dostępności i stabilności serwera

Wiarygodne źródło powinno być w stanie pokazać statystyki dostępności lub przynajmniej mieć historię, którą możesz zweryfikować — przez fora, raporty użytkowników lub testując linię próbną przez kilka dni w godzinach szczytu (wieczory, weekendy). Usługa, która wygląda dobrze o 3 nad ranem, ale ma problemy o 20, gdy wszyscy oglądają, to znany wzór w przypadku przeszacowanych konfiguracji.

Zapytaj, czy prowadzą jakąkolwiek stronę statusu lub monitorowania. Operatorzy, którzy traktują dostępność poważnie, zazwyczaj ją mają. Ci, którzy tego nie robią, to żółta flaga.

Lokalna karta vs reshare — dlaczego to ma znaczenie

Źródło hop 1 oznacza, że serwer, z którym się łączysz, fizycznie przechowuje kartę inteligentną. Źródło hop 2 oznacza, że twój serwer łączy się z innym serwerem, który przechowuje kartę. Każdy hop dodaje opóźnienie i potencjalny punkt awarii. Łańcuch reshare z 3 lub więcej hopów to prośba o kłopoty — jesteś trzy serwery od rzeczywistej karty, a każdy z tych linków, który się urwie, powoduje, że twoje połączenie zawodzi.

To jedna rzecz, którą większość konfiguracji ignorujących telewizję satelitarną bez subskrypcji nie wyjaśnia jasno: liczba hopów bezpośrednio wpływa na niezawodność, niezależnie od prędkości serwera. Szybka konfiguracja 3-hopowa jest często gorsza niż nieco wolniejsza konfiguracja 1-hopowa.

Opóźnienie, hop, i bliskość geograficzna

Dla odpowiedzi ECM w czasie 10 ms, karta musi być geograficznie blisko. Serwer w tym samym kraju co ty, obsługujący kartę bez reshare, może dostarczyć czasy ECM poniżej 100 ms w dobrym dniu. Serwer na innym kontynencie dodaje 80-150 ms podstawowego opóźnienia w obie strony, zanim karta w ogóle wykona swoją pracę.

Podczas oceny zapytaj, gdzie serwery są fizycznie zlokalizowane. Jeśli nie mogą lub nie chcą na to odpowiedzieć, opóźnienie, które widzisz w czasach ECM, i tak ci powie — uruchom połączenie na godzinę i obserwuj statystyki czytnika OScam. Spójne czasy ECM 300 ms są w porządku. Skoki do 900 ms co kilka minut oznaczają, że ścieżka jest niestabilna.

Czerwone flagi, które sygnalizują niepewną konfigurację

Kilka rzeczy, które powinny cię zatrzymać przed podjęciem decyzji:

• Brak oferowanego okresu próbnego — prosisz o zapłatę bez możliwości przetestowania stabilności
• Obietnice "nieograniczonych linii" lub "gwarantowanej dostępności" bez szczegółów — są bez znaczenia bez SLA za nimi
• Czasy ECM, które zmieniają się drastycznie z dnia na dzień — sugeruje, że serwer jest udostępniany przez wielu dostawców bez zarządzania pojemnością
• Wsparcie, które milknie na dni — jeśli nie możesz uzyskać odpowiedzi podczas oceny, nie oczekuj lepszej reakcji, gdy coś się zepsuje
• Tylko jeden adres IP serwera — brak redundancji oznacza, że jeśli ta maszyna ulegnie awarii, nie masz nic

Konfiguracja opisana w tym przewodniku daje ci narzędzia do samodzielnej oceny tego wszystkiego. Gdy OScam działa na twoim odbiorniku, masz monitorowanie ECM w czasie rzeczywistym i statystyki czytnika. Użyj ich — są bardziej wiarygodne niż jakiekolwiek twierdzenie marketingowe o telewizji satelitarnej bez subskrypcji.