Newcamd reshare: configuration for OScam and CCcam (2026)

If you have already set up OScam or CCcam and want to share a card via pyram, sooner or later you will encounter the fact that newcamd reshare: configuration turns out to be not as obvious as it seems from the first tutorials. Most guides simply insert a config block and move on. Here we will break down the mechanics: what happens inside, why group mismatch kills the share, and how to properly link the reader with clients without freezes.

What is newcamd reshare and when is it needed

Newcamd is a point-to-point protocol. One port serves one card profile with a specific CAID, and each connection is protected by a 14-byte DES key. This is not CCcam with its global channel — there is no concept of a "shared pool of cards" here. Each client sees only what is explicitly allowed to them on a specific port.

Reshare in the context of newcamd means one thing: the server received an ECM response (CW, Control Word) from a local reader or incoming line and forwards it to its clients. The newcamd protocol does not automate this — all the logic lies on the side of OScam or CCcam, which use newcamd as transport.

The difference between newcamd and CCcam protocol in reshare

CCcam transmits hop and distance parameters along with CW — the client knows how many nodes the response passed through. Newcamd does not transmit anything like that. The client receives CW and has no idea where it came from — from a local card or through a chain of three servers.

This means that the depth limitation of sharing in newcamd cannot be done automatically. Everything is done manually: through the parametersreshare andgroup in OScam, or throughF: { } in CCcam.

Scenarios: sharing a local card and re-exporting incoming lines

Two fundamentally different scenarios that are often confused. The first: you have a physical card in the reader (USB, built-in CI), and you want to share its decoded CW to newcamd clients. The second: you receive a line from someone (via CCcam or newcamd) and want to redistribute it to your pyram.

The configs for these scenarios look similar on the outside, but the grouping logic is different. In the first case, the reader is a physical device. In the second — a protocol connection that enters OScam asprotocol = newcamd orprotocol = cccam.

When reshare is prohibited by the provider's conditions

Most line providers explicitly prohibit re-export. This is stated in the terms of use and is technically controlled through load monitoring and the number of unique ECM requests. If your incoming line suddenly starts serving 20 clients instead of one — this is noticeable by response time and request patterns.

Re-exporting someone else's lines without explicit permission from the provider is a quick way to get your account banned. This material describes the technical mechanics of the setup; it makes sense to apply it only for your cards or with the explicit consent of the source.

Setting up a newcamd server in OScam (oscam.conf, oscam.server, oscam.user)

The OScam configuration files are by default located in/etc/tuxbox/config/ or/usr/local/etc/oscam/ — it depends on the distribution. On OpenPLi and Enigma2 boxes, it is most often/etc/oscam/. Before touching the configs, make sure throughps aux | grep oscam that the daemon is running, and remember the path from the-c argument.

Section [newcamd] in oscam.conf: port, key, allowed

In the main fileoscam.conf it describes which protocols the server listens to. For newcamd, a section is needed:

[newcamd]

The keykey is 14 bytes in hex, it must match on both the server and client. If you generate your own, use a proper random byte generator, not repeating sequences like0102030405060708091011121314 from the examples. This is the default key that everyone knows — it must be changed.

Port binding to caid in the format port = 16000@0500:000000

The formatport = number@CAID:ident. Zeros in ident mean "any provider of this CAID". For Viaccess CAID 0500, it looks like16000@0500:000000. For Nagravision 0B00 —16001@0B00:000000.

If you have multiple cards from different systems, each needs a separate port:

port = 16000@0500:000000|16001@0B00:000000|16002@1800:000000

One port — one CAID group. A client connecting to port 16000 receives only responses for CAID 0500. This is not a limitation, but an architectural feature of the protocol.

oscam.user: client account, group, au, caid/ident

The fileoscam.user describes each client. The minimal working block:

[account]

The parametergroup here is not a user group in the usual sense. It is a binding identifier: a client in group 1 will be served by readers that also have group = 1 specified inoscam.server. If the groups do not match — the client will connect, but no ECM will pass. This is the most common mistake during initial setup.

au = 1 enables automatic key updates (EMM). Set this only for trusted clients and only if the card supports it. If multiple clients haveau = 1 for one card — an EMM write conflict may occur.

Sharing a local reader through group binding

Inoscam.server the reader of the physical card looks like this:

[reader]

Group = 1 here and group = 1 inoscam.user — this is the link. OScam routes ECM from the client to the reader through this group logic. Add a second reader with group = 2, and clients from group 1 will not see it — this is convenient for separating sources.

Reshare of incoming lines: OScam as a newcamd proxy

Here the mechanics are a bit different. The incoming line is described as a reader with protocol = newcamd, and OScam turns into a proxy: it receives CW from an external source and gives it to its clients. This is newcamd reshare: configuration in re-export mode.

Incoming newcamd type reader in oscam.server

[reader]

Parameterinactivitytimeout = 30 sets how many seconds of inactivity before the connection is recreated. Without it, some lines silently die and do not reconnect — clients get a frozen screen without a single error in the logs.

Parameters cccreshare and reshare for proxying

Inoscam.user for accounts that are allowed further sharing, add:

reshare = 1

Value 0 — the client receives CW but cannot share further. Value 1 — can share one level. Value N — N levels deep. For most scenarios, reshare = 0 or reshare = 1 is sufficient.

Parametercccreshare relates to CCcam clients connected to the same OScam server. These are different parameters — confusion between them is a common problem.

Sharing restriction through ident and chid

If you do not want to give clients all packets from the incoming line — use filtering. Inoscam.user:

ident = 0B00:000000,000010

This restricts the client to specific providers and channel IDs. Useful when the incoming line provides more than you want to share, and you do not want to "expose" the source with excessive responses.

Group chain for separating sources

Working scheme with multiple sources: local card in group 1, incoming line in group 2. Assign clients of level A group = 1 (only local card), clients of level B — group = 1,2 (both sources). OScam uses a load balancer to choose the optimal reader when multiple are present in one group.

Reshare via CCcam with newcamd source (CCcam.cfg)

CCcam uses a different syntax and logic. The config is a single file/etc/CCcam.cfg. To connect a newcamd source, a line of the type is usedN:.

Line N: for connecting a newcamd source

N: provider-host.example 16000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

The DES key here is written byte by byte with spaces — 14 values in hex. This differs from the OScam format, where the key is written continuously. If you copy the key from the OScam config without breaking it — CCcam will not accept it and will not provide a clear error in the logs.

Parameter F: { } and hop/distance control

In CCcam.cfg, the lineF: describes which clients to accept and how to limit sharing:

F: clientuser clientpass 1 0 0

The third parameter is the maximum number of hops for sharing. When resharing a newcamd source, CCcam adds hop = 1 immediately. This means that CCcam clients will see this card with a distance of 1, and their clients will see it with a distance of 2. If a limit of 1 hop is set, the second level of sharing is already cut off.

Linking with C: lines and the danger of double sharing

If you are using simultaneouslyN: a source and sharing toC: clients — CCcam decides on its own which response to use. The problem is that CCcam when resharing newcamd: the setting throughN: does not always correctly process CAID mapping. I have seen situations where CCcam responded to an ECM from the wrong source and received a reject, while OScam with the same line worked without issues.

Mixing a newcamd source and CCcam sharing often leads to instability with frequent key changes. For serious infrastructure, I recommend OScam — it is more predictable in these scenarios.

Diagnostics: why reshare does not deliver channels

Most problems after the initial setup can be resolved in 10 minutes through the log. Enable debug mode inoscam.conf:

[logging]

For a complete picture, usedebuglevel = 255, but this is tons of data — only for short-term diagnostics. Check the log:tail -f /var/log/oscam.log | grep -i "ecm\|group\|reader\|rejected".

Log check: ecm rejected, group mismatch, no matching reader

The most telling messages:

• no matching reader — the client is in a group to which no reader is attached. Check the group in oscam.server and oscam.user.
• group mismatch — the same thing, but explicit. The client's group does not intersect with the reader's group.
• ecm rejected — the reader received the ECM but returned an error. Reasons: incorrect CAID, ident does not match, the card does not support this channel.
• connection refused when connecting the reader — network issue or incorrect port/address.

Check that the port is actually listening:ss -tlnp | grep 16001. If the port is not in the output — OScam did not start the newcamd section, look for an error during startup.

Mismatch of DES key and connection error

If the key does not match between the server and the client — the connection is established (TCP handshake passes), but newcamd authentication fails. In the logs, this appears as a connection drop immediately after connecting without an explicit message about the reason.

Check the key byte by byte. A common mistake is copying the key with spaces in OScam format (without spaces) or vice versa. OScam accepts0102030405060708091011121314, CCcam expects01 02 03 04 05 06 07 08 09 10 11 12 13 14.

Firewall and port forwarding (iptables/NAT)

If the server is behind a router, the newcamd port must be forwarded. Without this, external clients will not be able to connect, and the server will not even see the connection attempt in the logs.

Forwarding through iptables on the server itself (if it is also the router):

iptables -t nat -A PREROUTING -p tcp --dport 16001 -j DNAT --to-destination 192.168.1.100:16001

Additionally: in the section[newcamd] in oscam.conf the parameterallowed filters by IP. If a client comes from an IP not in the list, nothing is written to the log, the connection is simply dropped. Add the client's IP or temporarily remove the restriction for diagnostics.

Freezes due to ECM interval and timeouts

Freezes with active reshare are a separate story. If channels open but freeze every 10-30 seconds, look atecmwhitelist and the reader's timeouts:

[reader]

Enable loadbalancer: inoscam.conf the section[global], the parameterlb_mode = 1. It selects the reader with the lowest response time and automatically switches during degradation.

Also check the ping to the incoming line. The ECM response should arrive within 200-400 ms before the key window expires. If the ping is 300 ms to the source and there is also the overhead of OScam itself, freezes will start on the channel with a short key change interval. Solution: move the source closer orecm_timeout in the reader settings reduce to a real value.