Jak sprawdzić status serwera CCcam (online i offline)

Jeśli musisz sprawdzić status serwera CCcam i widzisz zamrożony kanał lub czarny ekran, najgorszą rzeczą, którą możesz zrobić, jest losowe restartowanie usług. Musisz przejść przez trzy odrębne warstwy diagnostyczne — a większość ludzi przeskakuje od razu do warstwy trzeciej, ignorując pierwsze dwie. Ten przewodnik omawia każdą metodę, z rzeczywistymi poleceniami i rzeczywistymi ścieżkami konfiguracji, abyś mógł dokładnie zlokalizować miejsce awarii.

Zrozumienie statusu serwera CCcam: co dokładnie sprawdzasz

Większość przewodników dotyczących sprawdzania statusu traktuje pytanie „czy CCcam działa?" jako jedno pytanie tak/nie. To nieprawda. Istnieją trzy odrębne warstwy i każda z nich może zawiść niezależnie od innych.

Status procesu vs. Status portu vs. Status karty

Warstwa 1 to sam proces CCcam — czy binarny faktycznie działa w systemie operacyjnym? Warstwa 2 to port TCP — czy coś słucha na porcie 12000 i akceptuje połączenia? Warstwa 3 to status karty — czy rzeczywiste udziały kart inteligentnych są aktywne i zwracają prawidłowe ECM?

Serwer może przejść warstwę 1 i warstwę 2, całkowicie nie powodzeniu warstwy 3. Proces działa, port akceptuje Twoje połączenie, a uzgodnienie się kompletuje — ale każde żądanie ECM zostaje odrzucone, ponieważ abonament karty upstream wygasł dwa dni temu. To jest najbardziej powszechny scenariusz „mój CCcam działa, ale nic nie działa".

CCcam domyślnie używa portu TCP 12000 dla połączeń klientów C-line. Wbudowany interfejs sieciowy działa na porcie TCP 16001. Zapamiętaj oba.

Jak wygląda zdrozwy serwer CCcam na każdej warstwie

Na warstwie procesu: ps aux | grep CCcam zwraca wpis procesu nie-zombie. Na warstwie portu: ss -tlnp | grep 12000 pokazuje stan LISTEN. Na warstwie karty: strona interfejsu sieciowego /cards.html pokazuje aktywne karty z niedawnymi odpowiedziami ECM, a Twój dziennik pokazuje strumień wpisów „ECM granted" zamiast „ECM denied".

Czas odpowiedzi ECM to jeden z najlepszych wskaźników zastępczych dla zdrowia serwera. Poniżej 500ms jest zdrowsty. 500–1000ms to marginalne, ale funkcjonalne. Powyżej 1500ms stale oznacza, że coś jest nie tak — albo serwer jest przeciążony, albo upstream card share umiera, albo istnieje problem routingu sieciowego między serwerem a klientem.

Powszechne wskaźniki statusu i ich znaczenie

• Proces uruchomiony, port zamknięty: CCcam uruchomił się, ale zaraz po uruchomieniu się zawalił, lub wiąże się z innym portem niż się spodziewasz. Sprawdź konfigurację.
• Port otwarty, połączenia odrzucone: Biała lista IP poprzez dyrektywy ALLOW DENY: w CCcam.cfg blokuje Twój adres IP klienta.
• Port otwarty, uzgodnienie kompletne, brak deszyfrowania: Awaria warstwy karty. Zacznij od /tmp/CCcam.log.
• Proces w stanie zombie (Z w ps): Proces wydaje się żywy, ale nic nie robi. R

```html wymaga kill -9 wraz z czystym restartem — zwykły restart nie wyczyści zombie.

Metoda 1: Sprawdzenie Statusu Procesu CCcam i Portu za Pomocą Linii Poleceń

To jest twój punkt wyjścia. Zanim dotkniesz plików konfiguracyjnych lub interfejsów internetowych, potwierdź, co faktycznie działa na poziomie systemu operacyjnego.

Używanie ps i grep do Weryfikacji, czy Proces CCcam Jest Uruchomiony

Na standardowym serwerze Linux:

ps aux | grep CCcam

Zdrowa odpowiedź wygląda następująco:

root 1234 0.4 1.2 45320 6140 ? Ss 08:22 0:12 /usr/local/bin/CCcam

Jeśli otrzymasz tylko sam proces grep, CCcam nie jest uruchomiony. Na urządzeniach Enigma2 (Dreambox, VU+, Zgemma), ps busybox nie akceptuje flag aux — użyj po prostu:

ps | grep CCcam

Na Enigma2 plik binarny często nosi nazwę CCcam.out zamiast CCcam, więc szukaj obu. Zwróć też uwagę na procesy w stanie Z — to zombie. Pojawia się w wyniku, ale nic nie przetwarza. Zabij je za pomocą kill -9 <pid>.

Jeśli CCcam działa za pośrednictwem systemd:

systemctl status CCcam

Dla starszych konfiguracji init.d:

service CCcam status

Na Enigma2 menedżer softcam zwykle obsługuje to:

/etc/init.d/softcam status

Uwaga dotycząca Docker: Jeśli CCcam działa wewnątrz kontenera, ps aux na hoście nic nie pokaże. Musisz najpierw wejść do kontenera: docker exec -it <container_name> ps aux.

Używanie netstat lub ss do Potwierdzenia, że Port 12000 Nasłuchuje

ss -tlnp | grep 12000

Lub jeśli twój system nadal ma netstat:

netstat -an | grep 12000

Zdrowy wynik z ss:

LISTEN 0 128 0.0.0.0:12000 0.0.0.0:* users:(("CCcam",pid=1234,fd=5))

Jedno, na co należy zwrócić uwagę: jeśli CCcam wiąże się tylko z 0.0.0.0 (IPv4), ale twój klient łączy się przez IPv6, otrzymasz odmowę połączenia, nawet jeśli proces działa i port jest „otwarty". Sprawdź, czy :::12000 również pojawia się w wyniku ss, jeśli IPv6 jest zaangażowany.

Używanie Telnet do Testowania Surowej Łączności TCP do Portu CCcam

telnet <server-ip> 12000

Jeśli CCcam jest aktywny, otrzymasz surowy ciąg uzgodnieniowy binarny w ciągu sekundy lub dwóch — nie czytelny tekst, ale połączenie się otworzy i dane będą przepływać. Jeśli otrzymasz „Connection refused" natychmiast, port jest zamknięty. Jeśli się zawiesza i upływa limit czasu, coś blokuje połączenie na poziomie zapory lub NAT.

Odczytywanie Kodów Wyjścia i Czego Wskazują Nieudane Połączenia

„Connection refused" = port nie nasłuchuje. „Connection timed out" = upuszczenie zapory lub problem z routingiem. „Connected but no data" = port jest otwarty, ale CCcam może nie być zdrowy, lub biała lista IP dyskretnie upadła y ```nasza sesję po uzgodnieniu TCP. Każdy tryb niepowodzenia wskazuje na inne rozwiązanie.

Metoda 2: Użyj interfejsu sieciowego CCcam do monitorowania statusu na żywo

Po potwierdzeniu, że proces jest uruchomiony i port jest dostępny, interfejs sieciowy jest najlepszym narzędziem do sprawdzenia, co się faktycznie dzieje z kartami i klientami.

Włączanie i dostęp do interfejsu sieciowego CCcam (port 16001)

W /etc/CCcam.cfg upewnij się, że te linie są obecne:

ALLOW WEBIF: yes
WEBIF USERNAME: admin
WEBIF PASSWORD: yourpassword

Po zapisaniu uruchom ponownie CCcam. Następnie otwórz przeglądarkę na:

http://<server-ip>:16001

Jeśli port 16001 nie odpowiada, ale CCcam jest uruchomiony, dokładnie sprawdź dyrektywę ALLOW WEBIF i potwierdź, że nic innego nie jest powiązane z tym portem.

Interpretacja strony informacyjnej: Klienci, karty, statystyki ECM

Strona główna daje szybki przegląd — wersję CCcam, czas pracy, połączonych klientów i całkowite karty. Ale nie zatrzymuj się tutaj. Przydatne dane znajdują się na podstronach.

Przejdź do /cards.html, aby zobaczyć każdą kartę i udział, które serwer zna. Każdy wpis pokazuje typ karty, CAID, dostawcę, liczbę przeskoków i statystyki odpowiedzi ECM. Liczba przeskoków ma znaczenie: 0 oznacza fizyczną kartę wstawioną lokalnie, 1 oznacza bezpośredni udział linii C, 2+ oznacza karty rozpowszechniane dalej w łańcuchu.

Sprawdzanie aktywnych udziałów i połączonych klientów linii C

Przejdź do /clients.html, aby zobaczyć każdego klienta linii C aktualnie połączonego. Zobaczysz jego nazwę użytkownika, adres IP, czas trwania połączenia i ile żądań ECM wykonali. Klient pokazujący 0 żądań ECM po kilku minutach jest albo bezczynny, albo źle skonfigurowany.

Sprawdź /ecm.html, aby uzyskać czasy odpowiedzi ECM dla poszczególnych kanałów. Karta wymieniona w /cards.html z zerową liczbą odpowiedzi ECM w ciągu pięciominutowego okna jest faktycznie martwą, nawet jeśli wykazuje się jako połączona — karta lub upstream share nie zwraca CW.

Co strony wersji i konfiguracji ujawniają o Twojej konfiguracji

Strona /version.html pokazuje dokładną kompilację CCcam. Strona konfiguracji pokazuje aktywne dyrektywy bez konieczności dostępu SSH. Oba są przydatne do zdalnej diagnozy, gdy nie możesz łatwo uzyskać dostępu do powłoki.

Metoda 3: Zdiagnozuj kondycję serwera za pomocą plików dziennika CCcam

Plik dziennika to miejsce, w którym dowiadujesz się, dlaczego coś nie działa, a nie tylko że nie działa.

Lokalizowanie i śledzenie dziennika CCcam w czasie rzeczywistym

Na boxach Enigma2 domyślna ścieżka dziennika to /tmp/CCcam.log. W standardowych instalacjach Linux może to być /var/log/CCcam.log, ale można to skonfigurować w CCcam.cfg za pomocą dyrektywy LOG FILE:. Aby obserwować to na żywo:

tail -f /tmp/CCcam.log

Dodaj więcej szczegółowości, ustawiając to w konfiguracji:

LOG WARNINGS: yes

Jedna pułapka: na długotrwałych serwerach /tmp/CCca

m.log może zapełnić system plików. Gdy się to stanie, CCcam cicho przestaje pisać do dziennika, podczas gdy nadal przetwarza ECM. Więc jeśli plik dziennika nie został zaktualizowany przez godziny, ale proces jest „uruchomiony", sprawdź df -h /tmp przed założeniem, że dziennik jest dokładny.

Kluczowe wpisy w dzienniku potwierdzające zdrowy serwer

Szukaj tych:

• ECM granted — deszyfrowanie działa
• connected to — upstream C-line pomyślnie połączony
• card added — nowa karta lub udział stał się dostępny

Wzorce błędów wskazujące na awarie udostępniania kart

To są te, które chcesz złapać:

• ECM denied — karta nie ma uprawnień dla tego kanału
• card not found — brak dostępnej karty do obsługi kombinacji CAID/SID
• timeout waiting for ECM — upstream jest wolny lub martwy
• CW not found — słowo kontrolne nie zostało zwrócone; deszyfrowanie nie powiodło się
• connection refused — upstream C-line jest niedostępny

Używanie grep do filtrowania odrzuceń ECM, limitów czasu i ponownych połączeń

Nie czytaj pełnego dziennika ręcznie. Użyj ukierunkowanych grep:

grep -i "ecm denied" /tmp/CCcam.log | tail -20

grep -i "timeout" /tmp/CCcam.log | tail -20

grep -i "connection refused" /tmp/CCcam.log | tail -20

grep -i "card not found" /tmp/CCcam.log | tail -20

Uruchomienie wszystkich czterech z nich zajmuje około 30 sekund i mówi ci więcej niż pięć minut wpatrywania się w surowy dziennik.

Metoda 4: Test łączności C-line ze strony klienta

Testowanie ze strony klienta izoluje, czy masz do czynienia z problemem serwera czy lokalnym problemem odbiornika. Ten krok samodzielnie oszczędza dużo zmarnowanego czasu.

Wysyłanie testowego C-line przez Telnet z zdalnego klienta

Z dowolnego komputera Linux w sieci (lub zewnętrznie, jeśli port jest przekierowany):

telnet <cccam-server-ip> 12000

Żywy serwer CCcam odpowiada binarnym handshake'iem prawie natychmiast — w ciągu 200–300 ms w sieci LAN. Jeśli łączysz się zewnętrznie i telnet się zawiesza, problem dotyczy przekierowania portów lub reguły zapory sieciowej, a nie samego procesu CCcam. Powodzenie ping ICMP nic tutaj nie znaczy. Ping może wrócić w porządku, podczas gdy port 12000 jest całkowicie zablokowany — zawsze testuj rzeczywisty port.

Używanie OScam jako klienta do weryfikacji odpowiedzi serwera CCcam

Jeśli uruchamiasz OScam jako klienta skierowany na serwer CCcam, sprawdź /etc/oscam/oscam.server aby potwierdzić, że czytnik jest prawidłowo skonfigurowany. Interfejs sieciowy OScam (domyślny port 8888) pokazuje status czytnika, bieżące czasy odpowiedzi ECM w milisekundach i czy czytnik jest w stanie „OK" czy „ERROR".

Czytnik pokazujący „TIMEOUT" lub „NO_CARD" na stronie stanu OScam oznacza, że OScam osiąga serwer CCcam na th

e poziom TCP, ale nie otrzymujesz prawidłowych odpowiedzi CW — co wskazuje na awarię warstwy karty po stronie CCcam.

Sprawdzanie czasów odpowiedzi ECM jako metryki zdrowia serwera

Czasy odpowiedzi ECM są najwyraźniejszym wskaźnikiem zdrowia w czasie rzeczywistym:

Czas odpowiedzi ECM	Status
Poniżej 500ms	Zdrowy — normalna operacja
500ms – 1000ms	Marginalny — monitoruj uważnie
1000ms – 1500ms	Zdegradowany — prawdopodobnie problemy upstream
Powyżej 1500ms	Problematyczny — spodziewaj się zamrożenia

Co wysoka latencja ECM (>1000ms) mówi o serwerze

Konsekwentnie wysoka latencja ECM wskazuje na jedno z trzech: upstream share, na którym serwer polega, jest przeciążony, ścieżka sieciowa między twoim klientem a serwerem ma problemy z routingiem (uruchom traceroute, aby sprawdzić), lub sam serwer CCcam jest przeciążony zbyt wieloma współbieżnymi połączeniami klientów na kartę. Sprawdź liczbę hopów w /cards.html — jeśli jesteś na hopie 3 lub wyższym, każdy dodatkowy hop dodaje opóźnienie i niestabilność.

Rozwiązywanie problemów: Serwer pokazuje online, ale kanały ciągle się zamraża

To scenariusz, który prawie każdy inny przewodnik ignoruje. Serwer przechodzi wszystkie podstawowe kontrole — proces działa, port 12000 nasłuchuje, możesz nawet się połączyć — ale kanały ciągle się zamraża lub STB pokazuje "brak sygnału" lub "nie znaleziono CA".

Karta obecna, ale błędy ECM — możliwe przyczyny

Karta pojawia się w /cards.html, ale kanał się nie odszyfruje. Pierwsze sprawdzenie: czy żądasz SID, do którego karta ma faktycznie uprawnienia? Karta może być w pełni funkcjonalna, mając zero uprawnień do określonego kanału lub pakietu. Strona /cards.html pokazuje autoryzowane SID — jeśli SID kanału nie znajduje się na liście, karta dosłownie nie może go odszyfrować, niezależnie od tego, jak zdrowy jest serwer.

Sprawdzanie uprawnień karty i ważności subskrypcji

Uprawnienia karty są związane z fizyczną subskrypcją, a nie z oprogramowaniem CCcam. Jeśli subskrypcja karty wygasła, CCcam ciągle będzie pokazywać kartę jako "obecną" — ale każdy ECM dla kanału premium będzie zwracany z odmową. Dziennik będzie pokazywać ECM denied dla tych kanałów. Nie ma poprawki oprogramowania dla wygasłej subskrypcji.

Przeciążony serwer: zbyt wielu klientów na kartę

CCcam ma dyrektywę SHARE LIMIT: w CCcam.cfg, która ogranicza jednoczesne żądania ECM. Jeśli masz 50 klientów walących na jedną kartę, żądania ustawiają się w kolejce i wiele z nich zostaje porzuconych lub upłynie limit czasu. Sprawdź /clients.html pod kątem całkowitej liczby aktywnych połączeń i porównaj z skonfigurowanym limitem udziału. Zmniejsz podłączonych klientów lub dodaj inny upstream share.

Problemy ze ścieżką sieciową między serwerem a klientem

Dwu-NAT to częsty sprawca, który łatwo przeoczyć. Połączenia TCP nawiązują się prawidłowo, ale pakiety keepalive gdzieś w środku są odrzucane, co powoduje, że serwer wyświetla klienta jako połączonego, podczas gdy żadne rzeczywiste dane nie przepływają. Uruchom traceroute z klienta na serwer i poszukaj asymetrycznych ścieżek lub middle-boxów, które mogą wykonywać inspektowanie stateful na portach niestandardowych.

Zwróć również uwagę na niepowodzenia synchronizacji NTP. Handshake kryptograficzny CCcam jest wrażliwy na czas — jeśli zegar serwera jest przesunięty o więcej niż kilka minut, połączenia klientów są odrzucane, nawet jeśli wszystko inne wygląda prawidłowo. Uruchom date na serwerze i kliencie, aby porównać znaczniki czasu.

Zapora sieciowa i NAT blokujące ruch CCcam

Niektórzy dostawcy usług internetowych uruchamiają głęboką inspekcję pakietów i specjalnie oznaczają lub ograniczają wzorzec handshake'u protokołu CCcam na porcie 12000. Jeśli wszystko działa w Twojej sieci LAN, ale zewnętrzni klienci nie mogą się połączyć pomimo prawidłowego przekierowania portów, to jest prawdopodobnie przyczyną. Rozwiązaniem jest zmiana portu nasłuchiwania CCcam w CCcam.cfg:

PORT: 443

Port 443 lub 8080 zazwyczaj omijają reguły DPI, ponieważ są traktowane jako standardowy ruch sieciowy. Zaktualizuj regułę przekierowania portów w routerze i zaktualizuj wszystkie C-linie klienta, aby odzwierciedlały nowy port. Zwróć uwagę, że port 443 może powodować konflikt z istniejącą usługą HTTPS — sprawdź wcześniej za pomocą ss -tlnp | grep 443.

Sprawdź również swoje dyrektywy ALLOW DENY: w CCcam.cfg. Błędnie skonfigurowana biała lista IP może spowodować, że port 12000 zaakceptuje połączenie TCP, a następnie natychmiast je zamknie, co z zewnątrz wygląda jak problem z przerywanym połączeniem.

Automatyzacja kontroli statusu CCcam za pomocą skryptów i monitorowania

Ręczna kontrola statusu CCcam działa dla natychmiastowego rozwiązywania problemów, ale na serwerze bez nadzoru potrzebujesz automatyzacji. Zadanie cron co pięć minut, które sprawdza zarówno kondycję procesu, jak i portu, będzie przechwytywać awarie zanim użytkownicy zaczną narzekać.

Pisanie skryptu Bash do sprawdzania kondycji procesu i portu CCcam

#!/bin/bash
LOGFILE="/var/log/cccam_monitor.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
HOST="localhost"
PORT="12000"
EMAIL="[email protected]"
# Check process
if ! ps aux | grep -v grep | grep -q "CCcam"; then echo "$TIMESTAMP - ALERT: CCcam process not found" >> "$LOGFILE" echo "CCcam process down at $TIMESTAMP" | mail -s "CCcam DOWN" "$EMAIL" exit 1
fi
# Check port
if ! nc -z -w3 "$HOST" "$PORT"; then echo "$TIMESTAMP - ALERT: Port $PORT not responding" >> "$LOGFILE" echo "CCcam port $PORT unreachable at $TIMESTAMP" | mail -s "CCcam Port Down" "$EMAIL" exit 1
fi
echo "$TIMESTAMP - OK: CCcam process running, port $PORT accepting connections" >> "$LOGFILE"

Zapisz to jako /usr/local/bin/check_cccam.sh i uczynić to plikiem wykonywalnym: chmod +x /usr/local/bin/check_cccam.sh.

Konfiguracja zadania Cron do okresowych kontroli statusu

Dodaj to do swojej crontab (crontab -e):

*/5 * * * * /usr/local/bin/check_cccam.sh >> /var/log/cccam_monitor.log 2>&1

To uruchamia się co 5 minut. Dostosuj interwał w zależności od tego, jak szybko musisz wykryć awarie. Jeśli chcesz powiadomienia webhook zamiast poczty e-mail (na przykład powiadomienia Slack lub Telegram), zastąp polecenie mail następującym:

curl -s -X POST "https://your-webhook-url" -d "payload=CCcam is down"

Używanie nc (netcat) jako lekkiego narzędzia do sprawdzania portów

nc -z -w3 localhost 12000 jest czystsze niż telnet do zautomatyzowanych kontroli. Flaga -z uruchamia tryb zero-I/O (tylko testuje łączność bez wysyłania danych), a -w3 ustawia limit czasu 3 sekund. Kończy się kodem 0 w przypadku powodzenia i 1 w przypadku błędu, co jest dokładnie tym, czego potrzebujesz do logiki warunkowej w skrypcie bash.

Alerty za pośrednictwem poczty e-mail lub webhook, gdy CCcam przestaje działać

Na urządzeniach Enigma2 z ograniczonymi narzędziami powłoki polecenie mail i nc mogą być niedostępne. Zamiast tego użyj wget jako sprawdzenia żywotności:

wget -q --spider http://localhost:16001
if [ $? -ne 0 ]; then echo "CCcam web interface down" >> /tmp/cccam_monitor.log
fi

To nie sprawdza warstwy karty, ale jest rozsądnym sprawdzeniem żywotności, gdy zestaw narzędzi jest ograniczony do tego, co jest dostępne w środowisku Enigma2 busybox.

Dzięki sprawdzeniu procesu, sprawdzeniu portu, sprawdzeniu interfejsu sieciowego i monitorowaniu dziennika, masz teraz wszystko, czego potrzebujesz, aby sprawdzić stan serwera CCcam na każdej warstwie — od tego, czy plik binarny w ogóle działa, aż do tego, czy poszczególne karty zwracają prawidłowe CW. Bez zgadywania, bez „uruchomienia ponownie i nadziei".