Najlepsza konfiguracja czytnika OScam: przewodnik po pliku oscam.server 2026

Jeśli kiedykolwiek patrzyłeś na świeży plik oscam.server zastanawiając się, dlaczego połowa parametrów ma znaczenie, nie jesteś sam. Większość przewodników po prostu wkleja działający blok i mówi, żebyś wstawił swoje dane logowania. To pozwala na połączenie. Nie zapewnia jednak niezawodnego dekodowania i zdecydowanie nie wyjaśnia, dlaczego twój czytnik pokazuje "KARTA OK", podczas gdy każdy kanał nadal zgłasza błąd ECM.

To moja próba stworzenia rzeczywistego przewodnika po konfiguracji czytnika OScam — nie jest to blok do kopiowania i wklejania, ale uzasadnienie każdego wiersza, abyś mógł samodzielnie debugować to za sześć miesięcy, gdy coś się zepsuje o 2 w nocy. Uruchamiałem OScam na wszystkim, od Raspberry Pi 3 po dedykowany VPS, a wzorce awarii powtarzają się nieustannie. Zacznijmy od struktury pliku, ponieważ tam zaczyna się większość zamieszania.

Czym właściwie jest czytnik OScam (i jak różni się od konta)

Ludzie używają terminów "konto", "linia" i "czytnik" jakby były wymienne. W OScam nie są. Czytnik to źródło dekodowania ECM/EMM — kropka. Może to być fizyczna karta smartcard siedząca w urządzeniu Phoenix lub Smargo podłączonym do twojego boxa, lub może to być zdalne połączenie z kartą kogoś innego przez protokół sieciowy. W każdym przypadku, z perspektywy OScam, czytnik to po prostu coś, co może zapytać "czy możesz dla mnie zdekodować ten ECM?"

Zamieszanie zwykle wynika z pomylenia trzech plików konfiguracyjnych, które sprawiają, że instalacja OScam działa. oscam.conf zawiera ustawienia globalne — tryb równoważenia obciążenia, logowanie, porty webif, tego rodzaju rzeczy. oscam.user definiuje klientów, którym służysz, co oznacza boxy lub oprogramowanie łączące się z twoją instancją OScam. A oscam.server to miejsce, w którym znajdują się czytniki — każde źródło karty, lokalne lub zdalne, ma blok [reader] w tym pliku. Jeśli źle zrozumiesz tę separację, spędzisz godziny edytując niewłaściwy plik zastanawiając się, dlaczego nic się nie zmienia.

Czytnik vs. konto vs. użytkownik: trzy pliki konfiguracyjne

Pomyśl o tym jak o rurze. Klient łączy się przy użyciu danych logowania zdefiniowanych w oscam.user. Ten użytkownik jest przypisany do grupy. OScam następnie sprawdza oscam.server w poszukiwaniu czytnika, który dzieli ten sam numer grupy i jest w stanie dekodować żądany caid. Jeśli znajdzie taki, ECM jest przesyłany do tego czytnika — niezależnie od tego, czy to lokalna karta, czy peer trzy skoki dalej — a zdekodowany CW wraca w dół łańcucha do klienta.

To powiązanie grupowe jest najczęściej pomijanym elementem w każdym tutorialu "najlepsza konfiguracja czytnika oscam", który czytałem. Ludzie konfigurują idealny blok czytnika, zapominają ustawić numer grupy, aby pasował do ich użytkownika, a następnie spędzają godzinę na rozwiązywaniu problemu z phantom connection, który nigdy nie był problemem z połączeniem.

Lokalne czytniki kart vs. czytniki sieciowe (proxy)

Lokalny czytnik komunikuje się z fizycznym sprzętem — urządzenie = /dev/ttyUSB0 dla szeregowego czytnika Phoenix, na przykład, z detect=CD lub podobnym. Czytnik sieciowy, czasami nazywany czytnikiem proxy, łączy się przez TCP/IP z zdalnym serwerem OScam lub CCcam, używając protokołu takiego jak cccam, newcamd lub cs378x. Większość osób konfigurujących cardsharing dzisiaj zajmuje się prawie wyłącznie czytnikami sieciowymi, ponieważ rzeczywisty fizyczny sprzęt karty smartcard stał się mniej powszechny poza dedykowanymi farmami kart.

Gdzie znajdują się czytniki: oscam.server i jego rola w rurze

Każdy czytnik ma swoją własną sekcję [reader] w oscam.server, identyfikowaną przez unikalną etykietę. OScam analizuje ten plik przy starcie (lub przy ponownym załadowaniu przez webif) i próbuje nawiązać połączenie z każdym czytnikiem niezależnie. "Najlepsza" konfiguracja nie polega na wpychaniu każdego opcjonalnego parametru — chodzi o pisanie zwięzłych, minimalnych, poprawnie zasięgowych wpisów, aby OScam nigdy nie marnował czasu ani przepustowości na zapytania do źródła, które nie może odpowiedzieć.

Budowanie idealnego czytnika sieciowego w oscam.server

Oto pełny przykład z adnotacjami dla czytnika protokołu cccam. Rozłożę każdy wiersz później.

[reader]

Linia urządzenia to host,port — i chcę być jasny, nie ma uniwersalnego standardowego portu dla protokołów cardsharing. Zobaczysz, że 12000 jest powszechnie używane dla cccam, a coś w zakresie 5000 lub 8000 dla newcamd lub cs378x, ale te są całkowicie definiowane przez operatora. Ktoś, kto prowadzi źródło, mówi ci, jaki port. Nie zakładaj, że 12000 działa wszędzie tylko dlatego, że jest powszechne.

Pełny blok [reader]: etykieta, protokół, urządzenie, użytkownik, hasło, klucz

etykieta to tylko wewnętrzny identyfikator — spraw, aby była opisowa, ponieważ będziesz ją ciągle czytać w logach. protokół mówi OScam, który handshake użyć. urządzenie to host,port dla czytników sieciowych. użytkownik i hasło to twoje dane logowania. Dla czytników newcamd będziesz również potrzebować linii key= zawierającej klucz DES, do którego przejdę za chwilę, ponieważ sprawia to problemy wielu osobom.

Wybór protokołu: cccam vs. newcamd vs. cs378x vs. mgcamd

cccam to najczęstszy protokół do udostępniania peer-to-peer, ponieważ tak wiele boxów i paneli mówi nim natywnie. newcamd jest starszy, ale nadal szeroko wspierany, i wymaga wymiany klucza DES — zazwyczaj 14-bajtowego klucza hex, a jeśli wkleisz go źle (za krótki, dodatkowa spacja, zła wielkość liter), czytnik często po prostu będzie siedział tam, cicho nie działając, zamiast zgłaszać oczywisty błąd.

cs378x warto znać szczególnie, jeśli łączysz dwa boxy OScam — to w zasadzie camd35 przez TCP z dodanym sprawdzaniem integralności wiadomości, w przeciwieństwie do starszego camd35 opartego na UDP, który nie ma nic. Jeśli oba końce działają na OScam, cs378x lub newcamd mają tendencję do bycia czystsze i o niższym narzucie niż cccam. Wsparcie dla mgcamd istnieje głównie dla zachowania zgodności wstecznej ze starszymi boxami, które mówią tylko wariantami newcamd/cccam — nie ustawisz protocol=mgcamd w samym oscam.server, ponieważ mgcamd jest aplikacją po stronie klienta, a nie protokołem czytnika OScam.

grupa, caid, ident i etykieta trasowania dla czystych ścieżek dekodowania

To jest część, którą prawie każdy przewodnik pomija, i to dokładnie dlatego tak wiele osób kończy z czytnikiem, który łączy się dobrze, ale nigdy nic nie dekoduje. grupa wiąże czytnik z konkretnymi użytkownikami — jeśli twój użytkownik w oscam.user ma grupę = 1, a twój czytnik ma grupę = 1, OScam uznaje ten czytnik za uprawniony do obsługi tego klienta. Brak wspólnego numeru grupy, żaden ECM nigdy nie dotrze do tego czytnika, niezależnie od tego, jak poprawnie skonfigurowane są wszystkie inne elementy.

caid ogranicza, które systemy szyfrowania są zapytane przez czytnik. Jeśli wiesz, że twoje źródło obsługuje tylko Viaccess (0500) i Nagravision (0100), nie zostawiaj caid pustego — ustaw go wyraźnie. ident idzie o poziom głębiej, zawężając do konkretnych identyfikatorów dostawcy w ramach caid, sformatowanych jako pary caid:ident. Agresywne filtrowanie tutaj nie jest tylko schludną konfiguracją — bezpośrednio zmniejsza błędy ECM, ponieważ OScam przestaje marnować cykle pytając czytnik o kanały, na które nigdy nie zamierzał odpowiedzieć.

cccversion, cccmaxhops, cccwantemu wyjaśnione

cccversion musi odpowiadać temu, czego oczekuje peer — 2.3.0 i 2.3.2 to powszechne wersje krążące. Niezgodność z tym często powoduje, że czytnik łączy się pomyślnie, ale zgłasza błędną liczbę kart lub zero udziałów, co wygląda jak problem z uprawnieniami, ale w rzeczywistości jest to niezgodność handshake protokołu. cccmaxhops ogranicza, jak daleko karta może być od źródła i nadal być akceptowana — niższe wartości oznaczają, że jesteś bliżej karty źródłowej, zazwyczaj szybciej i stabilniej. cccwantemu kontroluje, czy chcesz, aby karty emulowane/softcamowe były uwzględnione; pozostaw to na 0, chyba że chcesz, aby te były uwzględnione w twoim strumieniu.

Dostosowanie czytnika zgodnie z najlepszymi praktykami: czasy oczekiwania, pamięć podręczna, zapasowe i skoki

Gdy czytnik się połączy i zdekoduje, następna warstwa to dostosowanie — to tutaj zwykła funkcjonalna konfiguracja staje się rzeczywiście niezawodną konfiguracją najlepszego czytnika OScam, która przetrwa godziny szczytu i skakanie po kanałach bez zacięć.

ecmtimeout / ecmwhitelist i dlaczego 3000ms to punkt wyjścia

ecmtimeout kontroluje, jak długo OScam czeka na odpowiedź czytnika, zanim się podda i spróbuje zapasowego. 3000ms to rozsądny punkt wyjścia dla większości zdalnych źródeł. Ustaw to zbyt nisko, a otrzymasz przedwczesne zapasowe — czytnik miał odpowiedzieć, ale został odcięty, co powoduje niepotrzebne opóźnienia w przełączaniu i marnowanie CPU, gdy OScam próbuje gdzie indziej. Ustaw to zbyt wysoko, a otrzymasz odwrotny problem: widoczne zacięcia na ekranie, podczas gdy OScam cierpliwie czeka na wolnego lub martwego czytnika, zanim w końcu przejdzie na zapasowe.

zapewnienie i fallback_percaid dla redundancji

Czytnik zapasowy jest zapytany tylko po tym, jak główny zawiedzie lub przekroczy czas — nie jest używany do równoważenia obciążenia, to ubezpieczenie. Skonfiguruj to w oscam.user lub za pomocą ustawień zapasowych świadomych lb_mode, i użyj fallback_percaid, gdy chcesz innego zachowania zapasowego dla każdego systemu szyfrowania, zamiast jednego ogólnego czytnika zapasowego dla wszystkiego.

tryby cacheex 1/2/3 i kiedy czytnik powinien pchać vs. ciągnąć

Wymiana pamięci podręcznej jest naprawdę przydatna do przyspieszania powtarzających się dekodowań w sieci boxów, ale to także tam, gdzie widziałem, jak konfiguracje całkowicie się załamują. Tryby: 1 to tylko push, 2 to tylko pull, 3 to push-and-pull w obu kierunkach. Błąd, który ludzie popełniają nieustannie, to ustawienie trybu cacheex 3 na obu końcach relacji peer — to tworzy pętlę, w której każda strona ciągle przesyła te same wpisy pamięci podręcznej tam i z powrotem, zalewając logi i czasami zamrażając cały łańcuch.

Poprawny wzór jest asymetryczny. Jeśli box A jest twoim głównym, a box B chce pamięci podręcznej A, B powinien działać w trybie cacheex 2 (pull) w kierunku A, a A nie powinien jednocześnie być ustawiony na ciągnięcie z B dla tego samego caid/danych. Jeśli nie rozwiązujesz aktywnie konkretnego problemu z opóźnieniem, pozostaw cacheex wyłączone. To nie jest funkcja domyślnie włączona — to ukierunkowana optymalizacja dla specyficznych topologii sieciowych.

lb_weight, lb_force_fallback i globalna strategia równoważenia obciążenia

Balansowanie obciążenia jest konfigurowane globalnie w oscam.conf z lb_mode — tryb 1 wybiera najszybszego czytnika na podstawie zmierzonego czasu odpowiedzi. Ale poszczególni czytnicy mają lb_weight, co wpływa na to, jak często OScam wybiera tego czytnika w porównaniu do innych obsługujących ten sam caid. Jeśli masz dwóch czytników, które są w stanie dekodować ten sam caid i są mniej więcej podobne pod względem prędkości, możesz skończyć z OScam ping-pongującym między nimi, co objawia się jako skrajnie niespójne czasy dekodowania w webif od jednego zapytania do drugiego. Ustawienie wyraźnej różnicy w lb_weight — powiedzmy 100 na preferowanym czytniku i 50 na drugim — mówi OScam, którego rzeczywiście preferować, zamiast traktować je jako równe.

audisabled, aureader i obsługa EMM

audisabled=1 mówi OScam, aby nie przetwarzał aktualizacji EMM przez ten czytnik — co oznacza, że nie będzie próbował pisać pakietów aktualizacji z powrotem na kartę. To ma duże znaczenie w przypadku lokalnych kart fizycznych: jeśli masz wiele czytników w jakiś sposób skierowanych na tę samą fizyczną kartę (niezwykłe, ale zdarza się w niektórych konfiguracjach wieloklienckich), pozwolenie na jednoczesne przetwarzanie zapisów EMM przez więcej niż jeden może rzeczywiście uszkodzić wewnętrzny stan karty. Rozwiązanie jest proste — wybierz jeden czytnik jako pisarza EMM i ustaw audisabled=1 na każdym innym czytniku dotykającym tej samej karty.

Weryfikacja i rozwiązywanie problemów z czytnikiem, który nie dekoduje

Oto kolejność diagnostyczna, której używam za każdym razem, zanim dotknę jakiejkolwiek wartości konfiguracyjnej.

Czytanie oscam.log i strony statusu czytników w webif

Pierwszym przystankiem zawsze jest zakładka Czytniki w webif. Status pokazuje zielony dla połączonego, czerwony dla niepołączonego. Jeśli jest czerwony, to jest to czysto problem warstwy połączenia — nie trać czasu na sprawdzanie filtrów caid. Sprawdź osiągalność hosta/portu, potwierdź, że zapora sieciowa pozwala na wychodzący TCP na tym porcie, zweryfikuj nazwę użytkownika/hasło i potwierdź, że wersja protokołu odpowiada temu, czego oczekuje partner.

Połączony, ale 'KARTA OK' bez dekodowania: niedopasowanie filtra caid/ident

Jeśli status pokazuje połączony i nawet "KARTA OK", ale konkretne kanały nadal nie dekodują, to prawie nigdy nie jest problem z połączeniem. Wróć do swoich linii caid= i ident= i sprawdź, czy przypadkowo nie wykluczyłeś caid, którego używa ten kanał. Podwójnie sprawdź, czy numer grupy rzeczywiście odpowiada między czytnikiem a użytkownikiem żądającym — naprawiłem ten dokładny problem więcej razy, niż mogę policzyć, i zawsze jest to jedna z tych dwóch rzeczy.

'połączony' fluktuacje: niedopasowanie wersji lub hasła/klucza DES

Czytnik, który łączy się, a następnie rozłącza, a następnie ponownie łączy się kilka sekund później — powtarzająco — zazwyczaj wskazuje na niedopasowanie wersji cccversion lub, w przypadku newcamd, źle sformatowany klucz DES. Sprawdź dokładnie długość klucza; powinien mieć dokładnie 14 bajtów szesnastkowych bez zbędnych znaków. Jeśli czytnik pozostaje połączony tylko tuż po restarcie OScam, a następnie szybko się rozłącza, zwróć uwagę na wartości reconnecttimeout i inactivitytimeout — zbyt agresywny timeout zrywa połączenia, które są w rzeczywistości w porządku, tylko chwilowo bezczynne.

Błędy ECM, timeouty ECM i diagnoza 'brak pasującego czytnika'

"Brak pasującego czytnika" w logu oznacza, że OScam nie mógł znaleźć żadnego czytnika w odpowiedniej grupie z odpowiednim zakresem caid/ident dla tego ECM — sprawdź ponownie swoje filtry. Rzeczywisty timeout ECM w logu (w przeciwieństwie do odrzucenia) oznacza, że czytnik był osiągalny i w zakresie, ale nie odpowiedział na czas, co wskazuje na dostrojenie ecmtimeout lub rzeczywistą latencję sieciową do tego źródła.

Bezpieczne używanie loglevel oscam.log i flag debug -d

loglevel w oscam.conf kontroluje szczegółowość — tymczasowo zwiększ go, gdy ścigasz konkretny problem, ale nie zostawiaj logowania na poziomie debugowania na stałe, ponieważ spowoduje to powiększenie plików logów i może zasłonić rzeczywistą linię błędu w hałasie. Użyj flag -d (jak -d 1 dla debugowania klienta, -d 2 dla debugowania czytnika) z linii poleceń na krótki sesji diagnostycznej, a następnie zmniejsz go z powrotem, gdy znajdziesz to, czego szukasz.

Jak ocenić źródło karty ogólnie (bez nazw)

Nie zamierzam mówić, którego dostawcę użyć — to nie jest naprawdę sens dobrego pisania technicznego, a szczerze mówiąc, i tak nie przetrwałoby próby czasu. To, co powiem, to dokładnie to, co należy zmierzyć, abyś mógł ocenić każde źródło samodzielnie, używając tylko swojego OScam webif.

Sygnalizacja stabilnego źródła: spójny czas dekodowania, niski procent błędów ECM

Otwórz stronę statusu Czytników i obserwuj kolumnę średniego czasu dekodowania przez wieczór rzeczywistego użycia, a nie tylko pięciominutowy test. Cokolwiek, co konsekwentnie jest poniżej 300 ms, jest solidne. Jeśli widzisz dzikie wahania — 150 ms w jednym momencie, 2000 ms w następnym — to źródło z niestabilną pojemnością backendu, i objawi się to jako zamarzanie podczas szybkich zmian kanałów, nawet jeśli "działa" w szybkim teście.

Przezroczystość protokołu/wersji i dopasowana cccversion

Dobrze zarządzane źródło mówi ci dokładnie, jaki protokół, port i wersję użyć — nie ma potrzeby zgadywania. Jeśli źródło jest niejasne co do tego, którą cccversion ustawić, lub musisz ciągle próbować i błędów z portem, to już sygnał o tym, jak całe działanie jest prowadzone.

Liczba hopów, głębokość dzielenia i dlaczego mniej hopów dekoduje szybciej

Liczba hopów mówi ci, ile razy karta została ponownie udostępniona, zanim dotarła do ciebie. Hop 1 oznacza, że rozmawiasz z czymś bliskim rzeczywistej karty. Wyższe liczby hopów oznaczają więcej warstw ponownego udostępniania między tobą a źródłem, co zazwyczaj oznacza większą latencję i więcej punktów awarii. To jest naprawdę jedna z bardziej użytecznych, mierzalnych liczb, które masz do dyspozycji, i jest widoczna bezpośrednio w szczegółach czytnika webif.

Czerwone flagi: wymuszone wysokie hopów, niestabilne ponowne połączenia, EMM wyłączone wszędzie

Uważaj na źródła, które wymuszają niezwykle wysokie liczby hopów bez wyjaśnienia, czytniki, które ciągle się łączą bez wyraźnej przyczyny sieciowej z twojej strony, lub konfiguracje, w których obsługa EMM wydaje się całkowicie wyłączona w całym systemie bez żadnej ścieżki aktualizacji karty. Żaden z tych czynników sam w sobie nie dyskwalifikuje, ale razem tworzą obraz, na który warto zwrócić uwagę, zanim poświęcisz czas na rzeczywistą konfigurację.