Znaczenie CCcam: Protokół, Architektura i Jak to Działa

Jeśli przeszukujesz wątki na forach, menu odbiornika Enigma2 lub pliki konfiguracyjne i ciągle widzisz termin "CCcam" bez wyraźnego wyjaśnienia, nie jesteś sam. Znaczenie cccam myli wielu ludzi, ponieważ słowo odnosi się do dwóch nakładających się rzeczy jednocześnie — konkretnego oprogramowania i zastrzeżonego protokołu, który to oprogramowanie wprowadził. Wyjaśnienie tej różnicy przed dotknięciem pliku konfiguracyjnego zaoszczędzi ci wiele godzin rozwiązywania problemów.

Ten artykuł wyjaśnia dokładnie, co to jest CCcam "pod spodem": jak protokół działa, jak wyglądają pliki konfiguracyjne, jak wiąże się to z OScam i co się dzieje, gdy linia pada lub kanał nie odszyfrowuje się.

Co Oznacza CCcam: Definicja i Pochodzenie

CCcam to demon oparty na Linuksie, pierwotnie napisany dla odbiorników satelitarnych DVB. W swej istocie pozwala jednemu urządzeniu z fizyczną kartą inteligentną udostępniać możliwości deszyfrowania tej karty wielu klientom przez połączenie sieciowe TCP. Protokół, który do tego używa, nosi również nazwę CCcam — to jest miejsce, gdzie zaczyna się zamieszanie.

Rozbór Nazwy: Co Oznacza "CCcam"

Nie ma oficjalnego, opublikowanego rozwinięcia nazwy od oryginalnych twórców. Szeroko akceptowana interpretacja to Card Client CAM — gdzie "CC" oznacza Card Client a "CAM" odnosi się do emulacji Conditional Access Module. Ta nomenklatura ma sens funkcjonalny: oprogramowanie emuluje to, co robiłby fizyczny CAM, ale przez sieć.

Niektóre starsze posty na forach sugerują, że "CC" mogłoby oznaczać "CryptoCam" lub odnoszą się do inicjałów oryginalnego autora, ale nic nie zostało oficjalnie potwierdzone. Interpretacja Card Client CAM to ta, która utknęła w społeczności i jest zgodna z tym, jak oprogramowanie faktycznie się zachowuje.

Pochodzenie i Historia Rozwoju Protokołu

CCcam pojawił się w połowie 2000 roku jako alternatywa dla starszych rozwiązań do udostępniania, takich jak Newcamd. Został zaprojektowany specjalnie dla odbiorników DVB opartych na Linuksie — tego typu korzystających z Dreambox i podobnego sprzętu Enigma2. Oprogramowanie przeszło kilka głównych gałęzi wersji: 2.0.x, 2.1.x, 2.2.x i 2.3.x, każda z nich dodająca funkcje takie jak ulepszone filtrowanie CAID, kontrolę reshare i lepsze handshaking protokołu.

Rozwój zatrzymał się gdzieś wokół serii 2.3.x. Ostatnim szeroko rozpowszechnionym plikiem binarnym jest CCcam 2.3.0, który pochodzi sprzed wielu lat. Od tego czasu OScam przejął rolę aktywnie utrzymywanej alternatywy, choć sam protokół CCcam jest nadal intensywnie używany, ponieważ wiele klientów i serwerów zostało wokół niego zbudowanych.

CCcam jako Oprogramowanie vs. CCcam jako Protokół

To jest rozróżnienie, które większość ludzi pomija. Kiedy ktoś mówi "Uruchamiam CCcam," może mieć na myśli faktyczny binarny demon CCcam — oprogramowanie zainstalowane na ich odbiornik lub serwer. Ale kiedy ktoś mówi o "protokole CCcam," ma na myśli zastrzeżony format komunikacji oparty na TCP, który

t oprogramowanie zostało wprowadzone.

Protokół nie jest otwartym standardem. Nie ma RFC, nie ma publicznego dokumentu specyfikacji. To, co wiemy o nim, pochodzi z inżynierii wstecznej i dokumentacji społeczności. OScam był w stanie wdrożyć obsługę protokołu CCcam właśnie dlatego, że społeczność przeprowadziła inżynierię wsteczną wystarczającą części, aby napisać kompatybilną implementację. Te dwie rzeczy — oprogramowanie i protokół — dzielą nazwę, i to jest stałym źródłem zamieszania dla każdego nowego w ekosystemie.

Jak protokół CCcam działa technicznie

Na poziomie sieci CCcam jest protokołem klient-serwer opartym na TCP. Serwer posiada prawdziwą fizyczną kartę inteligentną — albo w module CAM, w gnieździe CI, albo w czytniku kart bezpośrednio podłączonym do sprzętu. Gdy klient musi odszyfrować kanał, wysyła ECM (Entitlement Control Message) do serwera. Serwer przekazuje ten ECM do fizycznej karty, otrzymuje z powrotem odszyfrowany CW (Control Word) i wysyła go z powrotem do klienta. Cała podróż w obie strony musi się odbyć wystarczająco szybko — przed przedziałem rotacji klucza kanału — lub obraz się zamarza.

Architektura klient-serwer: C-linie i N-linie wyjaśnione

Głównym sposobem konfiguracji połączenia klienta CCcam jest C-linia. Format jest prosty:

C: hostname port username password

Więc rzeczywisty wpis wygląda tak:

C: myserver.example.com 12000 myuser mypassword

Ta linia trafia do pliku /etc/CCcam.cfg na twoim odbiornik lub urządzeniu klienta. Mówi ona demonowi CCcam gdzie się połączyć, jakie poświadczenia użyć i niejawnie który port wybrać. Możesz mieć wiele C-linii wskazujących na różne serwery, a CCcam będzie używać pierwszej dostępnej.

N-linie są dla równorzędnych Newcamd — innego, ale powiązanego protokołu. Jeśli łączysz serwer CCcam z serwerem Newcamd, użyj N-linii w konfiguracji. N-linie mają następujący format:

N: hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Ciąg szesnastkowy na końcu to klucz Newcamd DES. Większość osób kopiuje-wkleja to z konfiguracji swojego dostawcy i nie musi tego konstruować ręcznie, ale wiedza, czym to jest, ma znaczenie, gdy połączenie się nie powiedzie.

Rola słów sterujących (CW) w deszyfracji

Control Word to 8-bajtowy klucz, który descrambler twojego odbiornika używa do deszyfrowania strumienia wideo w czasie rzeczywistym. Nadawcy rotują CW co kilka sekund (zazwyczaj co 10 sekund, chociaż niektóre usługi rotują szybciej). Za każdym razem, gdy CW się zmienia, twój klient musi pobrać nowy zanim stary wygaśnie — w przeciwnym razie obraz się zamarza lub zmienia się na czarny.

To dlatego czas odpowiedzi ECM ma takie znaczenie. Jeśli twój serwer zajmuje 800ms na zwrócenie CW a przedział rotacji wynosi 10 sekund, prawdopodobnie będzie w porządku. Ale jeśli czas odpowiedzi wzrośnie do 2000ms lub serwer jest wolny, otrzymujesz zacinanie się tuż przy granicy rotacji klucza. CW i

sam nie jest nigdy przechowywany długoterminowo — jest z założenia efemeryczny.

Port TCP 12000: Domyślny port komunikacji CCcam

CCcam nasłuchuje na porcie TCP 12000 w celu odebrania przychodzących połączeń klientów. Jest to ustawiane w /etc/CCcam.cfg za pomocą dyrektywy PORT:

PORT 12000

Jeśli twój dostawca internetu blokuje port 12000 — co niektórzy robią, szczególnie w regionach, gdzie udostępnianie satelitarne jest aktywnie ograniczane — możesz przenieść go na inny dostępny port. Porty takie jak 8080, 4444, a nawet 443 są czasami używane do obejścia filtrowania. Upewnij się tylko, że twoja linia C po stronie klienta używa pasującego numeru portu.

Interfejs informacji sieciowej działa oddzielnie na porcie 16001 domyślnie. Uzyskujesz do niego dostęp pod adresem http://adresservera:16001 i pokazuje on podłączonych klientów, listy udostępniania, czasy odpowiedzi ECM i obecny stan karty. To jest twoje główne narzędzie diagnostyczne — jeśli coś jest nie tak, ta strona zwykle ci to powie.

Liczba przeskoków i odległość udostępniania w sieciach CCcam

Liczba przeskoków jest jedną z najważniejszych i najmniej wyjaśnianych koncepcji w sieciach CCcam. Gdy serwer CCcam udostępnia swoją kartę klientowi, klient ten potencjalnie może ją ponownie udostępnić innemu klientowi — dodając jeden przeskok każdorazowo. Liczba przeskoków 0 oznacza, że jesteś bezpośrednio podłączony do karty fizycznej. Liczba przeskoków 1 oznacza, że między tobą a kartą znajduje się jeden serwer. Liczba przeskoków 2 oznacza dwóch pośrednich serwerów.

Każdy przeskok dodaje opóźnienie do odpowiedzi ECM. W dobrze skonfigurowanej sieci z szybkimi serwerami nawet przeskok 2 może być akceptowalny. Ale w praktyce wszystko poza przeskokiem 3 ma tendencję do powodowania niestabilnego deszyfrowania. Operatorzy serwerów kontrolują to za pomocą dyrektywy RESHARE — ustawienie RESHARE 1 oznacza, że klienci mogą ponownie udostępnić do 1 przeskoku od karty i tak dalej.

Różnice między CCcam a protokołami Newcamd i CS378x

Newcamd jest starszym protokołem udostępniania kart, który poprzedza CCcam. Używa portu 14000 domyślnie, używa linii N do konfiguracji i używa uścisku opartego na DES do uwierzytelniania. Nie obsługuje natywnie modelu udostępniania opartego na przeskokach, który wprowadził CCcam.

CS378x to nazwa modułu protokołu używana przez OScam do emulacji funkcjonalności serwera CCcam. Gdy włączysz [cs378x] w konfiguracji OScam, mówisz OScam, aby mówiła protokołem CCcam do przychodzących połączeń klientów. Z perspektywy klienta wygląda to jak natywny serwer CCcam. Nazwa „cs378x" pochodzi z konwencji nazewnictwa modułów wewnętrznych OScam — nie ma nic wspólnego z innym protokołem przewodowym. To JEST protokół CCcam, zaimplementowany w OScam.

Pliki konfiguracji CCcam i kluczowe parametry

Na większości systemów Linux opartych na DVB z systemem Enigma2 — Dreambox, VU+, Zgemma i podobny sprzęt — demon CCcam odczytuje swoją konfigurację z /etc/CCcam.cfg. Plik jest zwykłym tekstem, zależnym od wielkości liter w większości dyrektyw, i będzie po cichu ignorować linie, których nie potrafi przeanalizować. Ten ostatni punkt powoduje prawdziwe problemy.

CCcam.cfg

Lokalizacja i struktura plików

Domyślna ścieżka to /etc/CCcam.cfg. Niektóre obrazy Enigma2 umieszczają ją w innym miejscu — sprawdź /var/etc/CCcam.cfg, jeśli domyślna nie istnieje. Plik dziennika zwykle trafia do /tmp/CCcam.log na systemach wbudowanych, gdzie /tmp znajduje się w pamięci RAM, lub do /var/log/CCcam.log na systemach z bardziej trwałą pamięcią.

Jedna pułapka, która zmarnuje wiele czasu: jeśli edytujesz CCcam.cfg na maszynie z systemem Windows i przenosisz go na odbiornik Linux, zakończenia linii Windows (CRLF — carriage return + line feed) spowodują, że CCcam nie będzie w stanie prawidłowo analizować dyrektyw. Rozwiązaniem jest uruchomienie dos2unix /etc/CCcam.cfg po przesłaniu lub bezpośrednia edycja pliku na odbiorniku za pośrednictwem SSH.

Dyrektywy SERVER, SHARE i CLIENT

Oto minimalnie funkcjonujący plik CCcam.cfg pokazujący kluczowe dyrektywy:

# Port nasłuchu dla przychodzących połączeń klientów
PORT 12000
# Port strony informacyjnej HTTP
HTTPPORT 16001
# Wychodzące połączenie do serwera upstream
C: upstream.example.com 12000 myuser mypassword
# Zdefiniuj lokalnego klienta uprawnionego do połączenia
CLIENT 192.168.1.50 clientuser clientpassword
# Poziom ponownego udostępniania (ile przeskoków mogą przepowiadać klienci)
RESHARE 1
# Poziom dziennika
LOGLEVEL 5

Powszechny bałagan: ludzie mylą linie C: (wychodzące połączenia do serwera, którego klientem jesteś) z liniami CLIENT (przychodzące połączenia od użytkowników, którzy są twoimi klientami). Robią one coś przeciwnego. Linia C: mówi „połącz mnie z tym serwerem upstream". Linia CLIENT mówi „pozwól temu użytkownikowi na połączenie ze mną jako klient".

Zrozumienie filtrowania SID, CAID i identyfikatora dostawcy

CCcam umożliwia filtrowanie na wielu poziomach. CAID (Conditional Access ID) identyfikuje system szyfrowania — na przykład Nagravision używa CAID 0x1800, Viaccess używa 0x0500, Irdeto używa 0x0600. SID to identyfikator usługi dla określonych kanałów. Identyfikator dostawcy to podidentyfikator w systemie CA.

Możesz dodać filtrowanie CAID do linii CLIENT, aby ograniczyć, które kanały może rozszyfrować dany klient. Jest to przydatne, jeśli uruchamiasz wieloużytkownikową konfigurację i chcesz ograniczyć dostęp do określonych pakietów. Składnia różni się nieznacznie w zależności od wersji CCcam — sprawdź komentarze w przykładowej konfiguracji twojej konkretnej wersji.

Ścieżki plików dziennika i wyjście debugowania

Ustaw LOGLEVEL 8, aby uzyskać pełne dane wyjściowe podczas rozwiązywania problemów. Dziennik będzie pokazywać próby połączenia, wyniki żądań ECM i komunikaty o błędach, takie jak „karta nie znaleziona" lub „niedozwolone" — wskazują one bezpośrednio na przyczynę niepowodzenia. Gdy wszystko działa, zmniejsz to do LOGLEVEL 5 lub niżej, aby uniknąć zapełniania pamięci RAM lub dysku.

Na pudełkach Enigma2 dziennik często trafia do /tmp/CCcam.log. Śledź go na żywo za pomocą: tail -f /tmp/CCcam.log

CCcam vs OScam: kiedy używać każdego

Rozwój CCcam zatrzymał się wiele lat temu. Ostatnia szeroko wdrażana

```html wersja (2.3.0) przez długi czas nie otrzymywała aktualizacji, a nie ma aktywnego zespołu deweloperskiego go utrzymującego. OScam natomiast jest aktywnie utrzymywany z regularnymi zatwierdżeniami, szerszą obsługą sprzętu i znacznie bardziej elastycznym systemem konfiguracji. W większości nowoczesnych konfiguracji OScam jest lepszym wyborem po stronie serwera.

Dlaczego OScam zastąpił CCcam w większości nowoczesnych konfiguracji

OScam działa na tym samym sprzęcie Enigma2, obsługuje znacznie więcej typów czytników, obsługuje wiele protokołów jednocześnie i ma odpowiedni interfejs internetowy na porcie 8888 domyślnie. Obsługuje również funkcje anti-cascading, szczegółowe logowanie ECM i szczegółowe zarządzanie użytkownikami, których statyczny plik konfiguracyjny CCcam nie może dorównać. Na wszystkim zbudowanym w ciągu ostatnich kilku lat, niewiele powodów, aby uruchamiać natywne oprogramowanie serwera CCcam.

Ale — i to jest kluczowy punkt — protokół CCcam nie jest martwy. Wiele klientów nadal mówi tylko CCcam. Twój stary Dreambox, tani odbiornik Android, konfiguracja znajomego wciąż korzystająca z firmware'u z 2010 roku — mogą obsługiwać tylko połączenia C-line. Dlatego nawet podczas uruchamiania OScam jako serwera, możesz potrzebować zaakceptowania połączeń protokołu CCcam.

Tryb emulacji CCcam OScam (cs378x i czytnik protokołu cccam)

OScam obsługuje CCcam w dwóch kierunkach. Po pierwsze, jako serwer: włącz sekcję [cs378x] w /etc/oscam/oscam.conf:

[cs378x]
port = 12000
version = 2.3.0
reshare = 1

To powoduje, że OScam akceptuje przychodzące połączenia klienta CCcam na porcie 12000, mówiąc natywnym protokołem CCcam. Z perspektywy łączącego się klienta, jest nie do odróżnienia od rzeczywistego serwera CCcam.

Po drugie, jako czytnik klienta: jeśli twoje pole OScam musi się połączyć z upstream'owym serwerem CCcam, dodaj czytnik w /etc/oscam/oscam.server:

[reader]
label = upstream_cccam
protocol = cccam
device = upstream.example.com,12000
user = myuser
password = mypassword
caid = 1800

Jedna rzecz, która łapie ludzi: jeśli OScam został skompilowany bez modułu cs378x, otrzymasz connection refused na porcie 12000 nawet z poprawną konfiguracją. Sprawdź, czy twoja kompilacja OScam zawiera cs378x, uruchamiając oscam --build-info lub równoważną dla twojego obrazu. To jest częsty problem na niektórych obrazach Enigma2, które zawierają okrojone kompilacje OScam.

Scenariusze, w których natywne oprogramowanie CCcam jest wciąż używane

Natywny CCcam pojawia się w kilku sytuacjach. Niektóre starsze pola Dreambox i obrazy go uruchamiają, ponieważ konfiguracja jest prostsza dla podstawowych konfiguracji. Niektórzy użytkownicy mają istniejące konfiguracje, których nie chcą migrować. A w niektórych przypadkach, bardzo prosty serwer z jedną kartą z kilkoma klientami jest faktycznie łatwiejszy w zarządzaniu za pomocą płaskiego pliku konfiguracyjnego CCcam niż wieloplikowe setup'u OScam.

Interoperacyjność: łączenie klientów CCcam z serwerami OScam

Za pomocą aktywnego modułu cs378x OScam standardowy klient CCcam używający C-line łączy się bez żadnych modyfikacji. Handshake jest kompatybilny. O ```ne rzecz na którą warto zwrócić uwagę: parametr version w sekcji OScama [cs378x]. Ustawienie go na 2.3.0 zapewnia kompatybilność z klientami, które sprawdzają wersję serwera podczas uzgadniania. Niektóre starsze wersje klienta CCcam są wybredne w tym względzie — jeśli widzisz błędy uzgadniania pomimo poprawnych poświadczeń, spróbuj dopasować ciąg wersji do tego, czego oczekuje klient.

Podobnie, jeśli używasz mieszanego zestawu — natywny CCcam na jednym urządzeniu, OScam na innym — i muszą one udostępniać karty między sobą, użyj czytelnika protocol = cccam w pliku oscam.server w OScamie, aby połączyć się z pudełkiem CCcam. Adresy IPv6 w liniach C warto tutaj odnotować: starsze wersje CCcam (przed 2.2.x) w ogóle nie obsługują adresów IPv6 w liniach C. Jeśli twój serwer ma adres tylko IPv6, ci starzy klienci nie będą w stanie się połączyć, niezależnie od poświadczeń.

Powszechne Nieporozumienia na Temat CCcam

Wiele zamieszania wokół znaczenia cccam pochodzi z tego, jak ten termin jest używany komercyjnie. Ludzie sprzedają „linie CCcam" lub „subskrypcje CCcam" i słowo zaczyna brzmieć jak kategoria produktu, a nie protokół techniczny. Warto rozpakować, co faktycznie jest opisywane w tych kontekstach.

CCcam Nie Jest Usługą Subskrypcyjną

CCcam to protokół i demon oprogramowania. To, co sprzedaje się jako „subskrypcja CCcam", to poświadczenia dostępu do serwera — nazwa użytkownika i hasło dla linii C, która łączy cię z serwerem udostępniania kart kogoś innego. Rzecz, którą kupujesz, to dostęp do usługi działającej na ich sprzęcie. CCcam sam w sobie to po prostu protokół komunikacyjny, z którym te poświadczenia są używane. Łączenie tych dwóch rzeczy jest jak mylenie SSH z serwerem, na który się loguje.

Darmowe Linie CCcam a Linie Płatne: Czym Się Faktycznie Różnią

Różnica techniczna zwykle sprowadza się do jakości serwera, a nie różnic w protokołach. Darmowe linie zwykle pochodzą z przeciążonych serwerów o wysokiej liczbie przeskoków, niespójnym uptime'ie i bez gwarancji pokrycia CAID. Linie płatne — jeśli dostawca posiada przyzwoitą infrastrukturę — powinny oznaczać niższe liczby przeskoków (najlepiej 0 lub 1 od fizycznej karty), szybsze czasy odpowiedzi ECM i bardziej stabilny uptime.

Ale podstawowy format linii C i protokół CCcam są identyczne. Darmowa linia C i płatna linia C wyglądają dokładnie tak samo w twoim pliku konfiguracyjnym. Różnica jest czysto po stronie serwera — jakość.

Dlaczego Linie CCcam Wygasają Lub Przestają Działać

Linie ulegają awarii z konkretnych, diagnozowalnych powodów. Dziennik w /tmp/CCcam.log zwykle powie ci, który to:

• Błędne poświadczenia — nazwa użytkownika lub hasło zmieniło się na serwerze
• Ograniczenie IP — serwer ma na białej liście określone adresy IP, twój adres IP się zmienił (częste w przypadku CGNAT lub dynamicznych adresów IP)
• CAID niedostępny — karta, z którą łączy się twój serwer, nie ma uprawnień do tego, czego żądasz
• Limit przeskoków przekroczony — ustawienie RESHARE serwera nie pozwala na twoją pozycję

```html w łańcuchu

Serwer offline — serwer upstream jest całkowicie wyłączony

Subskrypcja wygasła — operator serwera usunął Twoje konto

Warte wspomnienia zagadnienie związane z NAT: jeśli znajdujesz się za CGNAT (Carrier-Grade NAT), adres IP, który serwer widzi podczas połączenia, może być współdzielonym adresem NAT Twojego ISP zamiast czegoś, co rozpoznajesz. Jeśli serwer uwierzytelnia się po adresie IP, możesz otrzymać błędy uwierzytelniania, które wyglądają jak błędne hasła, ale w rzeczywistości są niedopasowaniami IP. Sprawdź, jaki zewnętrzny adres IP prezentujesz, używając narzędzia takiego jak curl ifconfig.me i porównaj go z tym, którego oczekuje serwer.

CCcam nie jest tym samym co usługa IPTV

CCcam udostępnia klucze deszyfrowania sygnałów DVB satelitarnych. Twój odbiornik nadal strojej na rzeczywisty transpondę satelitarny i odbiera strumień transmisji przez RF — CCcam po prostu dostarcza deszyfrowanie CW, aby descrambler Twojego odbiornika mógł go zdekodować. IPTV to całkowicie inny model, w którym sam strumień wideo jest dostarczany przez IP. Te dwa systemy są technicznie odrębne, używają różnych ścieżek sprzętowych i mają różne tryby awarii. Mylenie ich prowadzi do błędnych podejść do rozwiązywania problemów.

Na co zwracać uwagę przy ocenie serwera CCcam

Omijaj każdy serwer, na którym nie możesz uzyskać linii testowej przed zapłaceniem czegokolwiek. To jest minimum. Wszystko inne jest drugorzędne w stosunku do rzeczywistego testowania wydajności z Twoją konkretną konfiguracją i konkretnymi wymaganiami kanałów.

Testy opóźnienia i czasu odpowiedzi ECM

Czas odpowiedzi ECM poniżej 200ms to doskonałe wyniki. Poniżej 500ms jest akceptowalne dla większości kanałów. Powyżej 500ms zaczniesz widzieć okazjonalne zacinanie się, szczególnie na kanałach o szybkiej rotacji CW. Powyżej 1000ms konsekwentnie, usługa jest bezwartościowa — nie płać za nią.

Możesz sprawdzić czas odpowiedzi ECM za pośrednictwem strony informacyjnej CCcam na http://serverip:16001. Poszukaj sekcji "ECMs", która pokazuje czasy odpowiedzi dla każdego CAID. Na serwerach OScam, interfejs webowy na porcie 8888 zawiera równoważne informacje w sekcji czytelników. Jeśli dostawca nie da Ci dostępu do interfejsu webowego lub jakikolwiek sposób sprawdzenia tego, to jest czerwona flaga.

Obsługiwane CAID i zasięg dostawcy

Poproś o listę CAID serwera lub ją sprawdź przed zaangażowaniem się. Różne systemy szyfrowania mają różne CAID, a nie każda karta serwera ma uprawnienia dla każdego pakietu. Serwer może wymieniać rozległy zasięg kanałów, ale mieć tylko jedną lub dwie karty, każdą z konkretnymi uprawnieniami. Strona informacyjna CCcam na porcie 16001 pokazuje listę CAID w sekcji udziałów — sprawdź, czy odpowiada temu, czego potrzebujesz.

Głębokość ponownego udostępniania i limity liczby przeskoków

Na stronie informacyjnej CCcam, liczba przeskoków 0 obok udziału oznacza bezpośredni dostęp do karty na tym serwerze. To idealne. Hop 1 jest w porządku. Jeśli strona informacyjna pokazuje Twoje udziały CAID na hop 3 lub wyżej, spodziewaj się problemów z opóźnieniami. Niektóre serwery reklamują bezpośredni dostęp do karty, ale w rzeczywistości ponownie udostępniają z innego miejsca — strona informacyjna m ```akes this visible.

Jeśli widzisz RESHARE 0 w konfiguracji serwera (czasami widoczne w informacjach udostępniania), oznacza to, że serwer nie pozwoli ci na ponowne udostępnienie tego, co otrzymasz. To polityka po stronie serwera, którą nie możesz zastąpić z klienta.

Wskaźniki stabilności serwera do sprawdzenia

Testuj w godzinach szczytu — zwykle wieczorem w regionie serwera. Serwer, który działa dobrze o 2:00, może być całkowicie przeciążony o 20:00. Sprawdź liczbę podłączonych klientów na stronie informacyjnej, jeśli jest dostępna: serwer z 500 klientami i jedną kartą nie będzie działać dobrze pod obciążeniem.

Spójność czasu pracy jest ważniejsza niż surowa szybkość. Serwer z czasem ECM 180ms, który rozłącza się dwa razy dziennie, jest gorszy niż serwer 400ms, który pracuje bez przerwy przez tygodnie. Uruchom swoją linię próbną przez co najmniej 48-72 godziny w różnych porach dnia, zanim wyciągniesz wnioski.

ble the [cs378x] section in /etc/oscam/oscam.conf with the port set to 12000 (or your chosen port). Note that cs378x must be compiled into your OScam build — some stripped-down images omit it.