\n\n

Serwer CCcam na Linuxie: Pełna konfiguracja& Przewodnik

\n\n

Ustawienie serwera cccam na Linuxie od podstaw to jedno z tych zadań, które wydaje się proste, dopóki nie napotkasz pierwszego błędu zgodności binarnej o 23:00. Ten przewodnik obejmuje pełną ścieżkę: decyzje architektoniczne, instalację binarną, składnię plików konfiguracyjnych, zasady zapory ogniowej i co robić, gdy coś się zepsuje. Jeśli masz kartę smart w ręku i gotową maszynę z Linuxem, oto dokładnie to, co musisz wiedzieć.

\n\n

Co właściwie robi CCcam na Linuxie (i kiedy potrzebujesz serwera)

\n\n

CCcam to demon udostępniania kart. Jedna maszyna uruchamia go z podłączonym fizycznym czytnikiem kart — to jest serwer. Inne urządzenia w twojej sieci (lub w internecie) łączą się z nim i żądają dekodowania ECM dla kanałów, które próbują oglądać. Serwer dekoduje za pomocą fizycznej karty i wysyła Control Word z powrotem do klienta. Wszystko to odbywa się przez TCP, domyślny port 12000.

\n\n

Architektura ma znaczenie, ponieważ określa twoją konfigurację. Serwer ma kartę podłączoną lokalnie i udostępnia linie F dla przychodzących klientów. Klient łączy się wychodząc za pomocą linii C. Większość ludzi się myli, ponieważ CCcam działa po obu stronach — to ten sam plik binarny, tylko skonfigurowany inaczej.

\n\n

Tryb klienta vs. serwera: Co zmienia się w konfiguracji

\n\n

Nie ma oddzielnego flagi "trybu serwera". Rozróżnienie polega całkowicie na tym, które linie pojawiają się wCCcam.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 być również obydwoma jednocześnie — łącząc się w górę, podczas gdy obsługujesz klientów w dół — co jest sposobem, w jaki działają kaskady.

\n\n

Dlaczego Linux jest preferowanym systemem operacyjnym dla CCcam

\n\n

Niezawodność to główny powód. Maszyna z Linuxem uruchamiająca CCcam jako usługę systemd automatycznie uruchomi się ponownie po awarii i przetrwa ponowne uruchomienia bez interwencji. Windows nie ma równoważnej infrastruktury demona do tego. Ponadto większość opartych na ARM odbiorników satelitarnych, które ludzie faktycznie używają — Dreambox, VU+, Zgemma — działa na Enigma2, która jest Linuxem. Dlatego plik binarny, skrypty inicjalizacyjne i ścieżki konfiguracyjne są takie same na różnych platformach.

\n\n

Wymagania sprzętowe: CPU, RAM i wsparcie dla fizycznych czytników kart smart

\n\n

CCcam nie jest zasobożerny. Procesor 500MHz i 64MB RAM to naprawdę wystarczające dla kilku klientów. Każda nowoczesna maszyna z Linuxem jest znacznie przewyższająca wymagania. Prawdziwym ograniczeniem jest czytnik kart: potrzebujesz albo wewnętrznego czytnika (często spotykanego w sprzęcie Dreambox), albo zewnętrznego czytnika USB rozpoznawanego przez jądro. Popularne opcje to sc8in1, czytniki w stylu phoenixrc oraz standardowe czytniki USB zgodne z CCID. Uruchomdmesg | grep tty po podłączeniu, aby potwierdzić, że się pojawiło — będzie widoczne jako/dev/ttyUSB0,/dev/ttyACM0, lub podobne w zależności od chipsetu.

\n\n

Instalacja CCcam na Linuxie: Binarne, Zależności i Pierwsze Uruchomienie

\n\n

CCcam 2.3.0 to ostatnia wersja, która kiedykolwiek była szeroko rozpowszechniana. Jest to oprogramowanie zamknięte, nigdy nie aktualizowane, a pierwotni deweloperzy dawno odeszli. To, co masz, to statyczny lub półstatyczny plik binarny — a na nowoczesnym 64-bitowym serwerze Debian lub Ubuntu, to od razu stwarza problemy, ponieważ jest to 32-bitowy plik binarny ELF.

\n\n

Wybór Odpowiedniego Pliku Binarnego CCcam dla Twojej Architektury

\n\n

Uruchomfile CCcam na dowolnym pliku binarnym, który masz. Zobaczysz coś takiego jakELF 32-bit LSB executable, ARM, EABI5 lubELF 32-bit LSB executable, Intel 80386. Dopasuj plik binarny do swojego sprzętu. Binarne pliki ARM dla odbiorników ARM. Binarne pliki x86 32-bit dla ogólnych serwerów PC. Jeśli jesteś na maszynie 64-bitowej x86, potrzebujesz 32-bitowego pliku binarnego x86 plus warstwy kompatybilności — nie wersji ARM, nawet jeśli ARM jest w jakiś sposób dostępny.

\n\n

Instalacja 32-bitowych Zależności Bibliotek na Debianie/Ubuntu

\n\n

Na świeżym systemie 64-bitowym Debian 11/12 lub Ubuntu 22.04, 32-bitowe środowisko uruchomieniowe nie jest domyślnie zainstalowane. Najpierw to napraw:

\n\n

dpkg --add-architecture i386\napt-get update\napt-get install libc6-i386 lib32gcc-s1

\n\n

W starszych wersjach Ubuntu (przed 20.04) możesz zobaczyćia32-libsw starych poradnikach — ten pakiet już nie istnieje. Użyjlibc6-i386 zamiast tego. Po zainstalowaniu, zweryfikuj za pomocąldd CCcam aby sprawdzić, czy wszystkie biblioteki współdzielone są rozwiązane. Jeśli uruchamiasz kontener Docker, który jest tylko 64-bitowy i nie ma wsparcia dla multiarch, całkowicie pomiń CCcam i przejdź od razu do OScam (omówione w sekcji 6).

\n\n

Umieszczanie binariów i ustawianie uprawnień do wykonywania

\n\n

cp CCcam /usr/local/bin/CCcam\nchmod +x /usr/local/bin/CCcam\nchown root:root /usr/local/bin/CCcam

\n\n

Na obrazach odbiorników Enigma2, binaria zazwyczaj znajdują się w/usr/bin/CCcam i są uruchamiane przez skrypt init.d. Nie przenoś go na tych systemach — ich skrypty init oczekują go w tej ścieżce.

\n\n

Uruchamianie CCcam jako usługi systemd dla automatycznego restartu

\n\n

Utwórz/etc/systemd/system/cccam.service z tą zawartością:

\n\n

[Unit]\nDescription=CCcam Card Server\nAfter=network.target\n\n[Service]\nExecStartPre=/bin/sleep 10\nExecStart=/usr/local/bin/CCcam\nRestart=on-failure\nRestartSec=5\nStandardOutput=journal\nStandardError=journal\n\n[Install]\nWantedBy=multi-user.target

\n\n

ExecStartPre=/bin/sleep 10 nie jest opcjonalne, jeśli twój czytnik kart smartcard potrzebuje chwili na inicjalizację po uruchomieniu. Bez tego, CCcam uruchamia się zanim jądro zakończy konfigurację czytnika USB i loguje "brak karty" — a następnie nigdy nie próbuje ponownie.

\n\n

systemctl daemon-reload\nsystemctl enable cccam\nsystemctl start cccam

\n\n

Weryfikacja, czy proces nasłuchuje na porcie 12000

\n\n

ss -tlnp | grep 12000\n# lub\nnetstat -tlnp | grep CCcam

\n\n

Powinieneś zobaczyć CCcam przypisany do0.0.0.0:12000 lub konkretnego adresu IP interfejsu. Jeśli nic się nie wyświetla, sprawdźjournalctl -u cccam -n 50 w poszukiwaniu błędów uruchamiania.

\n\n

Głębokie zanurzenie w CCcam.cfg: Każda dyrektywa, którą musisz znać

\n\n

Plik konfiguracyjny znajduje się w/etc/CCcam.cfg domyślnie. CCcam najpierw sprawdza tam. Niektóre skrypty uruchamiające przekazują ścieżkę jako argument — sprawdź swoje, jeśli zmiany nie są uwzględniane. Jedna rzecz, która ciągle sprawia problemy: zakończenia linii Windows (CRLF) w pliku konfiguracyjnym powodują ciche błędy analizy w systemie Linux. Jeśli edytowałeś ten plik w systemie Windows i przeniosłeś go, uruchomdos2unix /etc/CCcam.cfg przed debugowaniem czegokolwiek innego.

\n\n

Komentarze używają# lub// — oba działają. Dyrektywy są niewrażliwe na wielkość liter dla samego słowa kluczowego, ale wartości (nazwy użytkowników, hasła, nazwy hostów) są wrażliwe na wielkość liter.

\n\n

Port serwera i adres nasłuchujący: DYREKTYWY SERVERPORT i BIND

\n\n

# Nasłuchuj przychodzących połączeń klientów CCcam\nSERVERPORT: 12000\n\n# Przypisz do konkretnego interfejsu (zalecane)\n# BIND: 10.8.0.1

\n\n

Jeśli masz wiele interfejsów sieciowych — powiedzmy, interfejs WAN i interfejs VPN — CCcam domyślnie przypisze się do wszystkich z nich (0.0.0.0). To jest problem z bezpieczeństwem. Użyj dyrektywy BIND, aby zablokować to tylko do adresu IP interfejsu VPN. Więcej na ten temat w sekcji zapory.

\n\n

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

\n\n

# Zdefiniuj fizyczny czytnik kart smart\nDEVICE: /dev/ttyUSB0 SR\nCARDTYPE: 0\nBOXKEY: 00 00 00 00 00 00 00 00

\n\n

Ścieżka URZĄDZENIA musi odpowiadać temu, codmesg pokazuje. Jeśli twój czytnik pojawia się jako/dev/ttyACM0 zamiast/dev/ttyUSB0, konfiguracja musi wskazywać/dev/ttyACM0. Błąd w tym zakresie jest jedną z najczęstszych przyczyn błędów "brak karty". CARDTYPE 0 oznacza automatyczne wykrywanie, co działa dla większości kart. BOXKEY jest istotny dla kart Nagravision, które używają boxkey — pozostaw go zerowym, jeśli twoja nie używa.

\n\n

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

\n\n

C-line informuje ten serwer, aby połączył się z innym serwerem CCcam:

\n\n

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

\n\n

Rozbijając to:remote.host.example to nazwa hosta lub adres IP serwera upstream.12000 to port.myusername imypassword to twoje dane logowania na tym serwerze.{0:0:1} to opcjonalny filtr CAID w formacie{CAID:ProviderID:1} — wartość0:0:1 oznacza akceptację wszystkich CAID-ów. Końcowy01 to liczba przeskoków dla ponownego udostępniania kart otrzymanych z tej linii.

\n\n

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

\n\n

F-linie definiują, kto może połączyć się z Twoim serwerem:

\n\n

F: klient1 silnehasło 1 0 0 0 { 1830:000000:1 }\nF: klient2 innehasło 1 0 0 0 { 0:0:1 }

\n\n

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

\n\n

B-linia do blokowania konkretnych identyfikatorów dostawców

\n\n

B: 1234 000000

\n\n

B-linie blokują konkretną kombinację CAID/dostawcy przed udostępnianiem. Jeśli masz kartę z wieloma dostawcami i chcesz zablokować jednego, oto jak to zrobić. Format toB: CAID ProviderID.

\n\n

LIMIT UDOSTĘPNIANIA i LICZBA PRZESKOKÓW: Kontrola głębokości ponownego udostępniania

\n\n

LICZBA PRZESKOKÓW kontroluje, ile razy karta może być ponownie udostępniana, zanim CCcam przestanie ją przekazywać dalej. Ustaw to w F-liniach (na użytkownika) lub globalnie:

\n\n

LIMIT UDOSTĘPNIANIA: 3

\n\n

LICZBA PRZESKOKÓW równa 0 oznacza, że karta jest lokalna i nie będzie w ogóle ponownie udostępniana. Wartość 1 oznacza, że może przejść jeden przeskok do klientów, ale ci klienci nie mogą jej ponownie udostępnić. Utrzymuj to tak nisko, jak to praktycznie możliwe — głębokie łańcuchy ponownego udostępniania spowalniają czasy reakcji ECM i tworzą problemy z odpowiedzialnością.

\n\n

Dyrektywy LOG i DEBUG do rozwiązywania problemów

\n\n

LOGFILE: /var/log/cccam.log\nLOGLEVEL: 1\nDEBUG: 0

\n\n

LOGLEVEL 1 daje ci zdarzenia połączeń i aktywność ECM bez zalewania dysku. Ustaw DEBUG na 1 tymczasowo, gdy ścigasz konkretny problem — jest szczegółowy i będziesz chciał to wyłączyć. Interfejs webowy na porcie 16001 (domyślne dane logowania: admin/admin — zmień je natychmiast) pokazuje status kart w czasie rzeczywistym, połączonych klientów i czasowanie ECM, co jest znacznie łatwiejsze do odczytania niż surowe logi podczas diagnozy.

\n\n

Zapora, sieć i przekierowywanie portów dla CCcam

\n\n

To jest miejsce, w którym konfiguracja serwera cccam na Linuxie najczęściej się zatrzymuje. Usługa działa, konfiguracja wygląda poprawnie, ale klienci nie mogą się połączyć. Dziewięć razy na dziesięć to zasada zapory lub problem z NAT.

\n\n

Otwieranie portu TCP 12000 za pomocą iptables i ufw

\n\n

Używając iptables bezpośrednio:

\n\n

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT\n# Zapisz zasady, aby przetrwały restart:\niptables-save > /etc/iptables/rules.v4

\n\n

Lub jeśli używasz ufw:

\n\n

ufw allow 12000/tcp\nufw reload

\n\n

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

\n\n

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

\n\n

Przypisanie CCcam do konkretnego interfejsu, aby uniknąć narażenia

\n\n

Jeśli twój serwer ma publiczny interfejs (eth0) i interfejs VPN (wg0 lub tun0), nie zostawiaj CCcam nasłuchującego na obu. Dodaj dyrektywę BIND w CCcam.cfg z adresem IP prywatnego/interfejsu VPN. Klienci łączą się przez VPN, a port 12000 nigdy nie jest narażony na publiczny internet. To jest właściwy sposób, aby to zrobić.

\n\n

Używanie tunelu VPN (WireGuard/OpenVPN) zamiast publicznego narażania portu 12000

\n\n

WireGuard jest lepszym wyborem w dzisiejszych czasach — ma mniejsze obciążenie niż OpenVPN, prostszą konfigurację, a moduł jądra jest teraz włączony od wersji Linux 5.6. Skonfiguruj peer WireGuard między swoim 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 skanujący internet nigdy nie zobaczy portu 12000.

\n\n

NAT i Przekierowanie Portów, jeśli Serwer jest za Routerem Domowym

\n\n

Jeśli twój serwer Linux znajduje się w sieci domowej, musisz przekierować port TCP 12000 na swoim routerze do lokalnego adresu IP serwera. Większość routerów nazywa to "przekierowaniem portów" lub "serwerem wirtualnym." Ustaw port zewnętrzny na 12000, protokół TCP, wewnętrzny adres IP na adres LAN twojego serwera (ustaw go jako statyczny, albo poprzez rezerwację DHCP, albo ręczną konfigurację), port wewnętrzny 12000. Następnie klienci używają twojego publicznego adresu IP w swoich liniach C.

\n\n

Jeden poważny problem: jeśli twój dostawca internetu używa CGNAT (carrier-grade NAT), tak naprawdę nie masz publicznego adresu IP — dzielisz go z dziesiątkami innych klientów i nie ma możliwości przekierowania połączeń przychodzących. Rozwiązaniem jest wynajęcie taniego VPS-a, uruchomienie na nim WireGuard i tunelowanie ruchu CCcam przez to. VPS staje się publicznym punktem końcowym; twój domowy serwer komunikuje się z powrotem przez tunel.

\n\n

Dynamiczny DNS dla Serwerów Bez Statycznego IP

\n\n

Jeśli twój publiczny adres IP się zmienia, klienci z twoim starym adresem IP w swoich liniach C nie będą mogli się połączyć. Użyj usługi dynamicznego DNS i umieść nazwę hosta (np.myserver.ddns.net) w liniach C zamiast gołego adresu IP. Uruchom klienta aktualizacji DDNS, takiego jakddclient na swoim serwerze Linux, aby utrzymać rekord aktualny. Większość domowych routerów ma to również wbudowane.

\n\n

Również: jeśli twój dostawca internetu blokuje przychodzący TCP na porcie 12000 (niektórzy tak robią), zmień SERVERPORT na coś mniej rzucającego się w oczy, jak 15000 lub 8080, zaktualizuj regułę przekierowania portów na swoim routerze i zaktualizuj każdą linię C klienta, aby pasowała.

\n\n

Rozwiązywanie Typowych Problemów z Serwerem CCcam na Linuxie

\n\n

Debugowanie konfiguracji serwera cccam na Linuxie przebiega według dość spójnego schematu: eliminuj warstwy jedna po drugiej, zaczynając od dołu (czy proces w ogóle działa?) przez sieć, następnie konfigurację, a potem wykrywanie karty.

\n\n

CCcam Uruchamia się, ale Klienci Nie Mogą Się Połączyć: Lista Kontrolna

\n\n

\n
• Potwierdź, że proces rzeczywiście działa:systemctl status cccam
\n
• Potwierdź, że nasłuchuje:ss -tlnp | grep 12000
\n
• Najpierw przetestuj lokalnie:telnet 127.0.0.1 12000 — jeśli to nie zadziała, problem leży w usłudze, a nie w sieci
\n
• Sprawdź zaporę:iptables -L -n | grep 12000
\n
• Sprawdź linię F: nazwa użytkownika i hasło muszą dokładnie odpowiadać temu, co klient używa w swojej linii C
\n
• Potwierdź, że adres IP/nazwa hosta linii C klienta poprawnie rozwiązuje się z maszyny klienta
\n

\n\n

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

\n\n

Zacznij oddmesg | tail -30 zaraz po podłączeniu czytnika. Powinieneś zobaczyć linię o nowym urządzeniu USB i przypisanym mu węźle urządzenia. Jeśli tego nie widzisz, czytnik nie jest rozpoznawany na poziomie jądra — może to być problem z sterownikiem lub usterka sprzętowa.

\n\n

Jeśli czytnik się pojawia, ale karta nie jest wykrywana, zweryfikuj, czy linia DEVICE w CCcam.cfg wskazuje dokładną ścieżkę pokazaną w dmesg. Pamiętaj:/dev/ttyACM0 oraz/dev/ttyUSB0 to różne urządzenia, a niewłaściwe z nich spowoduje cichą awarię. Sprawdź również, czy użytkownik procesu CCcam ma uprawnienia do odczytu/zapisu na urządzeniu:ls -l /dev/ttyUSB0 i dodaj użytkownika CCcam do grupydialout jeśli to konieczne.

\n\n

Błędne odpowiedzi ECM i niepowodzenia dekodowania (niezgodność CAID)

\n\n

Klient łączy się, widzisz to w interfejsie webowym CCcam na porcie 16001, ale kanał nie jest odszyfrowany. Prawie zawsze jest to niezgodność CAID. Otwórz interfejs webowy, sprawdź, jakie CAID-y serwer faktycznie ogłasza. Następnie sprawdź, jaki CAID używa kanał — ekran informacji o kanale w twoim STB lub menu CAM to pokaże. Jeśli się nie zgadzają, serwer nie może pomóc temu klientowi niezależnie od statusu połączenia.

\n\n

Sprawdź również LICZBĘ HOP. Jeśli linia F dla tego klienta ma wartość reshare równą 0, a karta została otrzymana z górnej linii C (nie lokalnej), klient nie dostaje nic. LICZBA HOP 0 blokuje ponowne udostępnianie kart nielokalnych.

\n\n

Wysokie obciążenie / Wolne czasy odpowiedzi ECM

\n\n

Pojedyncza fizyczna karta może przetwarzać tylko jeden ECM w danym czasie. Jeśli masz 10 klientów, którzy jednocześnie żądają odszyfrowania, ustawiają się w kolejce, a czasy odpowiedzi rosną. Kanał może się zaciąć lub na chwilę zgasnąć. Rozwiązaniem jest albo mniej klientów, dodatkowe fizyczne karty, albo dodatkowe górne linie C z różnymi kartami. Nie ma programowego obejścia tego — to ograniczenie sprzętowe.

\n\n

Lokalizacja pliku dziennika i jak czytać dane debugowania CCcam

\n\n

Jeśli LOGFILE jest zdefiniowany w CCcam.cfg, logi trafiają tam. W przeciwnym razie, uruchamiając pod systemd, użyjjournalctl -u cccam -f aby uzyskać na żywo. Szukaj linii zawierających "connected", "ECM", "card" i kody błędów. Odpowiedź ECM "0x00" zazwyczaj oznacza, że karta odpowiedziała poprawnie. Błędy takie jak "N/A" lub komunikaty o czasie oczekiwania wskazują na problemy z kartą.

\n\n

CCcam zawiesza się przy uruchamianiu: Naprawa niekompatybilności binarnej

\n\n

Uruchomfile CCcam najpierw. Następnie uruchomldd CCcam. Jeśli widzisz "not a dynamic executable", binarka jest statycznie powiązana i powinna działać. Jeśli widzisz nierozwiązane biblioteki ("not found"), zainstaluj brakujące pakiety 32-bitowe. Jeśli CCcam natychmiast się zamyka z komunikatem "Exec format error", masz całkowitą niezgodność architektury — na przykład binarka ARM na x86. Zdobądź odpowiednią binarkę dla swojej platformy.

\n\n

CCcam vs OScam jako serwer Linux: Kiedy przełączyć

\n\n

Jeśli zaczynasz od nowa dzisiaj, poważnie rozważ OScam. CCcam 2.3.0 to oprogramowanie porzucone — brak poprawek, brak aktualizacji, brak kodu źródłowego do audytu. OScam jest aktywnie utrzymywane, open-source (GPL) i wspiera szerszy zestaw funkcji niż CCcam. Jedynym powodem, aby pozostać przy CCcam, jest potrzeba zgodności z klientami CCcam w przypadku starszych urządzeń, które nie obsługują natywnego protokołu OScam — a nawet wtedy, OScam sobie z tym radzi.

\n\n

Kluczowe różnice w architekturze

\n\n

CCcam to czarna skrzynka. Bierzesz binarkę, konfigurujesz ją i masz nadzieję, że działa — nie ma sposobu, aby zbadać lub zmodyfikować wnętrze. OScam jest w pełni otwartym źródłem, aktywnie aktualizowanym dla nowych typów kart i problemów z bezpieczeństwem, a także ma znacznie bogatszy model konfiguracji z filtrowaniem na poziomie czytnika i użytkownika, którego CCcam nie może dorównać. Interfejs webowy w OScam jest również znacznie lepszy niż podstawowa strona CCcam na porcie 16001.

\n\n

Filtracja CAID i ID dostawcy w OScam

\n\n

W OScam możesz filtrować według CAID, ID dostawcy, ID usługi, a nawet konkretnych PID ECM — wszystko niezależnie dla każdego czytnika, użytkownika i profilu. Filtrowanie w CCcam jest w porównaniu do tego mało precyzyjne. Jeśli korzystasz z karty z wieloma pakietami dostawców i potrzebujesz precyzyjnej kontroli nad tym, do czego każdy klient ma dostęp, OScam jest narzędziem do tego zadania.

\n\n

Uruchamianie OScam jako serwera protokołu CCcam (słuchacze cs378x / cs357x)

\n\n

OScam może komunikować się z protokołem CCcam natywnie. Oznacza to, że Twoi istniejący klienci CCcam nie muszą w ogóle zmieniać swoich linii C — OScam odpowiada na porcie 12000 i nigdy nie zauważają różnicy.

\n\n

W/etc/oscam/oscam.conf dodaj blok słuchacza:

\n\n

[cs378x]\nport = 12000\nkey = 0102030405060708091011121314151617181920

\n\n

Moduł cs378x obsługuje połączenia protokołu CCcam w wersji 2.x. Użyj cs357x dla starszych wariantów protokołu CCcam. Użytkownicy są następnie definiowani w/etc/oscam/oscam.user zprotocol = cccam.

\n\n

Ścieżka migracji: Konwersja CCcam.cfg na pliki konfiguracyjne OScam

\n\n

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

\n\n

[reader]\nlabel = upstream1\nprotocol = cccam\ndevice = remote.host.example,12000\nuser = myusername\npassword = mypassword\ncaid = 1830\nident = 1830:000000

\n\n

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

\n\n

[konto]\nuser = klient1\npwd = silnehasło\nprotocol = cccam\ngroup = 1\ncaid = 1830

\n\n

Konwersja jest mechaniczna, ale wymaga przejścia linia po linii. Nie ma automatycznego narzędzia, które niezawodnie obsługuje każdy przypadek brzegowy. Poświęć godzinę i zrób to ręcznie — warto dla długoterminowej konserwacji odpowiedniej konfiguracji OScam w porównaniu do przestarzałej instalacji serwera cccam na Linuxie.

\n\n