MGCamd Reshare Setup: Pełna konfiguracja& Przewodnik po Newcamd

Odpowiedniakonfiguracja mgcamd reshare sprawia wiele problemów — i to z dobrego powodu. Większość przewodników w Internecie zakłada, że MGCamd działa jak mini-serwer, na który można skierować inne odbiorniki. Tak nie jest. MGCamd jest klientem. Zrozumienie tej różnicy to klucz do spędzenia wieczoru na debugowaniu lub rzeczywistego uzyskania dekodowania przez twoje downstreamowe urządzenia.

Ten przewodnik obejmuje pełną architekturę: jakie pliki kontrolują co, jak połączyć przezOScam w celu prawdziwego resharingu oraz jak debugować najczęstsze tryby awarii, w tym frustrujący problem "źródło dekoduje poprawnie, ale downstream się zawiesza".

Jak działa MGCamd Resharing

MGCamd jako klient vs. jako źródło resharingu

MGCamd jest zasadniczonewcamd/cs357x klientem. Łączy się z górą, odbiera słowa kontrolne (CW) i przekazuje je do lokalnego tunera. To jego zadanie. Nie ma wbudowanego demona serwera newcamd, który nasłuchuje połączeń downstream — MGCamd nie otwiera portu, do którego mogą łączyć się inne odbiorniki.

Więc kiedy ludzie mówią o konfiguracji mgcamd reshare, to co mają na myśli (czy to wiedzą, czy nie) to użycie MGCamd do odbierania linii górnej, a następnie przekazywanie tego przez coś innego — zazwyczaj OScam — aby obsłużyć klientów downstream.

Łańcuch protokołu Newcamd: Klient → MGCamd → Downstream

Realistyczny łańcuch wygląda tak: twoja linia karty górnej łączy się za pomocą protokołu newcamd z MGCamd. MGCamd deszyfruje i przekazuje CW lokalnie. OScam, działający na tym samym urządzeniu, łączy się z tym samym upstreamem jako czytnik newcamd — lub, jeśli jesteś sprytny, odczytuje z pamięci współdzielonej MGCamd. OScam następnie uruchamia własne porty serwera newcamd/cccam do których łączą się odbiorniki downstream.

Głębokość resharingu — czasami nazywana skokami — to ile razy CW może być przekazywane, zanim zostanie zablokowane. Każdy skok dodaje opóźnienie. Przy dwóch skokach głęboko już patrzysz na czasy ECM 400–800ms, jeśli cokolwiek w łańcuchu się zacięło.

Dlaczego MGCamd samodzielnie jest ograniczone do resharingu

MGCamd 1.35, 1.38 i 1.45 nie mają nasłuchującego serwera. Możesz skonfigurować udostępnianie pamięci podręcznej za pomocą cache-ex, aby wymieniać CW z rówieśnikami, ale to jest wymiana CW między równymi sobie, a nie prawdziwy model resharingu serwer-klient. Nie trać czasu na szukanie ustawienia "portu resharingu" w mg_cfg — nie ma go tam.

Niektóre zewnętrzne wersje MGCamd twierdzą, że mają zdolność resharingu, ale w praktyce są niestabilne i słabo udokumentowane. Most OScam to podejście, które rzeczywiście działa niezawodnie.

Kiedy połączyć MGCamd z OScam jako serwerem resharingu

Użyj tego połączenia, gdy masz jedną linię górną i chcesz obsłużyć 2–10 odbiorników downstream. OScam obsługuje uwierzytelnianie, filtrowanie CAID, limity maxhops i uprawnienia do resharingu dla poszczególnych użytkowników w sposób przejrzysty. MGCamd pozostaje klientem upstream, jeśli twoja linia górna tego wymaga, chociaż wiele konfiguracji całkowicie pomija MGCamd i używa OScam jako klienta i serwera.

Wymagania wstępne i układ plików

Wymagane pliki: newcamd.list, mg_cfg, cw_list

Trzy pliki wykonują większość pracy w MGCamd.newcamd.list zawiera linie połączeń z twoim serwerem — jeden wpis CWS na linię górną.mg_cfg kontroluje zachowanie w czasie rzeczywistym: limity czasowe, ustawienia pamięci podręcznej, szczegółowość debugowania, ponowne próby połączenia.cw_list jest opcjonalny, ale przydatny — pozwala filtrować, które CAID i dostawcy są przetwarzani przez MGCamd, co ma znaczenie, gdy udostępniasz mieszany strumień, a tylko niektórzy dostawcy są dozwoleni do przekazywania dalej.

Typowe ścieżki: /var/keys/, /var/emu/, /etc/tuxbox/

Na obrazach Enigma2 (OpenPLi, OpenATV itp.) zazwyczaj znajdziesz konfigurację MGCamd w/var/keys/. Starsze obrazy, szczególnie oparte na Gemini lub DreamElite, używają/var/emu/. Niektóre wbudowane wersje umieszczają wszystko pod/etc/tuxbox/config/.

Sprawdź, która katalog twojego skryptu uruchamiającego odnosi się przed edytowaniem. Edytowanie niewłaściwej kopii i zastanawianie się, dlaczego nic się nie zmienia, to klasyczny sposób na marnowanie czasu.

Kompatybilność wersji MGCamd (1.35 / 1.38 / 1.45)

Nazwy flag w mg_cfg zmieniały się między wersjami. MGCamd 1.35 używa nieco innej składni cache-ex niż 1.38 i 1.45.M: orazG: struktura bloku jest spójna, ale opcje takie jak definicja peer cache zmieniły format. Zawsze czytaj readme dołączone do twojego konkretnego binarnego pliku — nie zakładaj, że konfiguracja z postu na forum pasuje do twojej wersji.

Weryfikacja, czy twój upstream działa przed ponownym udostępnieniem

Nie dotykaj konfiguracji ponownego udostępnienia, dopóki lokalne dekodowanie nie działa poprawnie. Przełącz się na płatny kanał, poczekaj 10–15 sekund i przeszukaj swój dziennik MGCamd pod kątem czasu ECM:grep "ecm time" /tmp/mgcamd.log. Chcesz, aby czasy były spójne i wynosiły poniżej 500 ms. Jeśli widzisz przekroczenia czasu lub "brak CW" przed próbą ponownego udostępnienia, konfiguracja ponownego udostępnienia tylko doda zamieszania do problemu upstream.

Konfigurowanie linii newcamd.list

Anatomia linii CWS: Host Port Użytkownik Hasło Klucz DES

Każdy wpis wnewcamd.list ma ten format:

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

Klucz DES to ostatnie 14 pól, każde to dwucyfrowy bajt szesnastkowy, oddzielone spacjami. Niektóre wersje akceptują je bez spacji jako pojedynczy ciąg 28-znakowy. Oba formaty istnieją w rzeczywistości — sprawdź przykładową konfigurację swojej wersji, aby wiedzieć, czego oczekuje.

Wrażliwość na białe znaki jest tutaj realna. Tabulator tam, gdzie oczekiwana jest spacja, lub dodatkowa spacja przed nową linią, mogą cicho zepsuć analizę. Użyj edytora hex lubcat -A aby sprawdzić ukryte znaki, jeśli linia odmawia połączenia.

14-bajtowy klucz DES i dlaczego 28 znaków szesnastkowych ma znaczenie

Klucz DES autoryzuje sesję newcamd. Ma 14 bajtów — wyrażonych jako dokładnie 28 znaków szesnastkowych. Pojedynczy błędny znak oznacza, że handshake się nie udaje. Błąd w dzienniku będzie wyglądał jak przekroczenie czasu połączenia lub "logowanie nie powiodło się", a nie błąd formatu klucza, więc łatwo pomylić to z problemem sieciowym.

Twój dostawca upstream daje ci ten klucz jako część twoich danych uwierzytelniających. Skopiuj go dokładnie. Nie przepisuj go ręcznie — wklej go, a następnie zweryfikuj liczbę znaków. 28 znaków, bez spacji w formacie 28-znakowym, bez obcięcia.

Ustawianie flag ponownego udostępnienia/włączenia na linię

Niektóre wersje MGCamd obsługują flagi końcowe na linii CWS:

CWS = hostname 15000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14 01 00

Bajty końcowe tutaj (np.01 00) mogą wskazywać stan włączenia/wyłączenia lub wskazówki dotyczące ponownego udostępnienia w zależności od wersji. W standardowym MGCamd 1.38/1.45 te dodatkowe bajty są zazwyczaj ignorowane. Nie dodawaj ich, chyba że readme twojej wersji szczegółowo dokumentuje, co robią — nieudokumentowane flagi wprowadzają zamieszanie bez korzyści.

Wiele linii, priorytet i kolejność awaryjna

MGCamd odczytuje linie CWS od góry do dołu i próbuje je w tej kolejności. Pierwsza linia, która odpowiada ważnym CW, "wygrywa" dla tego ECM. Jeśli masz dwie linie pokrywające różne CAID-y, umieść swoją główną/najszybszą linię na pierwszym miejscu. Jeśli pierwsza linia przekroczy czas (na podstawie wartości timeout w mg_cfg), MGCamd przechodzi do następnej.

Awaryjne przełączanie działa, ale dodaje czas ECM równy czasowi przekroczenia linii, która zawiodła. Utrzymuj swój czas przekroczenia na tyle krótki, aby awaryjne przełączanie nie powodowało widocznego zamrożenia — 2000–3000 ms to rozsądny punkt wyjścia.

Flagi mg_cfg, które wpływają na ponowne udostępnienie i stabilność

M: (Tryb konfiguracji) i G: (Globalne) bloki

mg_cfg jest zbudowany w blokach.M: blokuje tryb operacyjny — czy MGCamd używa lokalnych EMM, dzieli CW, uruchamia cache-ex.G: blok (lub jego odpowiednik w twojej wersji) ustawia globalne zachowanie, takie jak szczegółowość logów i rozmiar cache. Minimalna konfiguracja mg_cfg dla ustawienia reshare powinna mieć poziom logowania wystarczająco wysoki, aby zobaczyć czasy ECM i stan połączenia, ale nie tak szczegółowy, aby zapełniał /tmp i powodował problemy z I/O na pamięci flash.

Ustawienia Cache i Cache-EX (C: / Linie Cache)

Cache przechowuje niedawno odebrane CW, aby drugie żądanie ECM dla tego samego klucza nie wymagało podróży sieciowej. W ustawieniu reshare przyspiesza to odpowiedź w dół — ale wprowadza również pułapkę: jeśli dwa węzły dzielą się ze sobą (przypadkowa pętla), mogą wymieniać przestarzałe lub błędne CW, które są buforowane i serwowane wielokrotnie, powodując trwałe zawieszenie, które wygląda jak problem z siecią.

Jeśli używasz peerów cache-ex, upewnij się, że topologia jest ściśle jednokierunkowa. Nie pozwól, aby węzeł A łączył się z węzłem B, a węzeł B z powrotem z węzłem A, chyba że wyraźnie ustawiłeś flagi wykrywania pętli.

Czas oczekiwania ECM, ponowne próby i dostosowanie awaryjne

Czas oczekiwania ECM w mg_cfg kontroluje, jak długo MGCamd czeka na CW, zanim oznaczy linię jako nieodpowiadającą i spróbuje następnej (lub zwróci brak CW). Dla topologii reshare ten czas oczekiwania wpływa również na twoje odbiorniki w dół — czekają na MGCamd, które czeka na upstream.

Bezpieczna wartość początkowa to 3000ms (3 sekundy). Poniżej 1500ms otrzymasz fałszywe czasy oczekiwania na każdej linii przy umiarkowanym obciążeniu. Powyżej 5000ms pojedyncze pominięcie ECM powoduje widoczne zawieszenie w dół. Dostosuj w dół, gdy konfiguracja jest stabilna.

Ustawienia zapobiegania kaskadzie i zawieszeniu

Niektóre wersje MGCamd zawierają zachowanie zapobiegające kaskadzie — ograniczając, ile ECM-ów na sekundę jest przesyłanych w górę. Chroni to twojego dostawcę upstream przed nadmiernym obciążeniem (i chroni cię przed odcięciem linii). W ustawieniu reshare z kilkoma odbiornikami w dół, wskaźnik ECM może wzrosnąć, ponieważ każdy odbiornik wysyła swoje własne ECM niezależnie. Ustaw rozsądny limit na sekundę i monitoruj swój wskaźnik ECM w logach.

Mostkowanie MGCamd do OScam dla prawdziwego reshare

To tutaj znajduje się funkcjonalna konfiguracja reshare mgcamd. OScam obsługuje wszystko, czego MGCamd nie może: obsługę połączeń w dół, uprawnienia per-użytkownik, filtrowanie CAID i odpowiednią kontrolę głębokości reshare.

oscam.server: Typ czytnika=newcamd wskazujący na twoją linię

W/etc/oscam/oscam.server zdefiniuj czytnik, który łączy się z twoją linią upstream, używając protokołu newcamd:

[reader]

Polekey tutaj to twój 14-bajtowy klucz DES w 28 znakach szesnastkowych, bez spacji. Polegroup łączy tego czytnika z użytkownikami OScam — użytkownik w grupie 1 może korzystać z tego czytnika. Jeśli grupy się nie zgadzają, żadne ECM-y nie są przesyłane, niezależnie od tego, czy wszystko inne jest poprawne.

oscam.user z serwerem cccam/newcamd + maxhops i reshare

W/etc/oscam/oscam.user każde konto w dół potrzebuje uprawnienia do reshare i przypisania grupy:

[account]

reshare = 1 oznacza, że to konto może dzielić się na jeden poziom dalej.reshare = 0 oznacza, że klient może dekodować, ale nie może dzielić się z nikim innym.cccmaxhops ogranicza, ile skoków CCcam w dół od tego użytkownika może przejść CW.

Porty serwera oscam.conf (cs378x/newcamd/cccam)

W/etc/oscam/oscam.conf włącz protokoły serwera, które chcesz oferować w dół:

[newcamd]

Linia portu newcamd zawiera powiązanie CAID i identyfikatora —15001@0500:000000oznacza, że port 15001 obsługuje CAID 0500. Możesz powiązać wiele CAID na oddzielnych portach lub użyć portu ogólnego. To są porty, do których łączą się twoje odbiorniki downstream, i muszą być dostępne przez wszelkie zapory ogniowe lub NAT między tobą a twoimi klientami.

Ustawienie reshare = N i cccmaxhops poprawnie

Typowa błędna konfiguracja: ustawieniereshare = 1na użytkowniku, ale pozostawieniecccmaxhops = 0lub odwrotnie. Oba muszą pozwalać na zamierzony poziom. Jeśli twój dostawca upstream ustawił maxhops na 1 po swojej stronie, twój klient downstream otrzymuje dokładnie 1 hop — nie możesz tego zmienić z swojej strony. Możesz tylko ograniczyć, a nie rozszerzyć.

Dla prostego dwupoziomowego udostępniania (ty → klient),reshare = 1icccmaxhops = 1na koncie klienta jest wystarczające.

Rozwiązywanie problemów: Łączy, ale nie udostępnia

Logowanie OK, ale brak przesyłania ECM (niezgodność grupy/CAID)

To jest najczęstszy problem w każdej konfiguracji mgcamd reshare i zawsze jest to niezgodność grupy lub CAID. W logu OScam (/var/log/oscam/oscam.log) szukaj linii zawierających "brak pasującego czytnika" lub "brak karty dla caid." Jeśli widzisz "połączono" dla klienta downstream, ale brak aktywności ECM, czytnik nie jest wybierany dla żądań tego użytkownika.

Naprawa: upewnij się, żenumer grupy w bloku czytnika oscam.server pojawia się wpolu grupy konta oscam.user. I upewnij się, że CAID, o który prosi downstream, jest rzeczywiście wymieniony w obu miejscach.

Zawiesza się na Downstream, ale Źródło Dekoduje Bez Problemów

Gdy twój lokalny tuner dekoduje poprawnie, ale odbiornik downstream zawiesza się co 8–15 sekund (jeden okres kryptograficzny), CW przychodzi albo za późno, albo jest błędny. Późno = czas oczekiwania ECM, błędnie = pętla pamięci podręcznej serwująca przestarzały CW.

Szukaj w logu OScam czasów ECM dla konta downstream:grep "client1" /var/log/oscam/oscam.log | grep "ecm". Jeśli czasy sporadycznie skaczą do 2000ms+, zwiększ czas oczekiwania. Jeśli czasy są szybkie, ale downstream nadal się zawiesza, podejrzewaj błędny CW z pamięci podręcznej — tymczasowo wyłącz cache-ex, aby przetestować.

'Karta Nie Znaleziona' / Brak Przysług

Ten błąd oznacza, że OScam otrzymał żądanie ECM od klienta downstream, ale nie znalazł czytnika, który mógłby je obsłużyć. Albo czytnik nie działa (sprawdź status czytnika oscam), filtr CAID wyklucza żądanie, albo linia upstream nie obsługuje tego dostawcy.

Sprawdźoscam.server: jeślicaid = jest ustawione zbyt wąsko, żądania dla innych CAID na tej samej linii są cicho odrzucane. Mieszany feed upstream z autoryzowanymi tylko niektórymi CAID do reshare to rzeczywisty scenariusz — dostawca upstream może zezwalać na reshare 0500, ale nie 1800. Nie możesz reshare'ować CAID, które upstream zablokował po swojej stronie.

Wyeksploatowana Głębokość Reshare (maxhops = 0)

Jeśli twój dostawca upstream ustawił swoją linię na maxhops = 1, a ty reshare'ujesz do klienta, maxhops tego klienta = 0 — mogą dekodować, ale nie mogą reshare'ować dalej. To nie jest błąd konfiguracji z twojej strony; to upstream narzuca ograniczenia. Żadne dostosowania twojej konfiguracji OScam nie wydłużą hops poza to, co pozwala upstream.

Jeśli sama linia upstream przychodzi z maxhops = 0 (możesz to zobaczyć w informacji o czytniku OScam), to nawet ty nie możesz jej w ogóle reshare'ować — upstream wyraźnie to zablokował. Albo renegocjuj z swoim dostawcą, albo zdobądź inną linię z pozwoleniem na reshare.

Problemy z NAT, Zapory i Podwójnym NAT

Odbiornik downstream za drugim routerem NAT (podwójny NAT) to powszechny problem. Skrzynka downstream może dotrzeć do portu serwera OScam, ale połączenie TCP z klientem za CGNAT lub podwójnym NAT może nie działać bez odpowiedniego przekierowania portów na każdym poziomie.

Dla klientów newcamd serwer nie inicjuje żadnych połączeń — klient łączy się z twoim portem serwera. Dlatego musisz mieć swój port serwera (np. 15001) dostępny z publicznego internetu. Po stronie downstream nie trzeba otwierać żadnych portów. Ale jeśli sam jesteś za CGNAT, nie możesz łatwo hostować serwera przychodzącego — rozważ tunel VPN (WireGuard dobrze się do tego nadaje) między tobą a swoimi klientami downstream.

Sprawdź za pomocą:nc -zv your.server.ip 15001 z maszyny downstream. Jeśli to się nie powiedzie, to problem z siecią/zaporą przed jakąkolwiek konfiguracją MGCamd lub OScam jest istotny.