Serwer CCcam Europa: Przewodnik po konfiguracji, instalacji i rozwiązywaniu problemów

Jeśli próbujesz ustawić połączenie serwer cccam europa na swoim urządzeniu Enigma2 lub w instalacji Linux, prawdopodobnie już natrafiłeś na problem gdzieś między składnią C-line a czarnym ekranem przy zmianie kanału. Ten przewodnik obejmuje rzeczywiste szczegóły techniczne — ścieżki plików konfiguracyjnych, ustawienia portów, bloki czytników OScam, reguły zapory ogniowej i konkretne tryby awarii, które powodują problemy w przypadku europejskich pakietów satelitarnych. Bez patosu, bez fałszywych rekomendacji dostawców.

Co właściwie robi serwer CCcam dla Europy

CCcam to protokół udostępniania kart działający przez TCP. Podstawowa idea: serwer posiada fizyczną kartę inteligentną z ważną subskrypcją, a zdalni klienci wysyłają na ten serwer żądania ECM (Entitlement Control Message). Serwer deszyfruje kartę i wysyła z powrotem Control Word (CW), którego klient używa do dekodowania strumienia. To całe łańcuch.

Port domyślny to 12000, a protokół używa uścisku dłoni challenge-response z haszowaniem SHA1. Komunikacja to trwały TCP — nie HTTP, nie UDP. Sesja pozostaje aktywna tak długo, jak klient i serwer utrzymują połączenie, co jest ważne podczas debugowania.

Jak działa protokół CCcam (model klient-serwer)

Gdy zmienia się kanał, odbiornik identyfikuje system CA z PMT, wyodrębnia ECM i przekazuje go do CCcam. CCcam kieruje ten ECM do serwera hosta, który posiada odpowiednią kartę. CW wraca, zostaje wstrzyknięty do descramblers, a kanał się otwiera. Cała podróż w obie strony musi się odbyć szybko — idealnie poniżej 500ms, a dla kanałów sportowych ze zmianami transpondera, poniżej 300ms to to, czego chcesz.

EMM (Entitlement Management Messages) płynie w drugą stronę — z karty do systemu dostępu warunkowego, używany do aktualizacji subskrypcji i parowania. Jeśli zegar odbiornika jest błędny, filtrowanie EMM może zawieźć się w ciszy na określonych pakietach, szczególnie ORF i Sky DE.

Europejskie satelity objęte zakresem: Astra 19.2E, Hotbird 13E, Eutelsat 9A

Większość zaszyfrowanej treści europejskiej znajduje się na trzech pozycjach orbitalnych. Astra 19.2E (obsługiwana przez SES) obsługuje Sky Deutschland, ORF i szereg pakietów zaszyfrowanych w języku niemieckim — większość używająca Nagravision 3. Hotbird 13E hostuje Canal+ Francja, Sky Italia i różne pakiety Europy Wschodniej na Viaccess, Nagravision i Irdeto. Eutelsat 9A obsługuje pakiety regionalne, w tym część treści bałkańskiej i tureckiej.

Lokalizacja serwera ma tutaj znaczenie, ponieważ podróż ECM w obie strony musi się zakończyć w oknie ważności CW. Serwer fizycznie umiejscowiony w Niemczech odpowiadający na ECM Sky DE prawie zawsze zwyciężyć serwer w Azji o ponad 200ms. Ta różnica to różnica między czystym dekodowaniem a timeoutem „karta nie znaleziona".

Różnica między lokalną kartą a zdalną linią serwera

A loca

karta znajduje się w wbudowanym czytniku kart odbiorcy. Ścieżka ECM jest wewnętrzna — podmiliwisekundowa. Linia serwera zdalnego dodaje opóźnienie sieci do każdego żądania ECM. Na stabilnym połączeniu z geograficznie bliskim serwerem jest to akceptowalne. Ale każdy dodatkowy przeskok, każdy odcinek zapchanej trasy, pogarsza niezawodność dekodowania. To nie teoria — zobaczysz to w czarnych ekranach przy zmianie kanału.

Obsługa protokołu CCcam vs OScam dla pakietów europejskich

Natywny klient CCcam jest prostszy w konfiguracji, ale daje ci mniejszą widoczność. OScam, gdy jest skonfigurowany jako klient CCcam, daje ci statystyki czasu odpowiedzi ECM dla każdego czytnika w interfejsie internetowym, zarządzanie pamięcią podręczną i obsługę fallback. Dla pakietów europejskich, które używają wielu systemów CA na tym samym transponatorze (Viaccess i Nagravision jednocześnie, co robi Hotbird), OScam obsługuje priorytetyzację CA lepiej niż standardowy klient CCcam. OScam również rejestruje szczegóły bardziej szczegółowo, co czyni debugowanie rzeczywistym.

Konfiguracja klienta CCcam dla europejskich linii serwerowych

Prawidłowa konfiguracja strony klienta to miejsce, gdzie większość ludzi spędza najwięcej czasu. Ścieżki konfiguracji nie są spójne między obrazami odbiornika, a format C-line musi być dokładny — spacja na końcu lub niewłaściwa wielkość liter w haśle spowoduje niedomówioną awarię uwierzytelniania.

Lokalizacja i składnia pliku CCcam.cfg

W większości obrazów Enigma2 (OpenPLi, OpenATV, Gemini) główna konfiguracja znajduje się w /etc/CCcam.cfg. Niektóre starsze obrazy lub alternatywne dystrybucje umieszczają to w /var/etc/CCcam.cfg. Sprawdź za pomocą find / -name "CCcam.cfg" 2>/dev/null jeśli nie jesteś pewny. Plik jest zwykłym tekstem, z rozróżnianiem wielkości liter dla dyrektyw.

Jeden przypadek krawędziowy wart zaznaczenia: obrazy Enigma2, które się automatycznie aktualizują, mogą wymazać /etc/CCcam.cfg jeśli pakiet softcam zostanie ponownie zainstalowany. Przechowaj kopię zapasową w /home/root/CCcam.cfg.bak i użyj skryptu startowego, aby przywrócić ją w razie potrzeby. Algunos użytkownicy umieszczają trwałą kopię w /usr/keys/, ponieważ ten katalog zwykle przetrwa aktualizacje obrazu na sprzęcie Vu+ i Dreambox.

Prawidłowy format C-Line: Nazwa hosta, port, nazwa użytkownika, hasło

Format C-line jest prosty, ale bezwzględny:

C: hostname.example.com 12000 myusername mypassword

To znaczy: C: (z dwukropkiem, spacją), nazwa hosta lub IP, numer portu, nazwa użytkownika, hasło. Brak cudzysłowów wokół niczego. Brak dodatkowych znaków. Jeśli Twoja nazwa hosta używa dynamicznego DNS (powszechne w serwerach residential IP), istnieje specjalny tryb awarii: jeśli adres IP zmieni się, gdy odbiornik jest w trakcie sesji, CCcam spróbuje ponownie połączyć się z tą samą nazwą hosta — ale jeśli DNS nie został jeszcze rozpowszechniony, może rozwiązać stary adres IP. Otrzymujesz przerwania połączenia, które wyglądają losowo, ale skupiają się wokół zdarzeń zmiany IP.

Ustawianie liczby przeskoków i parametrów resharing

Jako klient łączący się ze zdalnym serwerem, ustaw wartość HOPS na 1 w CCcam.cfg:

HOPS = 1

Oznacza to, że odbiornik nie będzie ponownie udostępniać

są odbierane CWs do innych klientów. Jeśli uruchamiasz wieloodbiorkową konfigurację w domu i chcesz, aby wszystkie odbiorniki używały jednej linii CCcam, musisz jawnie włączyć resharing — ale każdy przyrost przeskoku dodaje opóźnienie, a Twój serwer upstream może całkowicie zablokować resharing. Sprawdź u operatora serwera przed założeniem, że resharing jest dozwolony.

W przypadku wieloodbiorkowej konfiguracji domowej prawidłowym podejściem jest jeden odbiornik (lub komputer Linux) działający jako lokalny serwer CCcam, pobierający linię upstream i redystrybuujący lokalnie. Liczba przeskoków z lokalnego pudełka do pozostałych odbiorników dodaje około 1-5 ms w sieci LAN — akceptowalne.

OScam jako klient CCcam: emulacja protokołu gbox i cccam

OScam może połączyć się z serwerem CCcam jako klient. Odpowiedni blok znajduje się w /etc/oscam/oscam.server:

[reader]
label = europe_cccam
protocol = cccam
device = hostname.example.com:12000
user = myusername
password = mypassword
cccversion = 2.3.0
cccmaxhops = 2
share_reshape = 0
reconnecttimeout = 30

Pole cccversion ma znaczenie — jeśli zdalny serwer uruchamia CCcam 2.3.x, a Twój OScam negocjuje ze starszym ciągiem wersji, uścisk dłoni może się nie powieść lub zejść do trybu zdegradowanego. Ustaw to jawnie. Parametr share_reshape = 0 uniemożliwia OScam resharing odbieranych CWs, chyba że konkretnie tego chcesz.

Sprawdź również, czy parametr au jest poprawnie ustawiony w pliku oscam.user dla odpowiedniego konta, jeśli potrzebujesz włączonego przetwarzania EMM. W przypadku większości konfiguracji klienta nie potrzebujesz au na kliencie — zostaw go wyłączony, chyba że masz pewność.

Różnice konfiguracji odbiornika Enigma2 a spoza Enigmy

Na odbiornikach spoza Enigmy (starsze modele Dreambox DM z własnym systemem operacyjnym, Technomate, niektóre pudełka Formuler) plik CCcam.cfg może znajdować się w /var/keys/ lub /etc/ w zależności od oprogramowania. Składnia jest identyczna. Różnica polega na tym, jak startuje softcam — na Enigma2 menedżer softcam obsługuje start/stop. Na innych odbiornikach może to być ręczny skrypt init.d, a nawet ręczne uruchomienie. Poznaj swój obraz.

Jedna konkretna pułapka: jeśli Twoje pudełko Enigma2 ma zainstalowany i jednocześnie uruchomiony zarówno CCcam, jak i OScam, będą walczyć o port 12000, jeśli oba są skonfigurowane do nasłuchiwania na nim. Tylko jeden proces może powiązać ten port. Wybierz jeden jako główny i wyłącz nasłuchiwanie drugiego lub jawnie przypisz różne porty.

Konfiguracja CCcam po stronie serwera na Linuksie

Uruchamianie własnego serwera CCcam na VPS Linux lub serwerze domowym daje Ci pełną kontrolę nad dostępem do karty, zarządzaniem użytkownikami i rejestrowaniem. To jest miejsce, gdzie większość przewodników się kończy — więc tutaj znajdziesz rzeczywistą konfigurację.

Instalacja binarnego CCcam na Debian/Ubuntu

CCcam nie ma oficjalnego pakietu Debian. Pobierzesz binarny bezpośrednio (wersja CCcam 2.3.x to obecna stabilna wersja) i umieścisz go ręcznie:

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

Binarny oczekuje swojej konfiguracji na /etc/CCcam.cfg domyślnie. Możesz to zastąpić flagą -c podczas uruchomienia. Utwórz plik konfiguracyjny przed pierwszym uruchomieniem — CCcam nie wygeneruje domyślnego.

Konfiguracja serwera CCcam.cfg: N-Lines i C-Lines

Na serwerze N-lines definiują konta klientów — co może się połączyć. Format:

N: clientusername clientpassword

C-lines na serwerze definiują połączenia upstream (jeśli Twój serwer pobiera z innego serwera wyżej w łańcuchu). Dla serwera zawierającego tylko fizyczne karty:

# Server config example
VERSION = 2.3.0
PORT = 12000
HOPS = 1
IGNORERESHARE = 1
KEEPALIVE = 1
N: user1 pass1
N: user2 pass2

IGNORERESHARE = 1 uniemożliwia klientom ponowne udostępnianie CW-ów swoim własnym klientom downstream. Zalecane, chyba że wyraźnie chcesz drzewo reshare.

Konfigurowanie portów: Domyślnie 12000, reguły zapory (iptables/ufw)

Otwórz port 12000 TCP za pomocą iptables:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables-save > /etc/iptables/rules.v4

Lub z ufw, jeśli to używasz:

ufw allow 12000/tcp

Jeśli Twój ISP lub dostawca hostingu blokuje port wejściowy 12000 (niektórzy robią), zmień dyrektywę PORT w CCcam.cfg na coś w rodzaju 10000 lub 8080 i odpowiednio zaktualizuj wszystkie C-lines klientów. Sam protokół nie obchodzi, jaki port używasz — 12000 to tylko konwencja.

Jedna sytuacja, która całkowicie psuje hosting serwera: CGNAT. Jeśli jesteś za Carrier-Grade NAT, nie masz routowanego publicznego IP, więc klienci nie mogą dotrzeć do Twojego serwera bezpośrednio. To jest w porządku dla trybu klienta — Twój odbiornik się łączy outbound — ale hosting serwera za CGNAT wymaga albo VPN ze statycznym punktem końcowym IP, albo odwrotnego tunelu SSH do VPS z prawdziwym publicznym IP.

Uruchamianie CCcam jako usługi systemd

Większość poradników to całkowicie pomija. Utwórz /etc/systemd/system/cccam.service:

[Unit]
Description=CCcam Card Sharing Server
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/CCcam
Restart=on-failure
RestartSec=5s
User=root
[Install]
WantedBy=multi-user.target

Następnie włącz i uruchom:

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam
systemctl status cccam

Linia Restart=on-failure oznacza, że CCcam automatycznie się uruchomi, jeśli się zawiesi, co czasami zdarza się podczas skoków przetwarzania EMM.

Lokalizacje plików dziennika i monitorowanie w czasie rzeczywistym

CCcam loguje do /tmp/CCcam.log domyślnie. Obserwuj to w czasie rzeczywistym:

tail -f /tmp/CCcam.log

Możesz również sprawdzić aktywne połączenia TCP na porcie 12000:

ss -tn | grep 12000

CCcam zawiera wbudowany interfejs internetowy, o którym prawie nikt nie wspomina — działa on domyślnie na porcie 16001. Skieruj przeglądarkę na http://your-server-ip:1

```html 6001 aby zobaczyć połączonych klientów, status karty, statystyki ECM i informacje o skokach. Nie jest wymagana konfiguracja — jest domyślnie włączone w wersji 2.3.x.

OScam jako pełny serwer: pliki oscam.conf, oscam.server, oscam.user

OScam jest naprawdę lepszy niż CCcam do zarządzania kartami po stronie serwera. Kluczowe pliki znajdują się w /etc/oscam/. Oto minimalna konfiguracja robocza:

oscam.conf — ustawienia globalne i webif:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 1000
preferlocalcards = 1
[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword

oscam.server — czytnik karty fizycznej:

[reader]
label = physical_card
protocol = internal
device = /dev/sci0
services = sky_de,orf
caid = 1830

oscam.user — konta klientów:

[account]
user = client1
password = pass1
protocol = cccam
cccmaxhops = 1
services = sky_de

Rozwiązywanie problemów z połączeniem serwera CCcam w Europie

Ta sekcja obejmuje rzeczywiste warunki błędu, które napotkasz w konfiguracji serwera cccam europa — nie są to ogólne porady dotyczące sieci, ale konkretne tryby awarii ze specyficznymi rozwiązaniami.

Błędy uwierzytelniania: złe hasło użytkownika lub zablokowane konto

W CCcam.log błędy uwierzytelniania zwykle wyglądają następująco: can't connect to server lub login failed. Najpierw sprawdź: skopiuj i wklej nazwę użytkownika i hasło bezpośrednio ze źródła poświadczeń — nie przepisuj ich. Wielkość liter ma znaczenie, spacje na końcu mają znaczenie.

Jeśli poświadczenia są poprawne, a nadal się nie powiedzie, konto może być zablokowane dla IP (niektóre serwery ograniczają do jednego IP), zawieszone lub serwer może filtrować na podstawie ciągu wersji CCcam klienta. Jeśli uruchamiasz klienta CCcam 2.0.x na serwerze oczekującym 2.3.x, uzgodnienie nie powiedzie się. Zaktualizuj plik binarny CCcam.

Kanał nie dekoduje: timeout ECM i problemy z latencją

Jesteś połączony, CCcam pokazuje serwer jako aktywny, ale określone kanały pokazują czarny ekran lub „brak sygnału" po zmianie kanału. To prawie zawsze timeout ECM. CW ma czas wygaśnięcia — jeśli odpowiedź nie wróci przed wygaśnięciem bieżącego CW, deszambler nie otrzyma nic i zobaczysz czarny ekran.

Szybko zmieniające się kanały sportowe na Sky DE i Canal+ używają okresów CW tak krótkich jak 10 sekund. Przy podróży w obie strony powyżej 300ms napotkasz to na zajętych transpondach. Sprawdź ping do IP serwera: ping -c 20 server-ip i spójrz na średnią i maksimum — skok do 400ms zabija to nawet jeśli średnia wynosi 80ms.

Port 12000 zablokowany przez ISP lub zaporę — porty alternatywne

Niektórzy dostawcy usług internetowych korzystają z inspkcji pakietów głębokich, aby zidentyfikować i zablokować ruch portów 12000. Wskaźnik: możesz pingować serwer, DNS rozwiązuje się poprawnie, ale połączenie TCP na porcie 12000 nigdy się nie nawiązuje. Sprawdź za pomocą: nc -vz server-ip 12000. Jeśli upłynie limit czasu, ale serwer potwierdzona, że jest uruchomiony, twój ```ISP blokuje to.

Rozwiązania: poproś operatora serwera o dodanie nasłuchiwacza na alternatywnym porcie (8080, 10000 i 443 to popularne alternatywy — 443 prawie nigdy nie jest blokowany). Lub skonfiguruj tunel SSH:

ssh -L 12000:localhost:12000 user@server-ip -N

Następnie skieruj swoją linię C na localhost 12000, a tunel przenosi ruch przez SSH na porcie 22.

Niedopasowanie protokołu Newcamd vs CCcam

To powoduje wiele cichych awarii. W menedżerach softcam Enigma2 i konfiguracjach czytnika OScam musisz określić prawidłowy typ protokołu. Jeśli masz linię C CCcam, ale twój odbiornik jest skonfigurowany z typem czytnika Newcamd (linia N:), spróbuje wykonać uścisk dłoni Newcamd względem serwera CCcam — i zawiedzie bez wyraźnego błędu. Dziennik będzie pokazywać połączenie nawiązane, a następnie natychmiast rozłączone.

Linie C CCcam zaczynają się od C: i używają protokołu CCcam. Linie Newcamd zaczynają się od N: i mają zupełnie inny format (14-bajtowy klucz, różne konwencje portów). Nie są zamienne. Jeśli ktoś da ci linię C, to CCcam. Jeśli zaczyna się od N:, to Newcamd, a typ czytnika musi się zgadzać.

Błędy karty nie znalezionej dla określonych pakietów europejskich

Widzisz, że niektóre kanały działają, ale inne pokazują „card not found" w CCcam.log. Najczęstsza przyczyna: karta zdalna po prostu nie posiada subskrypcji dla tego konkretnego pakietu lub SID. Karta Sky DE zasubskrybowana na pakiet podstawowy nie będzie dekodować kanałów premium sport — żadna konfiguracja tego nie naprawy.

Druga przyczyna: kanał używa innego systemu CA niż ten, który obsługuje karta. Kanały Hotbird 13E często transmitują ECM dla zarówno Viaccess 3.0 jak i Nagravision 3. Jeśli karta serwera obsługuje tylko Viaccess, ECM Nagravision zawiedzie. Lista priorytetów CA odbiornika określa, który ECM próbujesz najpierw — sprawdź konfigurację CA Enigma2 w /etc/tuxbox/config/camd.socket lub odpowiednie ustawienie priorytetu CA w twoim obrazie.

Problemy z rozpoznawaniem DNS dla linii serwera opartych na nazwach hostów

Jeśli twoja linia C używa nazwy hosta (zamiast bezpośredniego adresu IP), rozpoznawanie DNS następuje w momencie połączenia. Powolne lub niepowodzenie wyszukiwania DNS dodaje opóźnienie do każdego zdarzenia ponownego połączenia. W Enigma2 domyślny DNS to wszystko, co zapewnia twój router — co może mieć wysokie TTL lub problemy z buforowaniem.

Jeśli używasz serwera na linii mieszkalnej z dynamicznym DNS (w stylu DynDNS), nazwa hosta jest jedynym sposobem na jego znalezienie. Ale gdy IP się zmienia i DNS nie rozpropagował się, CCcam będzie rozpoznawać stary IP przez do TTL sekund (często 300-600s) przed otrzymaniem nowego. W tym oknie wszystkie próby ponownego połączenia nie powiodą się. Łagodzenie: użyj dostawcy dynamicznego DNS, który obsługuje bardzo niskie TTL (60s lub mniej).

Problemy synchronizacji zegara odbiornika wpływające na przetwarzanie EMM

To prawie nigdy nie jest udokumentowane. Niektóre systemy CA używają synchronizacji EMM dla weryfikacji subskrypcji — jeśli zegar odbiornika jest signifika

ntly wrong (more than a few minutes off), EMM processing for packages like ORF and certain Sky packages can fail silently. The channel may decode briefly then lose sync.

Fix it with NTP sync on your receiver. On Enigma2:

ntpdate pool.ntp.org

Or enable automatic NTP sync in the receiver's time settings. This is a ten-second fix that solves an infuriating problem.

Evaluating a CCcam European Server Line: Technical Criteria

If you're assessing a server line before committing to it, here's what to actually check — no provider names, just technical signals that tell you what you're dealing with.

Latency Requirements: Ping Thresholds per Package Type

Under 80ms round-trip to the server: excellent for any package type including fast-zapping sports. 80-150ms: generally fine for most European packages, you may see occasional black frames on channel change. 150-300ms: marginal — standard channels will mostly work, live sports on Sky DE or Canal+ Sport will show issues. Above 300ms: expect regular ECM timeouts on any package with short CW periods.

Measure this before you commit. ping -c 100 server-ip and look at the distribution, not just the average. A server that averages 120ms but spikes to 450ms on 10% of packets is worse than one that holds steady at 180ms.

Hop Count and Why Lower is Better

A hop count of 0 means the CCcam server holds the physical card. It's as close to the source as you can get. Hop 1 means your server is pulling from another server that has the physical card. Each hop adds latency (network round-trip for the ECM at each stage) and a potential point of failure. A server at hop 2 or 3 in a resharing chain will show higher ECM response times and more instability.

CCcam's web interface on port 16001 shows hop counts for each card/CAID combination. Use it. If a server claims to be hop 0 but the web interface shows hop 2, that's your answer.

Server Uptime and Redundancy Indicators

Real uptime only reveals itself over time. During a test period, check whether the server handles EMM update events without dropping — some CA systems push subscription renewals at specific times (midnight, start of month) and a poorly managed server will lose cards during these windows. A 24-hour test that spans a midnight window is more informative than a 24-hour test in the middle of the day.

Test Line Evaluation: What to Check in 24-48 Hours

During a test period on a linia serwera cccam europa, monitor these specific things: ECM response times in CCcam.log or OScam webif (target under 500ms, consistent), black screen frequency on channel change (zero is normal), whether all SIDs in the package decode (test systematically, not just one channel), and behavior during peak hours (7-10pm European time is when server load peaks).

Watch the log during the test, don't just flip channels

i zakładam, że to w porządku. grep "ECM" /tmp/CCcam.log | tail -50 daje szybki obraz czasów odpowiedzi i awarii.

Rozróżnianie linii serwera kart współdzielonych a dedykowanych

"Dedykowana" linia w card-sharingu oznacza, że Twoje konto jest jedynym klientem połączonym z konkretną kartą (lub gniazdem karty). Linia współdzielona oznacza, że wielu użytkowników dzieli czas ECM na tej samej karcie. Pod lekkim obciążeniem nie widać różnicy. Pod dużym obciążeniem (godziny szczytu, ważne imprezy sportowe), współdzielone karty pokazują zwiększone czasy odpowiedzi ECM i okresowe awarie w miarę zakolejkowania żądań.

Techniczny wskaźnik: obserwuj zmienność czasu odpowiedzi ECM w statystykach czytnika OScam. Dedykowana karta pokazuje spójne odpowiedzi poniżej 100ms. Mocno współdzielona karta pokazuje czasy, które gwałtownie wzrastają do 300ms+ w okresach zajętości. Oba mogą się średnio wyrównywać, ale zachowanie skoków jest rzeczywistym wskaźnikiem.

Kompatybilność wersji protokołu: CCcam 2.1.x vs 2.3.x

CCcam 2.1.x i 2.3.x używają różnego szyfrowania w uzgodnieniu. Nie są w pełni wstecz kompatybilne we wszystkich konfiguracjach. Jeśli używasz klienta 2.1.x przeciwko serwerowi 2.3.x, możesz się połączyć, ale ze zmniejszonym szyfrowaniem lub możesz otrzymać całkowitą awarię uzgodnienia w zależności od konfiguracji serwera.

CCcam 2.3.x dodał lepsze udostępnianie pamięci podręcznej i ulepszony CAID — oba istotne dla europejskich pakietów, gdzie nakładanie się systemów CA jest powszechne. Jeśli obraz receivera jest wyposażony w CCcam 2.0.x lub 2.1.x, sprawdź, czy dla Twojej platformy dostępny jest binarny 2.3.x. Ciąg wersji wysyłany przez klienta podczas uzgodnienia jest widoczny w CCcam.log po stronie serwera — warto sprawdzić, czy uwierzytelnianie nie powoduje nieoczekiwanego błędu.