MGCamd Reshare Setup: Full Config & Newcamd Guide

A proper mgcamd reshare setup trips up a lot of people — and for good reason. Most guides online assume MGCamd works like a mini-server you can just point other receivers at. It doesn't. MGCamd is a client. Understanding that distinction is the difference between spending an evening debugging and actually getting your downstream boxes decoding.

This guide covers the full architecture: what files control what, how to bridge through OScam for real resharing, and how to debug the most common failure modes including the frustrating "source decodes fine but downstream freezes" problem.

How MGCamd Resharing Actually Works

MGCamd as a Client vs. as a Reshare Source

MGCamd is fundamentally a newcamd/cs357x client. It connects upstream, receives control words (CWs), and hands them to your local tuner. That's its job. There's no built-in newcamd server daemon listening for downstream connections — MGCamd doesn't open a port that other receivers can connect to.

So when people talk about an mgcamd reshare setup, what they actually mean (whether they know it or not) is using MGCamd to receive the upstream line and then bridging that through something else — typically OScam — to serve downstream clients.

The Newcamd Protocol Chain: Client → MGCamd → Downstream

The realistic chain looks like this: your upstream card line connects via newcamd protocol to MGCamd. MGCamd decrypts and passes CWs locally. OScam, running on the same box, connects to the same upstream as a newcamd reader — or, if you're clever, it reads from MGCamd's shared memory. OScam then runs its own newcamd/cccam server ports that downstream receivers connect to.

Reshare depth — sometimes called hops — is how many times a CW can be forwarded before it's blocked. Each hop adds latency. At two hops deep you're already looking at 400–800ms ECM times if anything in the chain hiccups.

Why MGCamd Alone Is Limited for Resharing

MGCamd 1.35, 1.38, and 1.45 all lack a server listener. You can configure cache sharing via cache-ex to exchange CWs with peers, but that's a lateral CW exchange between equals, not a true server-client reshare model. Don't waste time hunting for a "reshare port" setting in mg_cfg — it's not there.

Some third-party MGCamd builds claim reshare capability, but in practice they're unstable and poorly documented. The OScam bridge is the approach that actually works reliably.

When to Pair MGCamd with OScam as the Reshare Server

Use this pairing when you have one upstream line and want to serve 2–10 downstream receivers. OScam handles authentication, CAID filtering, maxhops limits, and per-user reshare permissions cleanly. MGCamd stays as the upstream client if your upstream line requires it specifically, though many setups skip MGCamd entirely and just use OScam as both client and server.

Prerequisites and File Layout

Required Files: newcamd.list, mg_cfg, cw_list

Three files do most of the work in MGCamd. newcamd.list holds your server connection lines — one CWS entry per upstream line. mg_cfg controls runtime behavior: timeouts, cache settings, debug verbosity, connection retry. cw_list is optional but useful — it lets you filter which CAIDs and providers MGCamd processes, which matters when you're resharing a mixed feed and only some providers are permitted onward.

Common Paths: /var/keys/, /var/emu/, /etc/tuxbox/

On Enigma2 images (OpenPLi, OpenATV, etc.) you'll typically find MGCamd config at /var/keys/. Older images, particularly Gemini-based or DreamElite builds, use /var/emu/. Some embedded builds put everything under /etc/tuxbox/config/.

Check which directory your build's startup script references before editing. Editing the wrong copy and wondering why nothing changes is a classic time-waster.

MGCamd Version Compatibility (1.35 / 1.38 / 1.45)

Flag names in mg_cfg shifted between versions. MGCamd 1.35 uses a slightly different cache-ex syntax than 1.38 and 1.45. The M: and G: block structure is consistent, but options like cache peer definition changed format. Always read the readme bundled with your specific binary — don't assume a config from a forum post matches your version.

Verifying Your Upstream Line Is Decoding Before Resharing

Don't touch reshare config until local decoding works cleanly. Tune to a pay channel, wait 10–15 seconds, and grep your MGCamd log for ECM time: grep "ecm time" /tmp/mgcamd.log. You want consistent times under 500ms. If you're seeing timeouts or "no CW" before trying to reshare, the reshare config will only add confusion on top of an upstream problem.

Configuring the newcamd.list Line

Anatomy of a CWS Line: Host Port User Pass DES-Key

Each entry in newcamd.list follows this format:

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

The DES key is the last 14 fields, each a two-digit hex byte, space-separated. Some builds accept them without spaces as a single 28-character string. Both formats exist in the wild — check your build's example config to know which it expects.

Whitespace sensitivity is real here. A tab where a space is expected, or an extra space before the newline, can silently break parsing. Use a hex editor or cat -A to check for hidden characters if a line refuses to connect.

The 14-Byte DES Key and Why 28 Hex Chars Matter

The DES key authenticates the newcamd session. It's 14 bytes — expressed as exactly 28 hexadecimal characters. A single wrong character means the handshake fails. The error in the log will look like a connection timeout or "login failed," not a key format error, so it's easy to mistake for a network problem.

Your upstream provider gives you this key as part of your line credentials. Copy it exactly. Don't retype it manually — paste it, then verify character count. 28 chars, no spaces in the 28-char form, no truncation.

Setting Reshare/Enable Flags Per Line

Some MGCamd builds support trailing flags on the CWS line:

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

The trailing bytes here (e.g., 01 00) can indicate enable/disable state or reshare hints depending on the build. In vanilla MGCamd 1.38/1.45, these extra bytes are typically ignored. Don't add them unless your version's readme specifically documents what they do — undocumented flags add confusion with no benefit.

Multiple Lines, Priority, and Failover Ordering

MGCamd reads CWS lines top-to-bottom and tries them in that order. The first line that responds with a valid CW "wins" for that ECM. If you have two lines covering different CAIDs, put your primary/fastest line first. If the first line times out (based on the timeout value in mg_cfg), MGCamd falls through to the next.

Failover works, but it adds ECM time equal to the timeout of the failed line. Keep your timeout tight enough that failover doesn't cause a visible freeze — 2000–3000ms is a reasonable starting point.

mg_cfg Flags That Affect Resharing and Stability

M: (Config Mode) and G: (Global) Blocks

mg_cfg is structured in blocks. The M: block sets operating mode — whether MGCamd uses local EMM, shares CWs, runs cache-ex. The G: block (or equivalent in your version) sets global behavior like log verbosity and cache size. A minimal mg_cfg for a reshare setup should have log level high enough to see ECM times and connection state, but not so verbose it fills /tmp and causes I/O issues on flash storage.

Cache and Cache-EX Settings (C: / Cache Lines)

Cache stores recently received CWs so that a second ECM request for the same key doesn't need a network round-trip. In a reshare setup, this speeds up downstream response — but it also introduces a trap: if two nodes reshare to each other (accidental loop), they can exchange stale or wrong CWs that get cached and served repeatedly, causing a persistent freeze that looks like a network problem.

If you're using cache-ex peers, make sure the topology is strictly one-directional. Don't have node A peer to node B and node B peer back to node A unless you've explicitly set loop-detection flags.

ECM Timeout, Retry, and Fallback Tuning

The ECM timeout in mg_cfg controls how long MGCamd waits for a CW before marking a line unresponsive and trying the next one (or returning no-CW). For a reshare topology, this timeout also affects your downstream receivers — they wait for MGCamd, which waits for upstream.

A safe starting value is 3000ms (3 seconds). Below 1500ms you'll get false timeouts on any line with moderate load. Above 5000ms and a single missed ECM causes a visible freeze downstream. Tune down once the setup is stable.

Anti-Cascade and Freeze Avoidance Settings

Some MGCamd builds include anti-cascade behavior — limiting how many ECMs per second get forwarded upstream. This protects your upstream provider from excessive load (and protects you from having your line cut). In a reshare setup with several downstream receivers, ECM rate can spike because every receiver sends its own ECM independently. Set a reasonable per-second cap and monitor your upstream ECM rate in the log.

Bridging MGCamd to OScam for Real Resharing

This is where a functional mgcamd reshare setup actually lives. OScam handles everything MGCamd can't: serving downstream connections, per-user permissions, CAID filtering, and proper reshare depth control.

oscam.server: Reader Type=newcamd Pointing at Your Line

In /etc/oscam/oscam.server, define a reader that connects to your upstream line using the newcamd protocol:

[reader]label = upstream_lineprotocol = newcamddevice = your.upstream.host,15000key = 0102030405060708090A0B0C0D0Euser = yourusernamepassword = yourpasswordgroup = 1caid = 0500,1800ident = 0500:000000reconnecttimeout = 30

The key field here is your 14-byte DES key in 28 hex characters, no spaces. The group value links this reader to OScam users — a user in group 1 can use this reader. If the groups don't match, no ECMs get forwarded regardless of everything else being correct.

oscam.user with cccam/newcamd Server + maxhops and reshare

In /etc/oscam/oscam.user, each downstream account needs a reshare permission and group assignment:

[account]user = client1pwd = clientpasswordgroup = 1reshare = 1cccmaxhops = 1caid = 0500,1800au = 1

reshare = 1 means this account can share one level further. reshare = 0 means the client can decode but cannot reshare to anyone else. cccmaxhops limits how many CCcam hops downstream from this user a CW can travel.

oscam.conf Server Ports (cs378x/newcamd/cccam)

In /etc/oscam/oscam.conf, enable the server protocols you want to offer downstream:

[newcamd]port = 15001@0500:000000[cccam]port = 12000[cs378x]port = 15002

The newcamd port line includes CAID and ident binding — 15001@0500:000000 means port 15001 handles CAID 0500. You can bind multiple CAIDs on separate ports or use a generic port. These are the ports your downstream receivers connect to, and they need to be reachable through any firewall or NAT between you and your clients.

Setting reshare = N and cccmaxhops Correctly

A common misconfiguration: setting reshare = 1 on the user but leaving cccmaxhops = 0, or vice versa. Both need to allow the intended depth. If your upstream provider set maxhops to 1 on their side, your downstream client gets exactly 1 hop — you can't override that from your end. You can only limit further, not extend.

For a simple two-level share (you → client), reshare = 1 and cccmaxhops = 1 on the client account is sufficient.

Troubleshooting: Connects But Won't Reshare

Login OK but No ECM Forwarded (Group/CAID Mismatch)

This is the most common issue in any mgcamd reshare setup and it's always a group or CAID mismatch. In OScam's log (/var/log/oscam/oscam.log), look for lines containing "no matching reader" or "no card for caid." If you see "connected" for the downstream client but no ECM activity, the reader isn't being selected for that user's requests.

Fix: make sure the group number in your oscam.server reader block appears in the group field of the oscam.user account. And make sure the CAID the downstream is requesting is actually listed in both places.

Freezes on Downstream but Source Decodes Fine

When your local tuner decodes cleanly but the downstream receiver freezes every 8–15 seconds (one crypto period), the CW is either arriving late or wrong. Late = ECM timeout, wrong = cache loop serving a stale CW.

Grep the OScam log for ECM times on the downstream account: grep "client1" /var/log/oscam/oscam.log | grep "ecm". If times are spiking to 2000ms+ intermittently, raise the timeout. If times are fast but the downstream still freezes, suspect a wrong CW from cache — disable cache-ex temporarily to test.

'Card Not Found' / No Entitlements Passed

This error means OScam got the ECM request from the downstream client but found no reader able to handle it. Either the reader isn't running (check oscam reader status), the CAID filter is excluding the request, or the upstream line doesn't carry that provider.

Check oscam.server: if caid = is set too narrowly, requests for other CAIDs on the same line get silently dropped. A mixed-CAID upstream feed where only some CAIDs are authorized for reshare is a real scenario — the upstream provider may allow 0500 reshare but not 1800. You can't reshare CAIDs the upstream has blocked at their end.

Reshare Depth Exhausted (maxhops = 0)

If your upstream provider set their line to maxhops = 1, and you reshare to a client, that client's maxhops = 0 — they can decode but cannot reshare further. This isn't a config error on your side; it's the upstream enforcing limits. No amount of tweaking your OScam config will extend hops beyond what the upstream allows.

If the upstream line itself arrives with maxhops = 0 (you can see this in OScam's reader info), then even you can't reshare it at all — the upstream has explicitly blocked it. Either renegotiate with your provider or get a different line with reshare permission.

NAT, Firewall, and Double-Hop Networking Issues

A downstream receiver behind a second NAT router (double-NAT) is a common problem. The downstream box can reach your OScam server port, but the TCP connection from a client behind a CGNAT or double-NAT may not work without proper port forwarding at every layer.

For newcamd clients, the server initiates no connections — the client connects to your server port. So you need your server port (e.g., 15001) reachable from the public internet. On the downstream side, no ports need to be open. But if you're behind CGNAT yourself, you can't easily host an inbound server — consider a VPN tunnel (WireGuard works well for this) between you and your downstream clients.

Check with: nc -zv your.server.ip 15001 from the downstream machine. If that times out, it's a network/firewall issue before any MGCamd or OScam config is relevant.