Porównanie konfiguracji OSCam: Metody konfiguracji& Protokoły

Jeśli dotarłeś tak daleko, już wiesz, że klienci tylko CCcam to ślepy zaułek, a OSCam to elastyczna opcja. Ale "zainstaluj OSCam" to nie jest jedna decyzja — to cztery lub pięć. Binarne czy źródło? Docker czy bare metal? Emu czy standardowa wersja? CCcam, newcamd, cs378x czy mgcamd dla twojego protokołu? To porównanie konfiguracji OSCam przeprowadza przez każdy rozwidlenie drogi, abyś nie był trzy godziny w budowie, zanim zdasz sobie sprawę, że wybrałeś złą ścieżkę dla swojego sprzętu.

Porównanie metod instalacji OSCam: Binarne, Źródło i Docker

Najszybszym sposobem na uruchomienie OSCam jest pobranie wstępnie zbudowanego binarnego pliku — pakiety SimpleBuild lub build feed, jeśli jesteś na Enigma2. Problem polega na tym, że dziedziczysz wszelkie flagi modułów, które pakujący wbudował. Jeśli twój plik binarny nie został skompilowany z obsługą MODULE_CCCAM lub CS_CACHEEX, żadna ilość edytowania konfiguracji nie sprawi, że się pojawi.uruchomoscam -V

po instalacji i sprawdź wbudowane moduły, zanim założysz, że cokolwiek działa.Kompilacja ze źródła daje pełną kontrolę. Pobierasz źródło SVN, uruchamiasz./config.sh i przełączasz dokładnie to, czego potrzebujesz: READER_NAGRA, READER_VIACCESS, MODULE_CCCAM, MODULE_NEWCAMD, WEBIF, CS_CACHEEX, CS_CACHEEX_AIO. Następniemake

i kompilujesz przeciwko własnemu narzędziom. To zajmuje więcej czasu i wymaga build-essential, libssl-dev i libpcsclite-dev przynajmniej na systemach opartych na Debianie, ale to jedyna droga, jeśli potrzebujesz nietypowej kombinacji modułów lub celujesz w sprzęt, dla którego nikt inny nie buduje.

Wstępnie zbudowany plik binarny (pakiety SimpleBuild / feed)Na boxach Enigma2 pliki binarne zazwyczaj trafiają do/usr/bin/oscam lub/var/bin/oscam, a konfiguracja znajduje się pod/etc/tuxbox/config/oscam/. Na ogólnych systemach Linux pakiety feed często domyślnie trafiają do/var/keys/

dla konfiguracji. To właściwy wybór, jeśli nie robisz nic egzotycznego — chcesz, aby kanały były dekodowane dzisiaj, a nie niestandardowa budowa jutro.

Kompilacja ze źródła SVN z make config

Budowy ze źródła są nie do negocjacji, jeśli chcesz peering cacheex, konkretną skórkę webif lub moduły czytnika, które pakujący pominął. Spodziewaj się budowy trwającej 5-15 minut na Raspberry Pi 4, sekundy na nowoczesnym komputerze x86. Zachowaj dokumentację swoich wyborów w config.sh gdzieś — sześć miesięcy później nie będziesz pamiętał, dlaczego brakuje cacheex.

Wdrożenie kontenera DockerDocker izoluje zależności OSCam od twojego hosta, co jest świetne na serwerach x86 uruchamiających inne usługi. Obrazy OSCam oparte na Alpine utrzymują mały ślad. Kompromis: czytniki kart USB (smargo, phoenix) potrzebują przejścia urządzenia, a to mapowanie psuje się przy ponownym uruchomieniu hosta, jeśli ścieżka urządzenia zmienia się z/dev/ttyUSB0 na/dev/ttyUSB1

— przypinaj według identyfikatora urządzenia w swoim docker-compose, a nie według ścieżki, inaczej będziesz gonić to za każdym razem, gdy jądro enumeruje USB w innej kolejności.

OSCam-emu vs standardowe budowy OSCam

OSCam-emu dodaje wsparcie dla softcam.key i emulacji opartej na constcw na standardowej funkcjonalności odczytu kart. Jeśli twoja konfiguracja opiera się wyłącznie na fizycznej karcie lub udostępnianiu peer, standardowy OSCam jest lżejszy, ma mniejszą powierzchnię ataku i nie wymaga częstego obracania plików kluczy, które wymagają budowy emu. Sięgaj po emu tylko wtedy, gdy rzeczywiście polegasz na emulowanych CW.

Porównanie struktur plików konfiguracyjnych OSCam

OSCam dzieli konfigurację na kilka plików, a zrozumienie, co gdzie się znajduje, to połowa walki. To jest część każdego porównania konfiguracji OSCam, która sprawia ludziom najwięcej problemów, ponieważ pliki współdziałają — czytnik w jednym pliku jest bezużyteczny bez odpowiadającego konta w innym.

ustawienia globalne i monitorujące w oscam.conf trzyma[global] blok (logfile, cachedelay, clienttimeout),[webif] — domyślny port 8888 oraz sekcje protokołów, takie jak[cs378x],[newcamd] z jego kluczem DES oraz[cccam] na porcie 12000. To jest plik zachowań dla całego serwera. Ustawhttpuser orazhttppwd w[webif] natychmiast — nieautoryzowany webif na porcie 8888 wystawiony na internet to poważny problem, a nie teoretyczny, ponieważ ujawnia status czytnika i może pozwolić atakującemu na rekonfigurację twojego urządzenia.

definicje czytników oscam.server

oscam.server to miejsce, gdzie żyje każdy[reader] blok — etykieta, protokół (cccam/mgcamd/internal), ścieżka urządzenia, klucz, grupa, caid i identyfikator. Minimalny blok fizycznego czytnika kart wygląda tak:

[reader]







kontrola kont i grup oscam.user

oscam.user łączy konta klientów z grupami, aby kontrolować, do których CAID-ów mają dostęp. Działające minimalne konto:

[account]





Tagroup = 1 musi odpowiadać czytnikowigrupa = 1 w oscam.server. Ta niezgodność numeru grupy jest, z mojego doświadczenia, najczęstszym powodem, dla którego ludzie łączą się poprawnie, ale nie mają żadnych dekodowanych kanałów — wszystko wygląda zdrowo w webif, klient się autoryzuje, a nic się nie dzieje, ponieważ numery grup nie pokrywają się. Sprawdź to, zanim dotkniesz czegokolwiek innego.

mapowanie oscam.services i oscam.dvbapi

oscam.services mapuje nazwy kanałów w formacie czytelnym dla ludzi na kombinacje CAID/dostawca/SID, przydatne do logowania i filtrowania.oscam.dvbapi obsługuje lokalne mapowanie demuxera, gdy OSCam bezpośrednio przekazuje dvbapi odbiornika zamiast klienta sieciowego. Uprawnienia do wszystkich tych plików powinny być 0644, należące do użytkownika, pod którym działa OSCam. I pamiętaj: OSCam ładował większość ustawień nakill -SIGHUP $(pidof oscam) bez pełnego restartu — ale jeśli wprowadziłeś błąd składniowy, ponowne załadowanie cicho zawodzi, a stara konfiguracja nadal działa. Zawsze sprawdzaj log po SIGHUP, aby potwierdzić, że faktycznie wprowadził twoje zmiany.

Porównanie protokołów: CCcam vs newcamd vs cs378x vs mgcamd

Wybór protokołu naprawdę zależy od tego, dokąd zmierza połączenie i jakie warunki sieciowe będzie musiało znosić. To jest sekcja porównania konfiguracji oscam, która jest najczęściej pomijana, a to część, która decyduje o tym, czy twoja konfiguracja przetrwa zły link WAN.

Protokół CCcam (port 12000) — kontrola nodeid i hop

CCcam pozostaje najbardziej kompatybilnym protokołem — praktycznie każdy klient go obsługuje. Działa na porcie 12000 domyślnie, używa nodeid do wykrywania pętli i pozwala ustawić limity hop, aby kontrolować głębokość udostępniania. Wada: struktura protokołu CCcam ujawnia informacje o drzewie udostępniania każdemu, kto ma dostęp do czytnika, co jest realnym zagadnieniem, jeśli łączysz się z podmiotami, którym nie ufasz w pełni.

newcamd (szyfrowane DES, porty per-CAID)

newcamd szyfruje sesję za pomocą klucza DES, który definiujesz w[newcamd] — a ten klucz musi mieć dokładnie 14 bajtów w formacie hex. Jeśli długość jest błędna, autoryzacja cicho zawodzi bez oczywistego błędu w logu poza odrzuconym połączeniem; sprawdź długość ciągu klucza, zanim spędzisz godzinę na debugowaniu gdzie indziej. newcamd jest solidny w WAN i zazwyczaj potrzebuje jednego portu na grupę CAID, więc zaplanuj swoją alokację portów (15000, 15001 itd.) przed skonfigurowaniem klientów.

cs378x — camd35 przez TCP

cs378x to camd35 działający przez TCP zamiast UDP, i to moja domyślna rekomendacja dla zdalnych partnerów. Niskie obciążenie, przyjazny dla zapory, ponieważ to standardowy strumień TCP, i toleruje NAT bez specjalnego traktowania. Porty są definiowane przez użytkownika, zwykle w zakresie 34000+ — nic nie jest ustalone przez sam protokół, to cokolwiek ustawisz w oscam.conf.

mgcamd / cs357x rozważania dotyczące UDP

cs357x mgcamd działa przez UDP, co oznacza niższe obciążenie na pakiet, ale prawdziwą wrażliwość na utratę pakietów — nie ma retransmisji na poziomie protokołu, więc utrata pakietów w linku WAN prowadzi do zacinania się lub utraty ECM. Dobrze na stabilnym LAN, ryzykowne przez otwarty internet. Jeśli łączysz dwa miejsca przez połączenie konsumenckie, nie sięgaj najpierw po UDP mgcamd.

Zasada ogólna: lokalny klient na tej samej skrzynce → wewnętrzny/dvbapi, nie potrzebny protokół sieciowy. Zdalny partner przez internet → cs378x lub newcamd. Klient starszej generacji, który mówi tylko jednym językiem → CCcam, akceptując kompromis związany z drzewem udostępniania. W przypadku peeringu cacheex konkretnie, tryb 1 przesyła wszystko (najwyższa przepustowość, najniższe opóźnienie do pierwszego dekodowania), tryb 2 przesyła tylko żądane CW (umiarkowana przepustowość), a tryb 3 jest tylko push do konkretnych partnerów (najniższa przepustowość, używane do kontrolowanego rozprzestrzeniania). Tryb 1 zauważalnie zwiększy twoje wykorzystanie przepustowości w górę przy więcej niż kilku partnerach — widziałem, jak podwaja outbound traffic w porównaniu do trybu 2 na zajętym czytniku.

Rozważania dotyczące sprzętu i wydajności w różnych konfiguracjach

Gdzie uruchamiasz OSCam ma znaczenie tak samo, jak to, jak go skonfigurowałeś. Wybór protokołu, który jest w porządku na dedykowanym serwerze, może zatykać niedostatecznie wydajny odbiornik.

Odbiorniki wbudowane (Enigma2 MIPS/ARM) vs serwery x86

Uruchamianie OSCam bezpośrednio na twoim boxie Enigma2 jest wygodne — brak dodatkowego sprzętu, konfiguracja tuż pod/etc/tuxbox/config/. Ale jesteś ograniczony przez to, ile RAM i CPU ma ten box, zazwyczaj znacznie mniej niż zapasowy komputer, a OSCam umiera za każdym razem, gdy uruchamiasz odbiornik ponownie w celu aktualizacji oprogramowania. Jeśli nie ma gotowego binarnego pliku dla twojego konkretnego obrazu, kompilujesz krzyżowo z narzędziem MIPS lub ARM (takim jak narzędzie OpenEmbedded pasujące do jądra twojego odbiornika), co jest wykonalne, ale dodaje realny czas konfiguracji. Dedykowany serwer x86 lub host Docker obsługuje więcej równoczesnych klientów, przetrwa niezależnie ponowne uruchomienia odbiornika i jest lepszym wyborem, gdy łączysz się z cacheex lub obsługujesz więcej niż kilku klientów.

Interfejsy czytników kart smart (phoenix, smargo, wewnętrzny)

Czytniki Phoenix i smartmouse potrzebują poprawnychmhz icardmhz ustawień w oscam.server — 357/357 to klasyczny domyślny ISO7816, ale niektóre karty wymagają 600 dla cardmhz, pozostając przy mhz=357. Jeśli masz mieszane karty na tym samym boxie — jedna potrzebująca 357, druga chcąca 600 — ustaw te wartości dla każdego czytnika w ich indywidualnych[reader] blokach, a nie globalnie; globalna niezgodność sprawi, że jedna karta będzie działać, a druga będzie ciągle zgłaszać błędy CRC. Czytniki Smargo są zazwyczaj bardziej wyrozumiałe w tej kwestii, ale potrzebują odpowiedniej reguły udev, aby węzeł urządzenia był spójny.

CPU, czas ECM i limity równoczesnych klientów

Zdrowy czas odpowiedzi ECM powinien wynosić znacznie poniżej 1000 ms — jeśli regularnie widzisz odpowiedzi 2000 ms+, coś jest nie tak, niezależnie od tego, czy to przeciążona karta, zła łączność czytnika, czy zbyt wielu klientów korzystających z jednego czytnika. Ustawmaxidle ireconnecttimeoutrozsądnie w oscam.server, aby martwe połączenia były usuwane zamiast się gromadzić. CS_CACHEEX powoduje realne obciążenie CPU, ponieważ każde połączenie z peerem oznacza ciągłe przetwarzanie i przesyłanie ruchu CW — na Raspberry Pi 3 powinienem utrzymywać niską liczbę peerów; na nowoczesnym komputerze x86 to nie jest problem, dopóki nie masz dziesiątek peerów.

Trwałość, logowanie i watchdog

Obracaj swój plik dziennika — OSCam z radością zapełni dysk logowaniem na poziomie debugowania przez tygodnie, jeśli mu na to pozwolisz, użyj logrotate z tygodniową rotacją i kompresją. Uruchom OSCam pod nadzorem procesu (jednostka systemd zRestart=on-failurejest najprostsza) zamiast polegać wyłącznie na logice ponownego połączenia OSCam, aby awaria rzeczywiście przywróciła cię do sieci zamiast cichego martwego procesu.

Jak ocenić źródło karty/serwera w sposób ogólny

Cokolwiek łączysz ze swoim czytnikiem po drugiej stronie, oceniaj to w ten sam sposób, w jaki oceniasz każdą usługę techniczną — według obiektywnych, mierzalnych kryteriów, a nie twierdzeń marketingowych.

Czas pracy i opóźnienie ECM jako obiektywne kryteria

Obserwuj swoje własne czasy odpowiedzi ECM w interfejsie webowym OSCam przez kilka dni, szczególnie w godzinach szczytu wieczorem. Źródło, które działa dobrze o 14:00, ale skacze do 3000 ms+ czasów ECM o 21:00, pokazuje problem z nadmierną sprzedażą, a nie błąd konfiguracji z twojej strony — zbyt wielu klientów dzieli zbyt mało slotów czytnika. To różni się od rzeczywistej błędnej konfiguracji, która zazwyczaj ujawnia się natychmiast i konsekwentnie, a nie tylko pod obciążeniem.

Przejrzystość protokołu i CAID

Źródło, które jest gotowe podać dokładne wartości CAID i identyfikatorów, limity skoków oraz szczegóły protokołu, których potrzebujesz do swojego bloku oscam.server, zachowuje się profesjonalnie. Niejasne odpowiedzi lub odmowa określenia, jakie CAID są faktycznie obsługiwane, to sygnał, aby szukać gdzie indziej.

Reaktywność wsparcia i dokumentacja konfiguracji

Jak szybko i jasno otrzymujesz odpowiedź, gdy twój czytnik pokazuje połączenie, ale brak dekodowania, mówi ci wiele. Dokumentacja, która odpowiada rzeczywistej strukturze twojego pliku konfiguracyjnego — a nie ogólne zrzuty ekranu — jest warta więcej niż jakiekolwiek twierdzenie o czasie pracy, którego nie możesz niezależnie zweryfikować.