Loading...

OScam WebIf: Jak monitorować aktywnych czytników i klientów (Przewodnik 2026)

Jeśli masz uruchomiony OScam i otwarte WebIf w zakładce przeglądarki, ale nadal nie możesz stwierdzić, czy twoje czytniki rzeczywiście coś robią, nie jesteś sam. Ten przewodnik naoscam webif: jak monitorować aktywnych czytników i klientów przechodzi przez każdą kolumnę na stronie Status, co oznaczają kody logów i który plik konfiguracyjny otworzyć, gdy coś jest zepsute. Uruchamiałem OScam na wszystkim, od Raspberry Pi po stary Vu+ Solo2, a WebIf mówi ci prawie wszystko, co potrzebujesz — musisz tylko wiedzieć, jak to odczytać.

To nie jest samouczek dotyczący konfiguracji. Zakładam, że pliki oscam.conf, oscam.server i oscam.user już istnieją, a demon działa. Celem jest diagnoza: mapowanie tego, co jest na ekranie, do konkretnej linii w pliku konfiguracyjnym, abyś mógł to naprawić zamiast zgadywać.

Włącz OScam WebIf zanim będziesz mógł cokolwiek monitorować

Duża część osób szukających tego tematu ma właściwie WebIf, które w ogóle się nie ładuje. Zanim przejdziemy do odczytywania kolumn, upewnijmy się, że strona się otwiera. Oto minimalny działający[webif] blok dla oscam.conf:

[webif]

httprefresh kontroluje, jak często strona automatycznie się przeładowuje, w sekundach. Ustaw to na 0, gdy odczytujesz log lub tabelę statusu i nie chcesz, aby strona skakała pod twoim kursorem — robię to ciągle, gdy próbuję złapać ponowne połączenie w akcji.

Jeśli dodasz+ przed portem, jakhttpport = +8888, OScam przełącza się na HTTPS. To wymaga plikuoscam.pem znajdującego się w tym samym katalogu konfiguracyjnym. Bez niego demon odmówi związania, a WebIf po prostu się nie uruchomi — żadny dialog błędu, żadna oczywista wskazówka, tylko odmowa połączenia w twojej przeglądarce.

Ścieżki konfiguracyjne nie są uniwersalne i to sprawia problemy większej liczbie osób, niż powinno. W obrazach Enigma2 zazwyczaj znajdziesz rzeczy pod/etc/tuxbox/config/ lub/etc/tuxbox/config/oscam/. Na ogólnym systemie Linux zazwyczaj jest to/usr/local/etc/. Niektóre wersje OpenWrt przechowują to w/var/etc/. Zamiast zgadywać, sprawdź skrypt inicjalizacyjny lub jednostkę systemd dla-c flagi — to mówi ci dokładnie, który katalog OScam rzeczywiście odczytuje. Widziałem ludzi edytujących oscam.conf przez dwadzieścia minut, zastanawiając się, dlaczego nic się nie zmienia, tylko po to, by odkryć, że działający proces został uruchomiony z-c /etc/oscam2/ zamiast.

Potwierdź, że twoja wersja rzeczywiście ma wsparcie dla WebIf skompilowane:

oscam --build-info | grep -i webif

Jeśli to wraca puste, demon działa dobrze — po prostu port nigdy nie nasłuchuje, ponieważ WEBIF nie został uwzględniony w czasie kompilacji. To jest powszechny powód "pustej strony", którą ludzie mylą z problemem konfiguracyjnym. Innym powszechnym powodem jest to, że port jest już używany przez drugą instancję OScam (więcej o tym później) lub inną usługę.

Odczytywanie strony Status: Co oznacza każda kolumna

To jest część, której prawie nikt nie wyjaśnia poprawnie. Większość opisów zrzuca zrzuty ekranu strony Status i mówi "oto twoje czytniki", nie mówiąc ci, co oznacza CARDOK w porównaniu do CONNECTED i IDLE. Więc przejdźmy przez kolumny, ponieważ to jest prawdziwa odpowiedź na oscam webif: jak monitorować aktywnych czytników i klientów.

Klient vs czytnik vs wiersze proxy

Każdy wiersz na stronie Status ma literę typu.c jest klientem — wpisem z oscam.user łączącym się w celu żądania ECM.p jest czytnikiem proxy — połączeniem sieciowym do innego serwera cardsharing (cccam, newcamd, camd35, cs378x, gbox).r jest lokalnym czytnikiem — fizyczną kartą przez PCSC lub czytnikiem szeregowym, takim jak Smargo.m jest wierszem monitorującym, który jest po prostu własnym portem monitorującym OScam.

Jedna rzecz, która myli ludzi: peer skonfigurowany po obu stronach — karmisz ich, a oni karmią ciebie — pojawia się dwukrotnie. Raz jako wiersz klienta, raz jako wiersz czytnika. Jeśli policzysz to jako dwie oddzielne osoby, przeliczasz swoje aktywne połączenia.

Kolumna Status

To jest pole, na które ludzie patrzą najdłużej. Oto, co każdy stan właściwie oznacza w praktyce:

  • POŁĄCZONY — gniazdo jest otwarte i uwierzytelnione, ale to samo w sobie nie mówi, czy dane płyną.
  • LOGOWANIE — w trakcie handshake, powinno być przejściowe. Jeśli utknie tutaj, prawdopodobnie dane uwierzytelniające lub wersja protokołu są błędne.
  • BEZCZYNNY — połączony, uwierzytelniony, po prostu nie obsługujący ECM w tej chwili. Całkowicie normalne.
  • WYŁĄCZONY — niepołączony. Dla czytnika sprawdź ścieżkę sieciową i dane uwierzytelniające. Dla lokalnego czytnika sprawdź, czy karta jest rzeczywiście włożona.
  • KARTA OK — specyficzne dla lokalnych i proxy czytników: karta została odczytana pomyślnie, a OScam ma jej ATR i uprawnienia.
  • ROZŁĄCZONY — był połączony, teraz nie jest. W połączeniu z rosnącą liczbą ponownych połączeń wskazuje to na problem z siecią lub keepalive.

Czytnik siedzący w KARTA OK z stale rosnącą liczbą ECM jest zdrowy — to jest obraz, którego chcesz. Czytnik utkniony w POŁĄCZONY z zerową liczbą wysłanych ECM jest osiągalny, ale nigdy nie jest faktycznie wybierany przez load balancer, zazwyczaj z powodu niezgodności CAID lub identyfikatora, lub dlatego, że inny czytnik jest szybszy i zawsze wygrywa wyścig. Czytnik, który ciągle przełącza się między POŁĄCZONY a WYŁĄCZONY co minutę lub dwie, ma problem z siecią lub danymi uwierzytelniającymi, a nie problem z kartą.

AU: kolumna, którą wszyscy źle interpretują

AU oznacza Auto Update — czy to połączenie ma prawo do przesyłania EMM, aby utrzymać subskrypcję karty na bieżąco.WŁĄCZONE oznacza, że EMM są dozwolone.WYŁĄCZONE oznacza, że są całkowicie zablokowane. Jeśli zamiast tego widzisz wartość CAID, AU jest ograniczone tylko do tego CAID — przydatne, gdy klient ma wiele kart za sobą, ale chcesz tylko automatycznych aktualizacji dla jednej. Ustawia się to za pomocąau = 1 w oscam.user, lubau = aby powiązać aktualizacje z konkretnym czytnikiem.

Czas ECM, Ostatni kanał i wskaźnik LB

Czas ECM mierzy się w milisekundach i jest to najważniejsza liczba wydajności na stronie. Poniżej około 300 ms i zmiana kanału wydaje się natychmiastowa. Między 300 a 800 ms jest użyteczne, ale zauważysz opóźnienie przed wyczyszczeniem obrazu. Po przekroczeniu 1000 ms konsekwentnie zobaczysz widoczne zacięcia przy zmianie kanału, a jeśli wzrośnie powyżej twojegoecmtimeout ustawienia (zwykle 3000 ms domyślnie), OScam całkowicie porzuca ten ECM.

Porównywanie czasu ECM między czytnikami, które mają ten sam CAID, to dokładnie sposób, w jaki decydujesz o priorytecie czytnika dla balancera obciążenia — powinien być preferowany najszybszy, a silnik statystyk OScam śledzi to automatycznie, jeśli lb_mode jest włączony (więcej na ten temat za chwilę).

Ostatni kanał pokazuje jakoCAID:provid:sid w formacie szesnastkowym. Bez plikuoscam.srvid w swoim katalogu konfiguracyjnym, to wszystko, co kiedykolwiek zobaczysz — surowe liczby, bez nazw kanałów. Umieść odpowiedni plik oscam.srvid (lub oscam.srvid2) w tym miejscu, a WebIf przetłumaczy te identyfikatory na rzeczywiste nazwy kanałów. Widziałem, jak ludzie zakładają, że WebIf jest uszkodzony, po prostu dlatego, że ten plik nigdy nie został dodany.

Czas bezczynności i dlaczego klient może być połączony z zerowym ECM

Kolumna Idle liczy sekundy od ostatniego żądania z tego połączenia. Klient może być w stanie CONNECTED przez godziny, z czasem bezczynności rosnącym i zerowym przetworzonymi ECM — to po prostu oznacza, że nie zmienili kanału lub aktualnie nie oglądają nic, co zostało odszyfrowane przez twoją skrzynkę. To nie jest błąd, to po prostu cisza.

Hitów pamięci podręcznej i czytników cache-ex

To jest część, którą prawie każdy inny przewodnik pomija, i powoduje prawdziwe zamieszanie. Jeśli uruchamiasz wymianę pamięci podręcznej (cacheex), niektóre czytniki istnieją wyłącznie po to, aby dzielić się odpowiedziami ECM z pamięci podręcznej między serwerami — mogą nigdy nie przetwarzać ani jednego "prawdziwego" ECM w stosunku do karty. Ich liczniki pozostają na zerze na zawsze, i to jest zamierzone, a nie uszkodzony czytnik. Nie gonić za fantomowym problemem na czytniku tylko cacheex, który pokazuje zero ECM; sprawdź jego ustawienie trybu cacheex w oscam.server zamiast zakładać, że jest martwy.

Monitorowanie logów na żywo: Filtrowanie szumów, aby znaleźć nieudany ECM

Strona Status informuje cię o stanie rzeczy w tej chwili. Log mówi ci, dlaczego. Oto prawdziwa linia ECM z adnotacjami, pod względem formatu (wartości są ilustracyjnymi miejscami, nie związanymi z żadnym rzeczywistym systemem kart):

2026/07/14 21:14:02 c (klient) nazwa_użytkownika ECM 0100:000000 sid 4A21 pid 0834 z reader1 (0 ms) rc=1 (znaleziono)

Rozkładając to: caid to0100, provid to000000, sid to identyfikator usługi4A21, pid to identyfikator strumienia elementarnego0834, czytnik, który odpowiedział, toreader1, arc=1 (znaleziono) to kod zwrotu — co oznacza, że ECM zostało pomyślnie odszyfrowane. Liczba w nawiasach przed rc to czas odpowiedzi w milisekundach, który jest tą samą liczbą odzwierciedloną w kolumnie Czas ECM na stronie Status dla tego czytnika.

Kody zwrotu, które faktycznie zobaczysz

  • znaleziono — pomyślnie odszyfrowane, wszystko w porządku.
  • nie znaleziono — każdy czytnik, którego próbowałeś, nie obsługuje tej kombinacji CAID/provid. Sprawdź stronę Uprawnień, aby potwierdzić.
  • cache1 / cache2 / cache3 — odpowiedź pochodziła z pamięci podręcznej, a nie z dotykania karty w ogóle. To jest normalne i szybkie — to także powód, dla którego czytnik może wyglądać na "bezczynny" na Status, podczas gdy kanał jest odszyfrowywany poprawnie.
  • timeout — czytnik zajął zbyt dużo czasu na odpowiedź. Nie podnoś tylko ecmtimeout, aby zamaskować to — sprawdź rzeczywistą latencję sieciową do tego czytnika i rozważ, czy ecmtimeout (domyślnie często 3000 ms) jest realistyczny dla tego połączenia.
  • odrzucony — prawie zawsze niezgodność grupy, CAID lub identyfikatora między oscam.user a oscam.server. Grupa klienta w oscam.user musi pokrywać się z grupą czytnika, w przeciwnym razie żądanie nigdy nie zostanie przekazane.

Poziomy debugowania — użyj maski bitowej, a nie 255

Poziomy debugowania OScam to maska bitowa, a ustawienie debug na 255 zrzuca wszystko naraz. Na zajętym serwerze to powódź, a na skrzynce z małą pamięcią RAM, pisanie do pamięci flash może naprawdę zapełnić dysk lub uruchomić ponowne uruchomienie watchdog. W ten sposób zablokowałem sesję na starym dekoderze z chipem flash 512 MB — nie rób tego.

Użyj konkretnych bitów, których potrzebujesz:2 dla aktywności czytnika/ATR,4 dla połączeń klientów,16 dla obsługi EMM,64 dla przepływu ECM. Jeśli ścigasz kanał, który nie chce się deszyfrować,debug = 64 sam w sobie zazwyczaj wystarcza. Ustawlogfile na wskazanie gdzieś w rzeczywistym systemie plików, a nie na flashu, ustawmaxlogsize aby to ograniczyć, a debug wróć do 0 w momencie, gdy znajdziesz odpowiedź.

Strona Live Log w WebIf pozwala filtrować według pojedynczego klienta lub nazwy czytnika zamiast przeszukiwać cały strumień, co jest znacznie szybsze niż przeszukiwanie ogromnego pliku oscam.log, gdy już wiesz, które połączenie działa nieprawidłowo.

Stan Czytnika: Uprawnienia, Karty i Widok Balansowania Obciążenia

Naj szybszym sposobem na odpowiedź na pytanie "czy moja karta jest rzeczywiście aktywna" jest widok Uprawnień na stronie Czytników. Wymienia każdy CAID, identyfikator dostawcy, klasę i datę wygaśnięcia, które karta zgłasza. Dla lokalnego czytnika — PCSC, wewnętrzny slot, Smargo — pochodzi to bezpośrednio z samej karty. Dla czytnika sieciowego (połączenie proxy cccam lub newcamd) widzisz to, co reklamuje serwer upstream, co może, ale nie musi, odpowiadać rzeczywistej fizycznej karcie po ich stronie.

Widziałem, jak czytnik siedział na CARDOK przez tygodnie, czas ECM wyglądał całkowicie zdrowo, a rzeczywiste uprawnienie wygasło dwa dni wcześniej — karta po prostu nadal odpowiadała na ECM-y dla CAID-ów, do których nie miała już praw, zwracając not-found zamiast błędu, który zauważyłbyś w Statusie. Jedynym miejscem, w którym to się pojawia, jest kolumna daty wygaśnięcia na stronie Uprawnień.

Strona statystyk Balansowania Obciążenia to historia, a nie widok na żywo

To jest część, którą większość konkurencyjnych przewodników całkowicie pomija, i dlatego idealnie wyglądający czytnik może mieć zero ECM-ów. Strona balansu obciążenia pokazuje skumulowane statystyki wydajności dla każdego czytnika — średni czas ECM, liczba niepowodzeń — a OScam używa tej historii, aby zdecydować, który czytnik będzie próbował jako pierwszy dla danej kombinacji CAID/dostawca. Czytnik, który jest w porządku teraz, ale ma złą historię sprzed godziny, będzie nadal przegrywał wyścig z czytnikiem z lepszymi osiągami, aż wystarczająco dużo danych się zmieni.

Istotne klucze w oscam.conf:

  • lb_mode = 1 — włącza balansowanie obciążenia, priorytetując najszybszy czytnik.
  • lb_save — zapisuje statystyki na dysku, aby przetrwały restart.
  • lb_nbest_readers — ile najlepszych czytników próbować na żądanie.
  • lb_retrylimit — milisekundy, zanim OScam zrezygnuje z pierwszego czytnika i spróbuje następnego. To bezpośrednio wpływa na czas ECM, który widzisz w Statusie: jeśli lb_retrylimit jest niższy niż typowy czas odpowiedzi czytnika, ten czytnik prawie nigdy nie wygra, nawet jeśli ostatecznie odpowiedziałby dobrze.
  • lb_stat_cleanup — godziny, zanim stare statystyki przestaną być aktualne.

Jeśli naprawisz wolny czytnik — powiedzmy, że przeniosłeś go na lepszą ścieżkę sieciową — jego stare statystyki nadal będą działać przeciwko niemu. Zresetuj statystyki balansu obciążenia z WebIf po naprawie, w przeciwnym razie OScam nadal będzie unikał czytnika, który już nie jest wolny. A jeślilb_save przeniosło statystyki z poprzedniej konfiguracji sprzętowej, możesz skończyć z OScam, który nadal kieruje ECM-y do czytnika, który już nie istnieje — to objawia się jako ECM-y cicho nieudane bez oczywistej przyczyny, aż sprawdzisz stronę balansu obciążenia i zobaczysz fantomowy wpis.

Automatyzacja Monitorowania: HTTP API, JSON Status i Narzędzia Zewnętrzne

Prawie nikt nie porusza tej części, ale OScam udostępnia API czytelne maszynowo przez WebIf, więc nie musisz skrobać HTML, aby sprawdzić stan czytnika. Użyj curl:

curl --user admin:twoje_hasło_tutaj "http://192.168.1.50:8888/oscamapi.json?part=status"

Odpowiedź to obiekt JSON z tablicą klientów — każdy wpis zawiera typ, nazwę, protokół, stan połączenia i ostatni kanał, strukturalnie te same informacje, co strona Status, ale możliwe do przetworzenia przez skrypt. Jest teżpart=readers dla danych specyficznych dla czytnika. To jest naprawdę przydatne, jeśli chcesz co pięć minut sprawdzać stan czytnika z crona i uruchamiać alert, gdy czytnik przestaje działać.

Zanim podłączysz to do czegokolwiek, zabezpiecz to: stwórz osobne, ograniczone konto WebIf zamiast ponownie używać swojego loginu administratora i ograniczhttpallowed tylko do adresu IP maszyny wykonującej polling. WebIf może zrestartować demona i przepisać pliki konfiguracyjne — to nie jest coś, co powinno być szeroko udostępniane tylko dlatego, że chcesz mieć pulpit nawigacyjny.

Do monitorowania na poziomie procesu — czy OScam w ogóle działa, a nie tylko "czy czytnik jest podłączony" — polegaj na systemd (systemctl status oscam) lub zachowaniu skryptu init.d przy restarcie po awarii, a nie na WebIf, ponieważ WebIf oczywiście nie może ci nic powiedzieć, jeśli cały proces jest wyłączony.

Typowe objawy monitorowania i co one naprawdę oznaczają

Oto tabela objawów i rozwiązań, ponieważ to zazwyczaj jest to, po co ludzie tu przychodzą, gdy szukają oscam webif: jak monitorować aktywne czytniki i klientów.

Objaw na stronie StatusPrawdopodobna przyczynaGdzie to naprawić
Klient pokazuje POŁĄCZONY, nic nie jest deszyfrowaneNiezgodność grupy między użytkownikiem a czytnikiem lub filtr CAID/ident blokujący żądanieoscam.user (grupa), oscam.server (grupa, caid, ident)
Czytnik pokazuje CARDOK, każdy ECM wraca jako nie znalezionyKarta faktycznie nie obsługuje tego providera lub uprawnienia wygasłySprawdź datę wygaśnięcia na stronie Uprawnień
Czas ECM stale rośnie, aż pudełko się zawiesiZator upstream lub zanieczyszczenie pamięci podręcznejSprawdź ustawienia cacheex, rzeczywistą latencję sieci czytnika
Klienci rozłączają się i łączą co kilka minutNiezgodność keepalive lub NAT zrywa bezczynne sesjecccam keepalive = 1, cccversion, inactivitytimeout w oscam.conf
Strona Status jest pusta lub pokazuje tylko wiersz monitorowaniaOScam uruchomiono z katalogiem konfiguracyjnym, który nie ma zdefiniowanych użytkowników, lub błędna ścieżka -cSprawdź flagę -c skryptu init w odniesieniu do rzeczywistej lokalizacji oscam.user
Licznik ECM czytnika pozostaje na zerzeWszystkie odpowiedzi pochodzą z pamięci podręcznej lub czytnik przegrywa każdy wyścig z równoważeniem obciążeniaStrona statystyk równoważenia obciążenia; niekoniecznie błąd

Kilka przypadków brzegowych, które warto bezpośrednio zaznaczyć. Jeśli uruchamiasz dwie instancje OScam jednocześnie — jedna uruchomiona przez obraz pudełka, druga uruchomiona ręcznie — każda ma swój własny WebIf na innym porcie i łatwo jest całkowicie monitorować niewłaściwą, zastanawiając się, dlaczego twoje zmiany nigdy nie wydają się mieć efektu. Sprawdźps aux | grep oscam jeśli strona Status wydaje się utknęła w czasie.

Sprawdź także swój zegar systemowy. Jeśli NTP nie zsynchronizował się od ostatniego restartu, zobaczysz fałszywe czasy logowania, ujemne timery bezczynności i — jeśli uruchamiasz HTTPS na WebIf — błędy walidacji certyfikatu, ponieważ okno ważności oscam.pem zależy od tego, aby zegar był mniej więcej poprawny.

Co oznacza kolumna AU na stronie statusu OScam?

AU oznacza Auto Update, odnosząc się do obsługi EMM. ON oznacza, że klient lub czytnik ma prawo wysyłać EMM, które aktualizują subskrypcję karty. OFF oznacza, że EMM są zablokowane. Wartość CAID zamiast ON/OFF oznacza, że AU jest ograniczone tylko do tego CAID. Ustaw to za pomocąau = 1 w oscam.user, lub powiąż to z konkretnym czytnikiem za pomocąau =<readername>. Zauważ, że AU=ON na czytniku proxy nic nie osiąga, chyba że serwer upstream faktycznie przesyła EMM przez połączenie.

Dlaczego mój czytnik pokazuje POŁĄCZONY, ale nigdy nie przetwarza żadnych ECM-ów?

Trzy zwykłe podejrzane: równoważnik obciążenia preferuje inny, szybszy czytnik (sprawdź stronę statystyk równoważnika obciążenia, aby poznać powód); lista CAID lub identyfikatorów czytnika nie pasuje do żądanego kanału; lub grupa użytkownika żądającego w oscam.user nie pokrywa się z grupą czytnika w oscam.server. Wszystkie trzy wyglądają identycznie na stronie Status i stają się widoczne w logu na poziomie debugowania 64.

Jaki jest dobry czas ECM w OScam WebIf?

Poniżej około 300 ms jest komfortowo, a zmiana kanału wydaje się natychmiastowa. Pomiędzy 300 a 800 ms jest użyteczne, ale zauważysz lekką pauzę przy zmianie kanału. Stałe wartości powyżej 1000 ms powodują widoczne zacięcia, a domyślny ecmtimeout OScam (zwykle 3000 ms) to punkt, w którym ECM jest całkowicie porzucany. Lokalne czytniki kart są często wolniejsze na ECM niż trafienie z pamięci podręcznej w pobliżu, więc wyższa liczba na lokalnym czytniku nie jest automatycznie błędem.

Jak mogę zobaczyć, jaki kanał aktualnie ogląda klient?

Kolumna Ostatni Kanał na stronie Status pokazuje CAID:provid:srvid, plus rozwiązana nazwa kanału, jeśli oscam.srvid (lub oscam.srvid2) istnieje w twoim katalogu konfiguracyjnym. Bez tego pliku OScam może wyświetlać tylko surowe identyfikatory hex, co jest powodem, dla którego kolumna wygląda jak bezsensowne liczby w wielu instalacjach — to brakujący plik, a nie błąd.

Czy mogę monitorować OScam z zewnątrz mojej sieci domowej bezpiecznie?

Technicznie tak, ale nie przekierowuj portu 8888 bezpośrednio do internetu. Użyj httpallowed, aby dodać do białej listy konkretne adresy IP źródłowe, ustaw silne httppwd, włącz HTTPS z wiodącym + na porcie oraz oscam.pem, i preferuj dostęp do urządzenia przez VPN lub tunel SSH. WebIf ma pełną moc restartu i edycji konfiguracji nad demonem, więc wystawiony WebIf jest w rzeczywistości pełnym kompromitowaniem urządzenia.

Dlaczego klienci ciągle się rozłączają i łączą ponownie co kilka minut?

Zwykle jest to niezgodność keepalive lub limit czasu NAT. Sprawdź, czy cccam keepalive = 1 jest ustawione po obu stronach, zweryfikuj, czy cccversion to wartość, którą partner rzeczywiście akceptuje, i sprawdź, czy router upstream nie zrywa bezczynnych sesji TCP. Sprawdź również inactivitytimeout w oscam.conf — zbyt niska wartość rozłączy klientów, którzy po prostu nie aktywnie zmieniają kanały.

Jaka jest różnica między wierszem klienta a wierszem czytnika/proxy?

Klienci to wpisy z oscam.user łączące się, aby żądać ECM-ów z twojego urządzenia. Czytniki i proxy to wpisy z oscam.server, z którymi twoje urządzenie łączy się, lub lokalna karta, z którą rozmawia bezpośrednio. Strona Status łączy oba typy razem — identyfikuj każdy z nich po literze typu wiersza i kolumnie protokołu. Partner skonfigurowany po obu stronach relacji pojawia się dwukrotnie: raz jako wiersz klienta, raz jako wiersz czytnika.

Jak mogę zmniejszyć hałas logów OScam bez utraty użytecznych informacji?

Utrzymuj debug na poziomie 0 w normalnej pracy i zwiększaj go tylko podczas aktywnej diagnostyki. Użyj konkretnego poziomu bitmaski zamiast dumpować wszystko na 255: 64 dla przepływu ECM, 16 dla obsługi EMM, 2 dla aktywności czytnika/ATR, 4 dla połączeń klientów. Wskaźnik logfile ustaw na ścieżkę w rzeczywistym systemie plików, a nie na pamięci flash, ustaw maxlogsize, aby ograniczyć wzrost, i użyj filtru per-client lub per-reader na stronie Live Log zamiast przewijać przez cały strumień.