Newcamd reshare: setting up reshare in OScam

Setting up newcamd reshare can be a challenging task, especially if you are encountering this technology for the first time. In this article, I will share a step-by-step guide on setting up reshare, explain the main parameters, and provide debugging tips. We will discuss how to properly configure OScam for sharing a card or subscription via the newcamd protocol so that other clients can access your content.

What is newcamd reshare and when is it needed

Newcamd reshare is the process of redistributing received ECM access to third parties. This is useful when you have access to paid channels and want to share it with other users. The newcamd protocol differs fromCCcam in that a separate port is used for each CAID and provider.

The difference between sharing and reshare

Sharing implies that you are sharing access to your card with other clients. Reshare, on the other hand, allows you to pass access to other servers or clients. This is an important distinction as it affects the settings and access rights.

Reshare via newcamd vs CCcam

UnlikeCCcam, where everything goes through one port, newcamd uses separate ports for each CAID and provider. This makes the setup more flexible but also more complex. For example, if you want to share multiple cards, you will need to open several ports.

The concept of hop and levels of reshare

Hop is the number of levels of reshare. Hop 0 means a direct card, Hop 1 means the first reshare, and so on. It is important to understand that each reshare increases latency and can lead to freezes. Therefore, it is better to limit the number of levels of reshare.

Server setup: oscam.conf and newcamd.server

Now let's move on to the setup. In the file /usr/local/etc/oscam.conf (or /etc/tuxbox/config/oscam/), you need to add the [newcamd] section. Example block:

[newcamd]

The format of the port parameter is as follows: PORT@CAID:IDENT1,IDENT2;PORT2@CAID2. Note that the 14-character DES key must match on both the server and client; otherwise, you will get "login ok" but "no decode".

The [newcamd] section in oscam.conf

The [newcamd] section in oscam.conf is responsible for the card access settings. Make sure that the key and port are correctly specified; otherwise, decoding will not be possible.

Parameters key, port, and CAID

The key parameter is a 14-character DES key. The port parameter indicates the port and CAID. If you are using multiple CAIDs, you will need to specify them in one line, as shown above.

Binding a port to a specific provider

Each port must be bound to a specific provider. This means that you cannot have one port for multiple CAIDs. If you have multiple cards from different providers, open a separate port for each.

Access rights and enabling reshare in oscam.user

After setting up the server, you need to configure access rights in the oscam.user file. Example block:

[account]

The connection between group in [reader] and [account] is very important. Without matching groups, decoding will not work, so make sure they match.

Creating a user for the client

When creating a user for the client, you must specify the correct parameters such as username, password, and group. This will allow the client to access your reshare.

Parameters au, group, and caid

The au parameter is responsible for automatic updates, group is for the connection between the reader and the account, and caid determines which card will be shared.

Flags cccreshare and uniq for controlling sharing

To limit the depth of reshare, you need to add the parameter cccreshare = N in the [reader] block. The uniq flag determines the number of simultaneous connections with one login: 1 — prohibited, 2 — allowed, 3 — allowed, etc.

Checking and debugging sharing through the web interface and logs

After setup, it is important to check how your reshare is working. To do this, open the OScam web interface. By default, the port is 8888 or the one you specified in the httpport parameter. The Status tab will show whether the client is connected, its status, hop, and ecm time.

Monitoring client status in webif

In the webif, you can see the status of connected clients, their hop, and response time. This will help quickly identify connection issues.

Reading oscam.log and ECM levels

OScam logs contain a lot of useful information. For example, if you see 'found', it means the key is found. If 'not found', check permissions and settings.

Checking hop and response time (ms)

To check how your reshare is working, use the commandnetstat -tulpn | grep 15000 to check the open port. This will help you ensure that the port is available for clients.

How to choose a source for reshare without compromising stability

Choosing a source for reshare is an important point. An incorrect choice can lead to high latencies and poor image quality. Look for a source with low ECM time (up to 300-400 ms), stable uptime, and support for the required CAID.

Criteria for a reliable incoming source

A reliable source should provide a stable connection and minimal delays. Additionally, it is important that it supports the CAID you need.

The impact of hop depth on speed

Each hop level adds latency. Therefore, try to limit their number. Reshare with hop 1 is preferable to long chains, as it reduces the risk of freezes.

Limiting load and number of clients

It is recommended to limit the number of simultaneous clients on one source. This will help avoid overloads and ensure a stable data stream.