Serwer CCcam na Linuksie: Pełny przewodnik konfiguracji i instalacji

Konfiguracja serwera CCAM na komputerze z systemem Linux od podstaw to jedno z tych zadań, które wydają się proste, dopóki nie pojawi się pierwszy błąd zgodności binarnej o godzinie 23:00. Ten przewodnik obejmuje pełną ścieżkę: decyzje dotyczące architektury, instalację binarną, składnię pliku konfiguracyjnego, reguły zapory sieciowej i co robić w przypadku awarii. Jeśli masz kartę inteligentną i gotowy komputer z systemem Linux, oto dokładnie to, co musisz wiedzieć.

Co właściwie robi CCcam w systemie Linux (i kiedy potrzebujesz serwera)

CCcam to demon współdzielenia kart. Działa na jednym komputerze z podłączonym fizycznym czytnikiem kart inteligentnych – to serwer. Inne urządzenia w sieci (lub przez internet) łączą się z nim i żądają odszyfrowania ECM dla kanałów, które próbują oglądać. Serwer odszyfrowuje za pomocą fizycznej karty i odsyła słowo kontrolne do klienta. Wszystko to odbywa się przez protokół TCP, domyślny port 12000.

Architektura ma znaczenie, ponieważ determinuje konfigurację. Serwer ma kartę podłączoną lokalnie i udostępnia linie F dla klientów przychodzących. Klient łączy się wychodząco za pomocą linii C. Wiele osób jest zdezorientowanych, ponieważ CCcam działa po obu stronach — to ten sam kod binarny, tylko inaczej skonfigurowany.

Tryb klienta kontra tryb serwera: jakie zmiany w konfiguracji

Nie ma osobnej flagi „trybu serwera”. Różnica polega wyłącznie na tym, które linie pojawiają się w CCcam.cfg . Jeśli masz linie F (definiujące użytkowników, którzy się z Tobą łączą) i linię DEVICE wskazującą na lokalny czytnik, jesteś serwerem. Jeśli masz tylko linie C (wskazujące na inny host), jesteś klientem. Możesz również pełnić obie funkcje jednocześnie — łącząc się z serwerem nadrzędnym i obsługując klientów podrzędnych — tak właśnie działają kaskady.

Dlaczego Linux jest preferowanym systemem operacyjnym dla CCcam

Głównym powodem jest niezawodność. Komputer z systemem Linux, na którym działa CCcam jako usługa systemd, automatycznie uruchomi się ponownie po awarii i przetrwa restart bez interwencji. System Windows nie posiada infrastruktury demonów, która by to umożliwiała. Ponadto większość odbiorników satelitarnych opartych na architekturze ARM, z których ludzie korzystają – Dreambox, VU+, Zgemma – korzysta z systemu Enigma2, czyli Linuksa. Zatem ścieżki binarne, skrypty inicjujące i konfiguracyjne są takie same na wszystkich platformach.

Wymagania sprzętowe: procesor, pamięć RAM i obsługa fizycznego czytnika kart inteligentnych

CCcam nie jest zasobożerny. Procesor 500 MHz i 64 MB pamięci RAM w zupełności wystarczą dla garstki klientów. Każdy nowoczesny komputer z Linuksem jest zdecydowanie przewymiarowany. Prawdziwym ograniczeniem jest czytnik kart inteligentnych: potrzebny jest albo czytnik wewnętrzny (typowy dla sprzętu Dreambox), albo zewnętrzny czytnik USB rozpoznawany przez jądro. Typowe opcje to sc8in1, czytniki w stylu phoenixrc oraz standardowe czytniki USB zgodne z CCID. Po podłączeniu uruchom polecenie dmesg | grep tty , aby upewnić się, że się pojawił — w zależności od chipsetu będzie widoczny jako /dev/ttyUSB0 , /dev/ttyACM0 lub podobnie.

Instalowanie CCcam w systemie Linux: pliki binarne, zależności i pierwsze uruchomienie

CCcam 2.3.0 to ostatnia wersja, jaka kiedykolwiek była szeroko rozpowszechniona. Jest to oprogramowanie o zamkniętym kodzie źródłowym, nigdy nieaktualizowane, a pierwotni twórcy dawno odeszli. To, co masz, to statyczny lub półstatyczny plik binarny – a na współczesnym 64-bitowym serwerze Debian lub Ubuntu, natychmiast powoduje to problemy, ponieważ jest to 32-bitowy plik binarny ELF.

Wybór właściwego pliku binarnego CCcam dla Twojej architektury

Uruchom file CCcam na dowolnym pliku binarnym, który posiadasz. Zobaczysz coś w stylu ELF 32-bit LSB executable, ARM, EABI5 lub ELF 32-bit LSB executable, Intel 80386 Dopasuj plik binarny do swojego sprzętu. Pliki binarne ARM dla odbiorników ARM. Pliki binarne x86 32-bit dla serwerów PC. Jeśli korzystasz z 64-bitowej maszyny x86, potrzebujesz pliku binarnego x86 32-bit oraz warstwy zgodności — a nie kompilacji ARM, nawet jeśli ARM jest w jakiś sposób dostępny.

Instalowanie zależności bibliotek 32-bitowych w systemie Debian/Ubuntu

W nowym 64-bitowym systemie Debian 11/12 lub Ubuntu 22.04 32-bitowe środowisko uruchomieniowe nie jest instalowane domyślnie. Najpierw należy to naprawić:

 dpkg --add-architecture i386 apt-get update apt-get install libc6-i386 lib32gcc-s1

W starszych wersjach Ubuntu (przed 20.04) w starych przewodnikach mogą pojawiać się odniesienia do ia32-libs — ten pakiet zniknął. Zamiast tego użyj libc6-i386 . Po instalacji zweryfikuj za pomocą ldd CCcam , aby sprawdzić, czy wszystkie biblioteki współdzielone są obsługiwane. Jeśli korzystasz z kontenera Docker, który jest 64-bitowy i nie obsługuje architektury wieloarchitekturowej, całkowicie pomiń CCcam i przejdź bezpośrednio do OScam (opisanego w sekcji 6).

Umieszczanie pliku binarnego i ustawianie uprawnień wykonywalnych

 cp CCcam /usr/local/bin/CCcam chmod +x /usr/local/bin/CCcam chown root:root /usr/local/bin/CCcam

W obrazach odbiornika Enigma2 plik binarny zazwyczaj znajduje się w katalogu /usr/bin/CCcam i jest uruchamiany przez skrypt init.d. Nie należy go przenosić w tych systemach — ich skrypty init oczekują go w tej ścieżce.

Uruchamianie CCcam jako usługi systemd w celu automatycznego ponownego uruchomienia

Utwórz plik /etc/systemd/system/cccam.service z następującą zawartością:

 [Unit] Description=CCcam Card Server After=network.target [Service] ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/bin/CCcam Restart=on-failure RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

Parametr ExecStartPre=/bin/sleep 10 nie jest opcjonalny, jeśli czytnik kart inteligentnych potrzebuje chwili na inicjalizację po uruchomieniu. Bez niego CCcam uruchamia się, zanim jądro zakończy konfigurację czytnika USB, i loguje komunikat „brak karty” — a następnie nie podejmuje żadnych prawidłowych prób.

 systemctl daemon-reload systemctl enable cccam systemctl start cccam

Sprawdzanie, czy proces nasłuchuje na porcie 12000

 ss -tlnp | grep 12000 # or netstat -tlnp | grep CCcam

Powinieneś zobaczyć CCcam powiązany z 0.0.0.0:12000 lub konkretnym adresem IP interfejsu. Jeśli nic się nie wyświetla, sprawdź polecenie journalctl -u cccam -n 50 pod kątem błędów uruchamiania.

Szczegółowa analiza CCcam.cfg: wszystkie dyrektywy, które musisz znać

Plik konfiguracyjny domyślnie znajduje się w katalogu /etc/CCcam.cfg . CCcam sprawdza go najpierw. Niektóre skrypty startowe przekazują ścieżkę jako argument — sprawdź swoją, jeśli zmiany nie są wykrywane. Jedna rzecz, która ciągle gryzie ludzi: znaki CRLF (końcowe wiersze w systemie Windows) w pliku konfiguracyjnym powodują ciche błędy analizy w systemie Linux. Jeśli edytowałeś ten plik w systemie Windows i przeniosłeś go z powrotem, uruchom polecenie dos2unix /etc/CCcam.cfg przed debugowaniem czegokolwiek innego.

Komentarze używają znaku # lub // — oba działają. Dyrektywy nie uwzględniają wielkości liter w samym słowie kluczowym, ale wartości (nazwy użytkowników, hasła, nazwy hostów) uwzględniają wielkość liter.

Port serwera i adres nasłuchiwania: dyrektywy SERVERPORT i BIND

 # Listen for incoming CCcam client connections SERVERPORT: 12000 # Bind to a specific interface (recommended) # BIND: 10.8.0.1

Jeśli masz wiele interfejsów sieciowych — na przykład interfejs WAN i interfejs VPN — CCcam domyślnie połączy się ze wszystkimi (0.0.0.0). To problem bezpieczeństwa. Użyj dyrektywy BIND, aby zablokować go tylko dla adresu IP interfejsu VPN. Więcej informacji na ten temat znajdziesz w sekcji dotyczącej zapory sieciowej.

Definiowanie lokalnych czytników kart: linie DEVICE, CARDTYPE i BOXKEY

 # Define the physical smartcard reader DEVICE: /dev/ttyUSB0 SR CARDTYPE: 0 BOXKEY: 00 00 00 00 00 00 00 00

Ścieżka DEVICE musi być zgodna z tą wskazywaną przez dmesg . Jeśli czytnik wyświetla się jako /dev/ttyACM0 zamiast /dev/ttyUSB0 , konfiguracja musi zawierać /dev/ttyACM0 . Nieprawidłowe odczytanie tego parametru jest jedną z najczęstszych przyczyn błędów „brak karty”. Parametr CARDTYPE 0 oznacza automatyczne wykrywanie, co działa w przypadku większości kart. Parametr BOXKEY ma zastosowanie w przypadku kart Nagravision z kluczem BOXKEY — jeśli Twoja karta go nie obsługuje, pozostaw go zerowym.

Dodawanie klientów C-line: C: Podział składni

Linia C informuje ten serwer o konieczności połączenia się z innym serwerem CCcam:

 C: remote.host.example 12000 myusername mypassword {0:0:1} 01

Rozkładając to na czynniki: remote.host.example to nazwa hosta lub adres IP serwera nadrzędnego. 12000 to port. myusername i mypassword to Twoje dane uwierzytelniające na tym serwerze. {0:0:1} to opcjonalny filtr CAID w formacie {CAID:ProviderID:1} — wartość 0:0:1 oznacza akceptację wszystkich CAID. Końcowe 01 to liczba przeskoków dla kart udostępnianych ponownie otrzymanych z tego wiersza.

Dodawanie użytkowników linii F (połączenia przychodzące): F: składnia i ograniczenia przeskoków

Linie F określają, kto ma prawo połączyć się z Twoim serwerem:

 F: client1 strongpassword 1 0 0 0 { 1830:000000:1 } F: client2 anotherpass 1 0 0 0 { 0:0:1 }

Pola po haśle to: poziom ponownego udostępniania (1 = można ponownie udostępnić jeden przeskok), minimalny przeskok karty (0 = karty lokalne), grupa CAID, grupa identyfikatorów oraz opcjonalny blok filtra CAID. Filtr { 1830:000000:1 } ogranicza tego użytkownika tylko do CAID 0x1830. Używaj silnych, unikalnych haseł dla każdej linii F — to są dane uwierzytelniające, które Twoi klienci podają na swoich liniach C.

Linia B do blokowania określonych identyfikatorów dostawców

 B: 1234 000000

Linie B blokują udostępnianie konkretnej kombinacji CAID/dostawcy. Jeśli masz kartę u wielu dostawców i chcesz zablokować jedną z nich, wykonaj następujące czynności. Format to B: CAID ProviderID .

LIMIT UDOSTĘPNIANIA I LICZBA PRZESKOKÓW: kontrolowanie głębokości udostępniania

HOP COUNT kontroluje, ile razy można udostępnić kartę, zanim CCcam przestanie ją udostępniać. Ustaw w wierszach F (dla każdego użytkownika) lub globalnie:

 SHARE LIMIT: 3

Wartość parametru HOP COUNT równa 0 oznacza, że karta jest lokalna i w ogóle nie będzie udostępniana. Wartość 1 oznacza, że karta może zostać przesłana do klientów w jednym przeskoku, ale klienci nie mogą jej udostępniać. Utrzymuj tę wartość na najniższym możliwym poziomie — głębokie łańcuchy udostępniania spowalniają czas reakcji ECM i stwarzają problemy z rozliczalnością.

Dyrektywy LOG i DEBUG do rozwiązywania problemów

 LOGFILE: /var/log/cccam.log LOGLEVEL: 1 DEBUG: 0

LOGLEVEL 1 wyświetla zdarzenia połączeń i aktywność ECM bez obciążania dysku. Ustaw DEBUG tymczasowo na 1 podczas śledzenia konkretnego problemu — jest on rozwlekły i warto go wyłączyć. Interfejs internetowy na porcie 16001 (domyślne dane logowania: admin/admin — zmień je natychmiast) pokazuje aktualny stan karty, podłączonych klientów i czas ECM, co jest znacznie łatwiejsze do odczytania niż surowe logi podczas diagnostyki.

Zapora sieciowa, sieć i przekierowanie portów dla CCcam

To właśnie tutaj najczęściej zacina się konfiguracja serwera CCAM w systemie Linux. Usługa działa, konfiguracja wygląda poprawnie, ale klienci nie mogą się połączyć. W dziewięciu przypadkach na dziesięć przyczyną jest reguła zapory sieciowej lub problem z NAT.

Otwieranie portu TCP 12000 za pomocą iptables i ufw

Bezpośrednie użycie iptables:

 iptables -A INPUT -p tcp --dport 12000 -j ACCEPT # Save rules so they survive reboot: iptables-save > /etc/iptables/rules.v4

Lub jeśli używasz ufw:

 ufw allow 12000/tcp ufw reload

Jeśli chcesz ograniczyć się tylko do znanych adresów IP klientów (znacznie lepsza praktyka):

 iptables -A INPUT -p tcp --dport 12000 -s 203.0.113.45 -j ACCEPT iptables -A INPUT -p tcp --dport 12000 -j DROP

Powiązanie CCcam ze specyficznym interfejsem w celu uniknięcia narażenia

Jeśli Twój serwer ma interfejs publiczny (eth0) i interfejs VPN (wg0 lub tun0), nie pozostawiaj CCcam nasłuchującego na obu. Dodaj dyrektywę BIND w pliku CCcam.cfg z adresem IP interfejsu prywatnego/VPN. Klienci łączą się przez VPN, a port 12000 nigdy nie jest widoczny w publicznym internecie. To jest właściwy sposób.

Korzystanie z tunelu VPN (WireGuard/OpenVPN) zamiast publicznego udostępniania portu 12000

WireGuard to obecnie lepszy wybór — mniejsze obciążenie niż OpenVPN, prostsza konfiguracja, a moduł jądra jest teraz w głównej linii od Linuksa 5.6. Skonfiguruj peera WireGuard między serwerem a każdym klientem, przypisz im adresy w prywatnej podsieci (np. 10.8.0.0/24), powiąż CCcam z 10.8.0.1 i umieść ten adres w liniach C po stronie klienta. Nikt, kto przeszukuje internet, nigdy nie zobaczy portu 12000.

NAT i przekierowanie portów, jeśli serwer znajduje się za routerem domowym

Jeśli Twój komputer z systemem Linux znajduje się w sieci domowej, musisz przekierować port TCP 12000 na routerze na lokalny adres IP serwera. Większość routerów nazywa to „przekierowywaniem portów” lub „serwerem wirtualnym”. Ustaw port zewnętrzny na 12000, protokół TCP, wewnętrzny adres IP na adres LAN serwera (ustaw go jako statyczny, poprzez rezerwację DHCP lub konfigurację ręczną), a wewnętrzny port 12000. Wtedy klienci będą używać Twojego publicznego adresu IP na swoich liniach C.

Jeden z głównych problemów: jeśli Twój dostawca internetu korzysta z CGNAT (NAT klasy operatorskiej), tak naprawdę nie masz publicznego adresu IP – dzielisz go z dziesiątkami innych klientów i nie masz możliwości przekierowywania połączeń przychodzących. Rozwiązaniem jest wynajęcie taniego serwera VPS, uruchomienie na nim WireGuard i tunelowanie ruchu CCcam przez ten serwer. Serwer VPS staje się publicznym punktem końcowym; Twój serwer domowy komunikuje się przez tunel.

Dynamiczny DNS dla serwerów bez statycznego adresu IP

Jeśli Twój publiczny adres IP ulegnie zmianie, klienci ze starym adresem IP w liniach C nie będą mogli się połączyć. Użyj dynamicznej usługi DNS i wpisz nazwę hosta (np. myserver.ddns.net ) w liniach C zamiast pustego adresu IP. Uruchom klienta aktualizacji DDNS, takiego jak ddclient na serwerze Linux, aby utrzymać aktualność rekordu. Większość routerów domowych również ma tę funkcję wbudowaną.

Również: jeśli Twój dostawca usług internetowych blokuje ruch przychodzący TCP na porcie 12000 (niektórzy tak robią), zmień SERVERPORT na coś mniej rzucającego się w oczy, np. 15000 lub 8080, zaktualizuj regułę przekierowania portów na routerze i zaktualizuj odpowiednio linię C każdego klienta.

Rozwiązywanie typowych problemów z serwerem CCcam w systemie Linux

Debugowanie serwera CCAM w systemie Linux przebiega według dość spójnego schematu: eliminuj warstwy po kolei, zaczynając od dołu (czy proces w ogóle działa?), przechodząc przez sieć, konfigurację, a na końcu wykrywanie kart.

CCcam uruchamia się, ale klienci nie mogą się połączyć: lista kontrolna

• Potwierdź, że proces faktycznie działa: systemctl status cccam
• Potwierdź, że nasłuchuje: ss -tlnp | grep 12000
• Najpierw przetestuj lokalnie: telnet 127.0.0.1 12000 — jeśli to się nie powiedzie, problem leży w usłudze, a nie w sieci
• Sprawdź zaporę sieciową: iptables -L -n | grep 12000
• Sprawdź linię F: nazwa użytkownika i hasło muszą dokładnie odpowiadać tym, których klient używa w swojej linii C
• Sprawdź, czy adres IP/nazwa hosta linii C klienta jest poprawnie rozpoznawana na komputerze klienckim

„Nie znaleziono karty” lub karta nie została wykryta po zdefiniowaniu czytnika

Uruchom polecenie dmesg | tail -30 zaraz po podłączeniu czytnika. Powinieneś zobaczyć wiersz dotyczący nowego urządzenia USB i węzła urządzenia, do którego zostało przypisane. Jeśli go nie widzisz, czytnik nie jest rozpoznawany na poziomie jądra — może to być problem ze sterownikiem lub awaria sprzętu.

Jeśli czytnik się pojawia, ale karta nie jest wykrywana, sprawdź, czy wiersz DEVICE w pliku CCcam.cfg wskazuje na dokładną ścieżkę wskazaną w pliku dmesg. Pamiętaj: /dev/ttyACM0 i /dev/ttyUSB0 to różne urządzenia i niewłaściwe z nich automatycznie ulegnie awarii. Sprawdź również, czy użytkownik procesu CCcam ma uprawnienia do odczytu i zapisu na urządzeniu: ls -l /dev/ttyUSB0 i w razie potrzeby dodaj użytkownika CCcam do grupy dialout .

Nieprawidłowe odpowiedzi ECM i błędy dekodowania (niezgodność CAID)

Klient łączy się, co widać w interfejsie internetowym CCcam na porcie 16001, ale kanał nie jest odszyfrowywany. Prawie zawsze występuje niezgodność identyfikatorów CAID. Otwórz interfejs internetowy i sprawdź, jakie identyfikatory CAID są faktycznie reklamowane przez serwer. Następnie sprawdź, jakiego identyfikatora CAID używa kanał — będzie to widoczne na ekranie informacji o kanale dekodera lub w menu kamery. Jeśli identyfikatory nie będą zgodne, serwer nie będzie mógł pomóc klientowi, niezależnie od statusu połączenia.

Sprawdź również HOP COUNT. Jeśli linia F dla tego klienta ma wartość reshare równą 0, a karta została odebrana z nadrzędnej linii C (nie lokalnej), klient nic nie otrzyma. HOP COUNT 0 blokuje reshare kart spoza lokalizacji.

Duże obciążenie / Długie czasy reakcji ECM

Pojedyncza karta fizyczna może przetwarzać tylko jeden moduł ECM na raz. Jeśli masz 10 klientów żądających odszyfrowania jednocześnie, ustawiają się w kolejce, a czas reakcji wydłuża się. Kanał może się zacinać lub chwilowo wyłączać. Rozwiązaniem jest albo mniejsza liczba klientów, albo dodatkowe karty fizyczne, albo dodatkowe linie C-stream z różnymi kartami. Nie ma na to żadnego oprogramowania – to ograniczenie sprzętowe.

Lokalizacja pliku dziennika i sposób odczytu danych debugowania CCcam

Jeśli plik LOGFILE jest zdefiniowany w pliku CCcam.cfg, logi trafiają właśnie tam. W przeciwnym razie, podczas pracy w systemie systemd, użyj polecenia journalctl -u cccam -f aby uzyskać podgląd na żywo. Szukaj wierszy zawierających słowa „connected”, „ECM”, „card” oraz kody błędów. Odpowiedź ECM „0x00” zazwyczaj oznacza, że karta odpowiedziała poprawnie. Błędy takie jak „N/A” lub komunikaty o przekroczeniu limitu czasu wskazują na problemy z kartą.

CCcam zawiesza się podczas uruchamiania: naprawa niezgodności binarnej

Najpierw uruchom file CCcam . Następnie uruchom ldd CCcam . Jeśli zobaczysz komunikat „not a dynamic executable” (nie jest to dynamiczny plik wykonywalny), plik binarny jest linkowany statycznie i powinien zostać uruchomiony. Jeśli zobaczysz nierozwiązane biblioteki („not found”), zainstaluj brakujące pakiety 32-bitowe. Jeśli CCcam natychmiast zakończy działanie z komunikatem „Exec format error” (błąd formatu pliku wykonywalnego), oznacza to całkowitą niezgodność architektury — na przykład plik binarny ARM na x86. Wybierz odpowiedni plik binarny dla swojej platformy.

CCcam kontra OScam jako serwer Linux: kiedy warto zmienić

Jeśli zaczynasz od nowa, poważnie rozważ OScam. CCcam 2.3.0 to porzucone oprogramowanie — bez poprawek, aktualizacji i kodu źródłowego do audytu. OScam jest aktywnie utrzymywany, udostępniany na licencji open source (GPL) i obsługuje nadzbiór funkcji CCcam. Jedynym powodem, dla którego warto pozostać przy CCcam, jest konkretna potrzeba kompatybilności klienta CCcam ze starszymi urządzeniami, które nie obsługują natywnego protokołu OScam — a nawet wtedy OScam sobie z tym radzi.

Kluczowe różnice w architekturze

CCcam to czarna skrzynka. Bierzesz plik binarny, konfigurujesz go i masz nadzieję, że zadziała — nie ma możliwości sprawdzenia ani modyfikacji jego elementów wewnętrznych. OScam jest w pełni open source, aktywnie łatany pod kątem nowych typów kart i luk w zabezpieczeniach, a także ma znacznie bogatszy model konfiguracji z filtrowaniem dla poszczególnych czytników i użytkowników z precyzją, której CCcam nie jest w stanie dorównać. Interfejs internetowy w OScam jest również znacznie lepszy niż podstawowa strona portu 16001 CCcam.

Zaawansowane filtrowanie CAID i identyfikatorów dostawców OScam

W OScam możesz filtrować według CAID, identyfikatora dostawcy, identyfikatora usługi, a nawet konkretnych identyfikatorów ECM PID – wszystko niezależnie dla czytnika, użytkownika i profilu. W porównaniu z tym filtrowanie w CCcam jest dość prymitywne. Jeśli korzystasz z karty z wieloma pakietami dostawców i potrzebujesz precyzyjnej kontroli nad dostępem każdego klienta, OScam jest idealnym narzędziem.

Uruchamianie OScam jako serwera protokołu CCcam (nasłuchiwacze cs378x/cs357x)

OScam obsługuje protokół CCcam natywnie. Oznacza to, że Twoi obecni klienci CCcam nie muszą w ogóle zmieniać linii C — OScam odpowiada na porcie 12000 i nigdy nie zauważy różnicy.

W /etc/oscam/oscam.conf dodaj blok nasłuchujący:

 [cs378x] port = 12000 key = 0102030405060708091011121314151617181920

Moduł cs378x obsługuje połączenia protokołu CCcam w wersji 2.x. W przypadku starszych wariantów protokołu CCcam należy użyć cs357x. Użytkownicy są następnie definiowani w /etc/oscam/oscam.user z protocol = cccam .

Ścieżka migracji: Konwersja pliku CCcam.cfg do plików konfiguracyjnych OScam

Linie C CCcam stają się wpisami czytelników w /etc/oscam/oscam.server :

 [reader] label = upstream1 protocol = cccam device = remote.host.example,12000 user = myusername password = mypassword caid = 1830 ident = 1830:000000

Linie F CCcam stają się wpisami użytkownika w /etc/oscam/oscam.user :

 [account] user = client1 pwd = strongpassword protocol = cccam group = 1 caid = 1830

Konwersja jest mechaniczna, ale wymaga przejścia linia po linii. Nie ma automatycznego narzędzia, które niezawodnie obsłuży każdy przypadek skrajny. Poświęć godzinę i zrób to ręcznie — warto, aby zapewnić długoterminową możliwość utrzymania poprawnej konfiguracji OScam w porównaniu ze starszą instalacją serwera CCCAM na Linuksie.