Newcamd reshare: setting up reshare on OScam in 2026

If you have already set up OScam, the reader works locally, channels open — and then silence: the peer does not receive the card, the reshare gets lost somewhere, ECM fails with an error — this means you have reached the murkiest place in the entire cardsharing ecosystem.Newcamd reshare: setting up this mechanism is full of nuances that are not properly explained anywhere. Let's break everything down step by step, with real configs and diagnostics from the logs.

What is newcamd reshare and when is it really needed

Newcamd is the good old TCP protocol for transmitting CW (Control Words) between the cardsharing server and the client. It appeared back in the era of the first Linux receivers, and has changed little since then. It works by default on ports from 28000 and above, encrypts traffic with a DES key of 14 hex characters (which is actually a 56-bit key, about the confusion with this — below).

The main difference from CCcam: one newcamd port serves exactly one card (one CAID). This is not a bug, it is the architecture of the protocol. If you want to share two cards with different CAIDs — open two ports. Many configurators stumble here.

Newcamd protocol: port, DES key encryption, difference from CCcam

CCcam is much smarter in terms of multi-card support: one port (by default 12000) handles everything available on the server, negotiates with the client about available CAIDs, and carries information about the hop distance to the card in the protocol. Newcamd fundamentally cannot do this.

The DES key is specified in the config as 14 hex characters, for example0102030405060708091011121314. The client and server must match character by character — one extra digit and you will getwrong DES key / login failed. The encryption is weak by modern standards, but the protocol is legacy, no one will change it.

Newcamd is justified in two situations: when you have an old receiver that only understands newcamd525 and does not support cs378x, and when you need to strictly limit access to a specific card through a separate port with a separate key — without the risk of accidentally opening other CAIDs.

How reshare differs from regular card sharing

Regular sharing: the server holds the card, the client connects and receives CW. Reshare is when the client, having gained access to the card, starts sharing it with its peers further. It sounds simple, but this is where the logic of groups and rights comes into play.

In OScam, reshare is regulated not by a "allow/deny" flag at the level of a single parameter, but by a combination: what group the reader is in, what group the user is in, and what exactly is being shared externally. If this is not thought out in advance — either the reshare does not work at all, or it goes where it shouldn't.

Reshare chain: hop and packet quality loss

In CCcam, hop is a numerical counter built into the protocol. A card with hop=0 is local, with hop=1 is received from a peer, with hop=2 is a reshare of a reshare. The higher the hop, the higher the ECM time and the greater the risk of freezes.

Newcamd does not carry hop as such. The protocol transmits the card "flatly" — the client simply sees a working CW, without metadata about the depth of the chain. But delays accumulate physically: each link adds network latency. A chain of three servers on different continents is a sure path to freezes during prime time.

Setting up newcamd reader and account in OScam

The configuration files for OScam are located in/etc/oscam/ on most distributions. On older Enigma2 boxes, the path may be/etc/tuxbox/config/oscam/ or/var/etc/oscam/ — it depends on the image. The main files:oscam.conf,oscam.server,oscam.user.

Section [reader] with protocol = newcamd525

When you connect to an external newcamd server as a client, inoscam.server a reader is created with the protocolnewcamd525. The minimum working block looks like this:

[reader]

The parameterdevice is the IP and port of the server. If the server is behind NAT, a public IP or port forwarding is needed. The parameterau = 1 enables EMM transmission; without it, the card will not be updated and will lose its subscription after some time.

The parameters key, device, and the binding of CAID/ident

This is where people often get confused. The DES key is displayed as 14 hex characters in the OScam config, but internally it is 16 bytes with padding. When copying the key from the provider, make sure to take exactly 14 hex, without spaces and extra characters. Different clients (CCcam, MGcamd) sometimes write the key with spaces between every two digits — OScam does not accept this format.

The parameterscaid andident limit which requests the reader will process.0500:000000 is CAID 0500 (Viaccess) with a zero provider. If ident is not specified, the reader will respond to all requests for this CAID, which can sometimes lead to conflicts with multiple readers.

The file oscam.user: group, caid, ident, au

Inoscam.user the clients that connect to your server are specified. The key point:the group of the user must match the group of the reader. This is not an optional recommendation — it is a mandatory condition. Without matching groups, OScam simply does not route the request to the correct reader, and the client receives "no cards".

[account]

The parameterau = 1 for the client allows them to receive EMM streams for card updates. If you leaveau = 0 — the client will watch channels, but the card will not be updated, and after some time the subscription will drop on their side. This is important for reshares: if the intermediate server does not transmit EMM, the end client in the chain does not receive updates.

The config newcamd.list / oscam.conf section [newcamd]

For OScam to accept connections via the newcamd protocol, inoscam.conf a section is needed[newcamd]:

[newcamd]

The formatport = 28000@0500:000000 reads as follows: port 28000 serves CAID 0500, provider 000000. A separate port 28001 is opened for the second card (CAID 0600). One port — one CAID. This is a fundamental limitation of the protocol, which causes 80% of questions on forums.

Filenewcamd.list — is the config for MGcamd and some other clients, the format there is slightly different. In the context of OScam as a server, it is not used — everything is configured throughoscam.conf andoscam.user.

Enabling reshare and controlling the depth of reshare

Here begins the most interesting part. Newcamd reshare: the configuration of the depth control of reshare is fundamentally different from how it works in CCcam.

The parameter cccreshare / reshare at the server and reader level

In OScam, the parameterreshare relates to the CCcam leg, not to newcamd. If you share a card through the CCcam port, then in the section[cccam] of theoscam.conf file there isreshare (globally) and at the reader level —cccreshare:

[cccam]

The valuereshare = 0 prohibits the pyramid from sharing the card further.reshare = 1 — allows one level of reshare. For newcamd clients, this parameter does not exist — control goes through group logic and who is given access to the reader.

At the level of a specific reader: the parametercccreshare = 0 in the block[reader] prohibits sharing this card through the CCcam leg, even if globally reshare is allowed.

Limiting the number of hops and preventing loops

A loop is when two servers mutually share the same card with each other. Server A gives the card to server B, B gives it back to A, A sees the "new" card again and gives it back to B. The ECM starts to go in circles, response time increases, the channel freezes or disappears altogether.

In CCcam, protection against loops is built-in through a hop counter — a card with hop=X cannot return back with hop=X+1 to the same server. In newcamd, this protection is absent. Therefore, when mutually sharing between two newcamd servers, it is necessary to manually limit: one server gives, the other only receives — not the other way around.

Practical advice: use different groups for incoming and outgoing readers. Local cards — group 1, received from peers — group 2, what is shared outside — group 3. Never place an incoming and outgoing reader in the same group.

Separate reshare for local and remote cards

A good practice is to prohibit the reshare of cards that you receive through reshare. A local card (physically inserted into the server or card reader) — can be shared. A card received from a peer — share with caution, or better not share at all without an explicit agreement with the source.

Technically: place the local physical reader in group 1, the external newcamd reader — in group 2. Give clients outside access only to group 1. Clients in group 2 see nothing except what they are entitled to.

Checking operation and reading logs

The first thing I do after changing the config is check the webif. By default, OScam opens the web interface on port 8888:http://localhost:8888. There you can immediately see the status of each reader — green means "connected and responding," red means "no connection or authorization error."

Webif: reader status, ECM time, statistics

In the "Readers" section, webif shows the time of the last ECM response in milliseconds. A normal indicator for a local card is 50–150 ms. For a card through a peer, 200–500 ms is acceptable. More than 800 ms — expect freezes.

In the "Users" section, you can see who is connected, how many ECMs have been processed, and if there were any errors. The "Decode" column shows the percentage of successfully decrypted requests. If it's 0% with an active connection — check for group mismatch in the logs.

Log tag: CW received, no cards, group mismatch

Enable detailed logging inoscam.conf:

[logging]

Level 4 is the maximum detail, including ECM and EMM. In production, it's better to set it to 2–3, otherwise the log grows quickly.

Key lines in the log:

• no matching reader found (group mismatch) — the group of the reader and user do not match. The first thing to check.
• CW received from reader peer_newcamd — all good, CW has arrived.
• no card available — the reader is connected, but the CAID/ident of the request does not match what the reader serves.
• wrong DES key — the key does not match.

Checking the port via telnet/nc and tcpdump

Make sure that OScam is listening on the required port:

ss -tlnp | grep 28000

If the port is not in the list — newcamd did not start. Checkoscam.conf section[newcamd] and restart OScam.

Quick external connection check:

nc -zv 192.168.1.100 28000

If "Connection refused" — firewall or OScam is not listening. If "Connected" but channels are not coming — the problem is in authorization or group logic.

For deep diagnostics, when it's unclear if packets are reaching:

tcpdump -i eth0 -n port 28000

If there is traffic, but OScam does not respond — check the log at level 4.

Typical newcamd reshare errors and their resolution

Let's break it down by the scheme "symptom → cause → fix." These are the most common pitfalls when setting upnewcamd reshare.

The client connects, but the channels do not open (CAID/ident)

Symptom: in webif the client is visible as connected, ECM requests come in, but the status is "not decoded".

Reason 1: CAID or ident inoscam.user does not match what the client requests. The client sends a request for CAID 0500, but only 0600 is specified in their account.

Reason 2: group mismatch. User in group 2, reader in group 1 — OScam does not see the link.

Correction: checkoscam.user — fieldcaid andgroup. Compare with the group of the reader inoscam.server. They must match.

Wrong DES key / login failed

Symptom: in the logwrong DES key orlogin failed, the client does not even pass authorization.

Reason: key mismatch. The most common options: copied the key with spaces, added an extra character, mixed up upper/lower case (case in the DES key is ignored by OScam, but it's better not to take risks), took a 16-byte version of the key instead of the 14-character one.

Correction: copy the key again from the source, make sure it is exactly 14 hex characters without spaces. Check simultaneously inoscam.conf section[newcamd] and in the client's reader — they must be identical.

EMM does not pass — the card does not update

Symptom: channels work, but after some time (days, weeks) the subscription "drops" and the card stops decoding.

Reason 1: au = 0 for the client — EMM is not transmitted.

Reason 2: somewhere in the re-sharing chain au is turned off, EMM does not reach the physical card.

Reason 3: client behind NAT, EMM stream does not return to the source.

Fix: setau = 1 for all intermediate accounts in the chain. Check that the log shows the linesEMM written.

High ECM time and freezes with a long chain

Symptom: periodic freezes of 2–5 seconds, especially during prime time. ECM time in webif jumps from 300 to 2000+ ms.

Reason: too long re-sharing chain, overloaded source or poor channel between links.

Fix: enablecacheex at the OScam level — it caches CW and reduces the load on the source with multiple clients. Shorten the re-sharing chain — remove unnecessary links. Check ping to the source, a normal value is up to 50 ms.

Criteria for choosing a card source for stable re-shares

The technical part of the setup is only half the job. Even an ideal config won't save you if the card source is unstable or sits behind three re-shares. Here's what to look for when choosing.

What to look for: uptime, ECM time, card locality

ECM time is the main indicator of source quality. For stable operation, it should not exceed 300–400 ms during peak times. If the source provides stable 100–150 ms — this is a sign of a local card, not a long re-sharing chain.

Uptime is equally important. A source that restarts every two days or disappears for several hours is a bad source for re-shares, because all your clients will see interruptions simultaneously.

Card locality — ask directly. A good source will say that the card is physical and is in a specific card reader. If the answer is evasive or sounds like "the card is great, everything works" — it's likely a resale of someone else's re-share.

Signs of an unstable source

ECM time is consistently high (600+ ms) or fluctuates greatly — a clear sign of overload or a long chain. Freezes during prime time (19:00–23:00) with normal operation at other times — the source is overloaded during peak hours. Frequent reconnections in the log — the source server is unstable or restarting.

Another sign: if the source cannot answer a simple question "what CAID and provider does the card have" — this is suspicious. A normal operator of their card knows this by heart.

Legal aspect: only legally acquired subscriptions

This material is purely technical and educational in nature. All described functionality of OScam is intended for working with cards for which you have a legally issued subscription — that is, the card is purchased from an official operator and is in your physical device.

Using card sharing to access paid content without an active subscription violates the laws of most countries and the terms of use of operators. Setting up newcamd reshare: configuring your own equipment with your own cards is a technically legal task. Everything else is the user's responsibility and beyond the scope of this article.