MgCamd Share Not Opening: Przewodnik naprawy (OSCam/CCcam)

Jeśli trafiłeś tutaj szukającmgcamd: share not opening решение, już wiesz, jakim piekłem jest oglądanie zielonego statusu połączenia, podczas gdy twoje kanały pozostają całkowicie czarne. Linia wygląda na połączoną. MgCamd nie zawiesza się. Ale nic nie dekoduje. Ten przewodnik przechodzi przez rzeczywiste przyczyny w kolejności prawdopodobieństwa — zaczynając od twojej lokalnej konfiguracji i kończąc na serwerze.

To nie jest przewodnik "wklej ten szablon". Każda sekcja poniżej zakłada, że już masz uruchomione MgCamd i dane uwierzytelniające w ręku — po prostu nie możesz uzyskać słowa karty.

Co oznacza 'Share Not Opening' w MgCamd

Fraza "share not opening" opisuje konkretny stan awarii, który jest zupełnie inny niż błąd logowania. MgCamd pomyślnie uwierzytelnia się na serwerze newcamd — użytkownik, hasło, port wszystko się zgadza — ale gdy twoje urządzenie dostraja się do kanału i wysyła ECM (Entitlement Check Message), nie wraca żadne odszyfrowane słowo kontrolne (dcw). Kanał jest zaszyfrowany. Pętla dekodowania nigdy się nie zaczyna. Czarny ekran.

Większość przewodników myli "nie można się połączyć" z "share not opening" i dlatego są bezużyteczne w tym problemie.

Połączenie działa vs. dekodowanie nieudane — dwa różne problemy

Błąd logowania wygląda jak linia, która natychmiast się zrywa lub nigdy nie pokazuje się jako połączona. MgCamd zarejestruje coś takiego jaklogin failed lub po prostu wielokrotnie próbuje się ponownie połączyć. Zobaczysz, jak połączenie skacze w/var/log/mgcamd.log lub gdziekolwiek twoje obrazy to zapisują.

Błąd dekodowania jest cichszy. Linia wydaje się być aktywna. MgCamd uważa, że jest połączony. Ale ECM, które twoje urządzenie wysyła, pozostaje bez odpowiedzi. Kanał nigdy się nie otwiera, ponieważ nikt nie zwraca ważnego CW na bieżący okres szyfrowania — który zmienia się co 10 sekund w większości systemów.

Czytanie logu MgCamd: żądanie ECM, odpowiedź i znaczniki czasu

Pierwsza rzecz: zwiększ szczegółowość. W/var/keys/mg_cfg znajdź linię debug i ustaw ją na poziom 3:

G: { 03 }

Z tym włączonym, zdrowe dekodowanie wygląda mniej więcej tak w logu:

[mgcamd] ecm dla caid 0x0500 pid 0x0136 provider 0x032820

Uszkodzone wygląda tak:

[mgcamd] ecm dla caid 0x0500 pid 0x0136 provider 0x032820

Lub co gorsza, nie masz w ogóle zarejestrowanego żądania ECM — co oznacza, że MgCamd nawet nie kieruje CAID kanału do tej linii. Inny problem, ten sam czarny ekran.

Przepływ protokołu Newcamd: logowanie OK, ale brak dcw

Uścisk dłoni newcamd ma dwie fazy. Faza pierwsza: połączenie TCP, wymiana kluczy DES, uwierzytelnianie użytkownika/hasła. Faza druga: rzeczywisty ruch ECM/dcw. Możesz przejść przez fazę pierwszą całkowicie i nadal nie zdać fazy drugiej. Zły klucz DES to klasyczny przykład — uścisk dłoni czasami kończy się w obniżonym stanie, który pokazuje "połączony", ale nie produkuje nic. Wygasła karta na serwerze to kolejny przykład: logowanie działa dobrze, sprawdzenie uprawnień zwraca pusty wynik.

Krok 1: Zweryfikuj linię Newcamd i klucz DES

Otwórz/var/keys/newcamd.list i spójrz na swoją linię CWS. Format to:

CWS = hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Ten ostatni blok to klucz DES. Musi mieć dokładnie 14 bajtów — zapisany jako 14 par szesnastkowych oddzielonych spacjami. Niektóre konfiguracje zapisują go bez spacji jako 28-znakowy ciąg szesnastkowy. Oba formaty istnieją; wiedz, którego oczekuje twój obraz.

składnia newcamd.list: CWS = host port user pass DES-key

Pełna działająca linia wygląda tak:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Po kluczu DES możesz opcjonalnie przypiąć CAID i identyfikator dostawcy:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14 0500 032820

Złe CAID/ident i nic dla tego dostawcy nigdy nie zostanie zdekodowane na tej linii, nawet jeśli serwer ma kartę.

Pułapka klucza DES o długości 14 bajtów (28 znaków szesnastkowych)

To jest najczęstsza przyczyna problemu z połączeniem, ale czarnym ekranem. Ktoś kopiuje klucz DES z końcową spacją, traci znak lub wkleja go z PDF, który zastąpił zero literą O. Klucz wygląda dobrze na pierwszy rzut oka. MgCamd łączy się. Nic nie jest dekodowane.

Policz swoje znaki. Jeśli klucz jest zapisany jako pary oddzielone spacjami: policz 14 par. Jeśli to ciąg szesnastkowy: policz dokładnie 28 znaków. Nie 27. Nie 29. 28.

Zwróć również uwagę na niespójności między małymi a wielkimi literami. Protokół newcamd jest niewrażliwy na wielkość liter dla szesnastkowych, ale niektóre wersje MgCamd znane są z problemów z kluczami o mieszanej wielkości liter. Unormalizuj do wielkich liter, jeśli ścigasz ducha.

Testowanie dostępności: telnet/nc do portu newcamd

Zanim obwinisz konfigurację, potwierdź, że połączenie TCP faktycznie działa z twojego komputera:

nc -zv myserver.example.com 17000

Chcesz zobaczyćPołączenie z myserver.example.com 17000 port [tcp/*] powiodło się!. Jeśli wystąpił czas oczekiwania lub odmowa, nawet nie osiągasz serwera — MgCamd pokazujące "połączone", podczas gdy to nie działa, oznacza, że jest stan pamięci podręcznej/stary, który zostaje wyczyszczony po restarcie.

Typowe numery portów i kontrole zapory/firewalla/NAT

Porty Newcamd różnią się w zależności od konfiguracji serwera, ale zazwyczaj mieszczą się w przedziale 10000–20000. Niektórzy operatorzy używają 17000, 15000 lub niestandardowych zakresów. Jeśli jesteś za CGNAT lub podwójnym NAT (częste w przypadku internetu mobilnego lub niektórych dostawców), połączenie TCP z twojego komputera może wydawać się nawiązywać lokalnie, ale serwer nigdy nie widzi prawdziwego gniazda. Status "połączone" w MgCamd opiera się na zakończeniu lokalnego uzgadniania TCP — nie dowodzi, że gniazdo po stronie serwera działa.

Przetestuj z innej sieci, jeśli podejrzewasz problemy z NAT. Sprawdź również, czy żadna zapora na twoim routerze nie blokuje cicho wychodzącego ruchu na tym porcie.

Krok 2: Sprawdź CAID, dostawcę i trasowanie ECM PID

Nawet z idealnym newcamd.list, ECM-y mogą nadal nie działać, jeśli MgCamd kieruje je do złej linii lub czytnik serwera nie obsługuje tego CAID. To jest druga najczęstsza przyczynamgcamd: rozwiązanie problemu z otwieraniem udziału problemów — i prawie zawsze jest niewidoczna bez szczegółowego logowania.

Ograniczenie linii do odpowiedniego CAID/ident

W/var/keys/mg_cfg blok C: definiuje, które CAID-y obsługuje każda linia. Przykład:C: ( 0500 )Druga forma przypina do konkretnego identyfikatora dostawcy w ramach CAID. Jeśli twój serwer obsługuje tylko identyfikator 032820, ale wysyłasz ECM-y dla identyfikatora 040810, te żądania nie zwracają nic. Dopasuj identyfikator do tego, co serwer faktycznie ma — zapytaj operatora, jeśli nie wiesz, lub sprawdź OSCam webif.

C: ( 0500 )C: ( 0500:032820 )

The second form pins to a specific provider ident within the CAID. If your server only carries ident 032820 but you send ECMs for ident 040810, those requests return nothing. Match the ident to what the server actually has — ask the operator if you don't know, or check OSCam webif.

Kiedy CAID kanału nie jest na czytniku

Niektóre kanały nadają wiele CAID-ów na tym samym transponderze. Twój dekoder może wybrać CAID 0x0100 (Seca), podczas gdy serwer ma tylko 0x0500 (Viaccess). Rozwiązaniem jest albo wymuszenie na twoim dekoderze użycia CAID, który obsługuje serwer, albo skonfigurowanie listy priorytetów MgCamd, aby preferować ten właściwy. W mg_cfg,linie P: ustalają kolejność priorytetów dla CAID-ów, gdy dostępnych jest wiele opcji.

ECM PID i transpondery z wieloma CAID-ami

Ten przypadek brzegowy często zaskakuje ludzi. Transponder obsługuje jeden kanał zaszyfrowany dwoma różnymi systemami CA — powiedzmy Nagravision na PID 0x0600 i Irdeto na PID 0x0601. Twój odbiornik może zablokować się na PID Irdeto, ponieważ jest wymieniony jako pierwszy w PMT. MgCamd wysyła ECM do twojej linii Irdeto, która nie ma karty. Tymczasem twoja linia Nagravision pozostaje bezczynna z idealnie ważną kartą, która natychmiast by to zdekodowała.

Wymuś ECM PID w ustawieniach kanału swojego odbiornika, jeśli twoje oprogramowanie to wspiera, lub skonfiguruj MgCamd, aby kierować ten konkretny CAID wyłącznie do właściwej linii.

Listy priorytetów i ignorowania (pozycje mg_cfg C:/P:)

LinieI: (ignorowanie) w mg_cfg są odwrotnościąC: — mówią MgCamd, aby nigdy nie wysyłać konkretnego CAID/ident do danej linii. Używaj ich, gdy masz wiele linii i chcesz zapobiec przechwytywaniu ECM-ów przez słabą linię, która nie może na nie odpowiedzieć:

I: ( 0500:040810 )

W połączeniu z wyraźnymiP: wpisami priorytetowymi, możesz przypisać każdy CAID/ident do dokładnie jednej linii i wyeliminować warunki wyścigu między wieloma wpisami CWS.

Krok 3: Diagnoza z perspektywy serwera (OSCam/CCcam)

Na tym etapie, jeśli twoja konfiguracja wygląda poprawnie, problem może wcale nie leżeć w twoim dekoderze. Uzyskanie widoczności po stronie serwera to to, co oddziela 20-minutową naprawę od 3-godzinnej sesji debugowania.

Serwer OSCam newcamd: [newcamd] klucz, port i blok użytkownika

Jeśli serwer działa na OSCam, sprawdź/etc/oscam/oscam.conf oraz/etc/oscam/oscam.server. Nasłuchiwacz newcamd potrzebuje dedykowanej sekcji woscam.conf:

[newcamd]

Klucz= tutaj musi odpowiadać kluczowi DES w twoimnewcamd.list dokładnie. Powiązanie portu opcjonalnie dodaje@CAID:ident aby ograniczyć, co ten nasłuchiwacz obsługuje. Jeśli CAID/ident w twoim dekoderze się nie zgadza, OSCam może zaakceptować ECM i natychmiast go odrzucić.

Konta użytkowników znajdują się w/etc/oscam/oscam.user. Potwierdź, że twoja nazwa użytkownika ma odpowiedni CAID i ident wcaid = orazident = polach, oraz żedisabled = 0 .

Status webif OSCam: czytnik, ecm i 'nie znaleziono' vs 'przekroczenie czasu'

Interfejs webowy OSCam (zwykle dostępny na porcie 8888 lub 8383) jest najprzydatniejszym narzędziem diagnostycznym, jakie masz. W zakładce historii ECM zobaczysz jeden z trzech wyników dla przychodzących żądań ECM:

• znaleziono — karta go zdekodowała, ważny CW wrócił do MgCamd. Jeśli twój dekoder nadal jest czarny, wina leży lokalnie.
• nie znaleziono — OSCam otrzymał ECM, ale żaden czytnik nie mógł na nie odpowiedzieć. Karta brakująca, zły CAID lub brak uprawnień.
• przekroczenie czasu — OSCam przesłał ECM w górę, ale nie otrzymał odpowiedzi w skonfigurowanym czasie oczekiwania. Problem z hopem w górę.

To trójstronne rozdzielenie precyzyjnie lokalizuje błąd. "Znaleziono, ale czarne" to lokalny problem PID/cam. "Nie znaleziono" to problem z kartą/uprawnieniami. "Przekroczenie czasu" to problem z łańcuchem w górę.

CCcam nowa eksportacja newcamd i widoczność udostępniania

Dla serwerów CCcam, sprawdź/etc/CCcam.cfg. Sekcja eksportu newcamd wymagaPORTU NASŁUCHU NEWCAMD: wpisu i odpowiadającychN: host port username password DES-key definicji klientów — lub odpowiednika po stronie serwera dla udostępnień wychodzących. Na stronach informacji CCcam (zwykle port 16001), zweryfikuj, czy karta, której się spodziewasz, jest faktycznie na liście udostępnień i oznaczona jako lokalnie dostępna, a nie tylko jako zdalne udostępnienie z innego skoku, który może być niedostępny.

Dostępność karty, AU i kontrole uprawnień

Technicznie doskonała konfiguracja może nadal powodować "udostępnienie nie otwiera się", jeśli sama karta nie ma ważnych uprawnień. Karty wygasają. Dostawcy rotują klucze z aktualizacjami EMM. Jeśli AU (Automatyczna Aktualizacja) nie działa — karta musi być fizycznie w czytniku podłączonym do serwera, który aktywnie odbiera EMM — uprawnienia stają się nieaktualne, a dekodowanie zatrzymuje się, mimo że karta jest obecna i OSCam pokazuje ją jako aktywną.

W OSCam sprawdź status czytnika w webif: spójrz na listę uprawnień i ostatni znacznik czasu EMM. Karta, która nie otrzymała EMM od dni, jest podejrzana.

Krok 4: Napraw czas, pamięć podręczną i limity szybkości ECM

Jeśli konfiguracja jest poprawna, a karta ma uprawnienia, ale nadal występują przerywane czarne ekrany lub zamrożenie po kilku sekundach, problem jest związany z czasem. To obejmuje najtrudniejszą kategorięmgcamd: udostępnienie nie otwiera się решение problemów, ponieważ wyglądają inaczej za każdym razem.

Dostosowanie limitu czasu ECM w mg_cfg (M: / T: wartości)

Limit czasu MgCamd na oczekiwanie na odpowiedź dcw jest kontrolowany przezM: (maksymalny czas ecm) w mg_cfg, często wyrażany w jednostkach 100ms. Ustawienie takie jak:

M: { 3 }

Oznacza, że MgCamd czeka 300ms, zanim zrezygnuje z odpowiedzi CW. Dla serwera dwa skoki dalej z pewnym opóźnieniem, to jest ciasne. Zwiększ to do 6 lub 8 (600–800ms) i przetestuj. Zbyt wysokie ustawienie tworzy inny problem — możesz przegapić okres rotacji CW i uzyskać zamrożenie zamiast płynnego obrazu. Zrównoważ to na podstawie rzeczywistego opóźnienia serwera.

Wzór zamrożenia po kilku sekundach występuje szczególnie wtedy, gdy następuje rotacja CW (mniej więcej co 10 sekund) i nowy CW nie przychodzi na czas. Poprzedni CW wygasa, obraz zamraża się, a w zależności od twojego dekodera, może się odzyskać lub nie. Czasowe sterowanie po stronie serwera lub użycie pamięci podręcznej CW OSCamd może to wygładzić.

cache-ex / cache peers powodujące nieaktualne CW

Funkcja cache-ex OSCam pozwala wielu instancjom OSCam dzielić się dekodowanymi CW. To zazwyczaj przynosi korzyści wydajnościowe — CW, które zostało właśnie zdekodowane przez jeden serwer, jest natychmiast serwowane następnemu żądającemu. Ale źle skonfigurowany peer pamięci podręcznej może serwować nieaktualne CW z poprzedniego okresu kryptograficznego. Twój dekoder otrzymuje CW, które wygląda na ważne, stosuje je, a obraz jest zniekształcony lub zamrożony, ponieważ szyfrowanie już się obróciło.

Jeśli widzisz krótki obraz (1–2 sekundy, a potem zamrożenie), tymczasowo wyłącz cache-ex i sprawdź, czy to stabilizuje. Jeśli tak, peer pamięci podręcznej zwraca błędne dane.

Ograniczanie szybkości ECM i ograniczanie 'za dużo ecm'

Serwery pod obciążeniem często wdrażają ograniczenia szybkości ECM na konto użytkownika. Jeśli twój dekoder wysyła ECM zbyt szybko (przełączanie kanałów, złe analizowanie PMT wysyłające duplikaty żądań), serwer zacznie odrzucać żądania. W logach OSCam pokazuje się to jakoza dużo ecm lub po prostu cisza — ECM jest odbierany i odrzucany bez odpowiedzi.

Czarne ekrany tylko w godzinach szczytu to prawie zawsze to. Czytnik serwera jest przytłoczony. Nie ma wiele, co możesz zrobić po stronie klienta, poza zmniejszeniem niepotrzebnego ruchu ECM — nie skanuj kanałów szybko, upewnij się, że twój dekoder nie wysyła duplikatów ECM dla tego samego PID, i poczekaj na okres szczytowy.

Zakłócenia z drugiego cam (priorytet softcam)

To jest subtelne i rzeczywiście powoduje scenariusz "działało wczoraj, zepsute dzisiaj". Jeśli zainstalowano lub włączono drugi softcam — lub jeśli twój obraz ma wbudowany dekoder, który aktywuje się na określonych CAID — może przechwycić ECM, zanim MgCamd go otrzyma. Wbudowany cam nie udaje się zdekodować (brak karty), nie zwraca nic, a MgCamd nigdy nie widzi żądania, ponieważ ECM został skonsumowany w górę.

Sprawdź ustawienia priorytetu cam w swoim obrazie i upewnij się, że MgCamd ma najwyższy priorytet dla CAID, które udostępniasz. Całkowicie wyłącz konkurencyjne camy dla tych CAID, jeśli twój obraz to wspiera. Objawem jest: log ECM w MgCamd nie pokazuje żadnych żądań dla kanału, który powinien je żądać.

Systematyczne przechodzenie przez te kroki to jedyna niezawodna droga w obliczumgcamd: share not opening решение błędów — nie ma jednego rozwiązania, ponieważ awaria może występować w sześciu różnych miejscach. Zacznij lokalnie (klucz DES, routowanie CAID), przejdź do weryfikacji po stronie serwera (interfejs webowy OSCam, udostępnienia CCcam), a następnie zbadaj czas i zakłócenia. Podział OSCam "znaleziono / nie znaleziono / timeout" to najpotężniejsze narzędzie diagnostyczne dostępne, a większość ludzi nigdy go nie używa.