How to Configure a CCcam N-line in OScam (2026 Guide)

If you've been handed a set of credentials and you're trying to get a cccam N-line in OScam working, there's a good chance your first attempt either threw a CONNECT ERROR or connected fine but decoded nothing. Both are fixable — but they require understanding what an N-line actually is before you touch the config file.

This guide covers the full setup: translating the N-line tokens into an oscam.server reader block, checking the WebIf to confirm the reader authenticated correctly, and tracking down the specific reason channels won't decode when everything looks fine on paper.

What an N-line Actually Is (and Why OScam Handles It Differently)

The naming here causes a lot of confusion. An N-line is a newcamd client line. It has nothing to do with CCcam's own protocol — it just sometimes gets bundled in CCcam.cfg files alongside C-lines, which is where people get tripped up.

The canonical format looks like this:

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

That last block of 14 bytes is a DES key — 28 hex characters — and it's mandatory for newcamd authentication. No equivalent exists in CCcam's C-line format, which is one of the giveaways you're dealing with a different protocol.

N-line vs C-line vs F-line: the protocol difference

A C-line is CCcam protocol: C: host port username password. No DES key. An N-line is newcamd protocol: requires that 14-byte key for the initial handshake. An F-line is a friend/peer line used in CCcam for trusted server connections — not relevant to OScam client setup.

The reason people conflate C-lines and N-lines is that CCcam.cfg can contain both, and some providers send a "CCcam config" that actually includes N-lines pointing to a newcamd backend. Read the line prefix. N: means newcamd, full stop.

The newcamd protocol behind the N-line

Newcamd (specifically newcamd525, sometimes newcamd524 on older setups) is a card-sharing protocol that uses DES encryption for the initial key exchange. The client sends the 14-byte key to the server during the handshake. If the key is wrong — wrong byte count, wrong format, extra spaces — auth silently fails or throws a key error. The server never tells you exactly why it rejected the handshake, which is one reason misconfigured DES keys are hard to debug.

Newcamd525 is the current standard. If your source is running older software, newcamd524 may be what they're serving. A mismatch here causes silent auth failure — the TCP connection establishes, then dies without explanation. If newcamd525 fails and you're certain the credentials are correct, try newcamd524.

Why OScam calls it a cccam reader vs a newcamd reader

OScam supports both protocols, but they use different protocol = values in oscam.server. When you configure a newcamd reader, you set protocol = newcamd525. When you configure a CCcam C-line reader, you set protocol = cccam. They're not interchangeable. A lot of guides just show you the cccam protocol block and call it done — that won't work if the credentials you have are actually N-line (newcamd) credentials.

Adding the N-line to oscam.server Step by Step

OScam doesn't use a single-line format like CCcam.cfg. Every connection you want to configure becomes its own [reader] block in oscam.server. Each token from the N-line maps to a specific parameter in that block.

Locating and editing /etc/tuxbox/config/oscam.server or /var/keys

The config path depends on how OScam was launched. Common locations:

• /etc/tuxbox/config/oscam.server — most embedded Linux setups (Dreambox, Vu+)
• /usr/keys/oscam.server — some older images
• /var/keys/oscam.server — common on OpenATV and similar
• Whatever path follows the -c flag in the OScam startup command

If you're not sure, open the WebIf (typically http://box-ip:8888), go to Files, and it shows you the active config directory. Edit the file directly with a text editor over SSH — nano works fine.

Building the [reader] block for a newcamd N-line

Take this example N-line:

N: myserver.example.com 15000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

It maps to this oscam.server reader block:

[reader]label = my_newcamd_readerprotocol = newcamd525device = myserver.example.com,15000key = 0102030405060708090a0b0c0d0euser = myuserpassword = mypasswordgroup = 1reconnecttimeout = 30

Notice the DES key. In the N-line it's given as 14 space-separated byte values. In oscam.server, the key = field expects those same 14 bytes as 28 continuous hex characters — no spaces, no colons. So 01 02 03 04 05 06 07 08 09 10 11 12 13 14 becomes 0102030405060708090a0b0c0d0e. Uppercase hex is fine, OScam normalizes it.

Setting protocol, device, key, and account fields

Break down each field:

• label — any unique name you want, used in the WebIf and logs
• protocol — newcamd525 for an N-line (or newcamd524 if the source is old)
• device — hostname,port from the N-line. No space after the comma.
• key — 14 bytes as 28 hex chars. Strip spaces and colons from whatever format the provider gave you.
• user / password — case-sensitive. Copy exactly as provided.
• group — an integer that must match a group = value in oscam.user for your local client. Without this link, the reader connects but serves nothing to local channels.

You can optionally add caid = 0500 (or whatever CAID applies) to limit the reader to specific card systems. Leave it out initially — add it later to tune if you have multiple readers.

Optional: adding a CCcam C-line as a cccam reader for comparison

If your provider gave you a C-line instead of or alongside the N-line, the block looks different:

[reader]label = my_cccam_readerprotocol = cccamdevice = myserver.example.com,12000user = myuserpassword = mypasswordcccversion = 2.3.0cccmaxhops = 1group = 1

No DES key. The cccversion field tells the server what CCcam version to emulate — 2.3.0 is a safe default if you don't know what the server expects. Set cccmaxhops = 1 initially to avoid re-shared cards; raise it only if you're not seeing the CAIDs you need.

Verifying the Connection in the OScam WebIf and Logs

Once you've saved oscam.server and reloaded OScam (more on that shortly), the WebIf is where you check whether the reader actually connected.

Reading the reader status: CONNECTED vs CARDOK vs CONNECT ERROR

In the WebIf under Readers, each reader shows a status string. Here's what they mean:

• CONNECTED — TCP connection is up, authentication passed. The server accepted your credentials.
• CARDOK or AU — A card was found at the server and entitlements are visible. This is what you want.
• CONNECT ERROR — TCP failed or auth was rejected. Network or credential issue.
• card not found — Connection OK, but no valid card for the CAID you're requesting.
• WAITING — OScam hasn't tried to connect yet, or is in the reconnect backoff window.

CONNECTED but no decode means auth passed but something downstream is wrong — CAID/ident mismatch, group linkage, or the account doesn't cover the channel you're testing.

Using oscam.conf [webif] to enable live logging

If the WebIf isn't running, add this to oscam.conf:

[webif]httpport = 8888httpuser = adminhttppwd = yourpasswordhttprefresh = 3

For debug logging, either set loglevel = 4 in oscam.conf's [global] section or start OScam with the -d 64 flag. The WebIf Log tab then shows live output. The relevant lines start with the reader label you set, so they're easy to grep.

Interpreting ECM/EMM counters and response times

In the Readers tab, the ECM column shows how many decrypt requests the reader has answered, and the response time column shows milliseconds per ECM. Under ~400ms is healthy. Over 800ms and you'll see channels stuttering or cutting out. If the reader is answering ECMs but with high times, the source card is overloaded or the network path is congested — not a config problem.

The Rejected counter climbing means ECMs are being sent to the reader but it's not decrypting them. That points to CAID/ident filtering or missing entitlements.

Checking CAID and provider IDs the reader actually exposes

In the WebIf, click the reader label to expand its details. Under Entitlements, you'll see which CAIDs and provider IDs the server card is actually offering. If your target CAID (e.g., 0500 for Viaccess, 0604 for Irdeto, 1810 for Nagravision) isn't listed there, no amount of config tweaking will get those channels to decode — the card simply doesn't have the entitlement.

Fixing the Most Common N-line Errors in OScam

Most failures configuring a cccam N-line in OScam fall into four buckets. Here's how to map the symptom to the actual fix.

CONNECT ERROR / connection refused — network and port issues

The reader shows CONNECT ERROR or immediately drops back to WAITING. Causes in order of likelihood:

• Wrong port — double-check the port number from the N-line. Newcamd typically uses ports in the 10000–15000 range but it varies.
• Firewall blocking outbound — on some receiver firmwares, iptables blocks non-standard outbound ports. Test with telnet hostname port from the box over SSH.
• IP not on the provider's allowlist — many setups only allow specific client IPs. If your ISP gave you a dynamic IP, a re-assignment will break the reader until the provider updates the allowlist. This is the most common cause of "worked yesterday, broken today" situations.
• DNS resolution failing — try replacing the hostname with the actual IP in the device = field to rule this out.

Wrong DES key or login rejected — auth failures

The TCP connection opens but immediately closes, or logs show auth failed. Nine times out of ten, the DES key is the problem.

The key must be exactly 28 hex characters. Providers sometimes give it with spaces (01 02 03...), with colons (01:02:03...), in uppercase, or split across lines. Strip everything — spaces, colons, line breaks — until you have a solid 28-character hex string. Count the characters. If you have 27 or 29, something got dropped or duplicated in copy-paste.

Username and password are also case-sensitive. MyUser and myuser are different accounts. Copy from the N-line directly, don't retype.

Connected but no decode — CAID, ident, and sid filtering

This is the one that drives people crazy. The reader shows CONNECTED or CARDOK, but tuning a channel produces nothing — no ECM response, or ECMs rejected.

First check: is the group = value in your [reader] block listed in the group = field of the relevant entry in oscam.user? This is the most commonly missed step. The reader being connected doesn't mean your local OScam client is authorized to use it. The group assignment is what bridges the reader to the client.

Second check: if you've added a caid = or ident = filter to the reader, temporarily remove it and test. Overly strict ident filters are a common culprit — the card might serve provider ID 000000 but you've filtered for 003311, so OScam rejects every ECM before it even reaches the reader.

Third check: confirm the CAID for the channel you're testing matches what the reader actually exposes. Open the reader in the WebIf, check Entitlements.

Card found but frozen channels — hop, ecm-time, and freeze problems

CARDOK is showing, ECMs are being answered, but the channel freezes every few seconds. This is usually one of:

• ECM response time too high — if ECM time is regularly over 600–700ms, the channel can't decrypt fast enough before the next CW is needed. Not a config fix; it's a source quality issue.
• Too many hops — a card re-shared four or five times accumulates latency. Each hop adds ~50–150ms. Setting cccmaxhops = 1 or 2 on a CCcam reader limits this.
• Multiple readers for the same CAID causing load-balance to a dead source — if OScam's load balancer is round-robining between a working reader and a dead one, half your ECMs fail. Fix with lb_weight or set the dead reader to fallback = 1 so it's only used when the primary fails.
• cacheex misconfiguration — if you've enabled cacheex (ECM cache exchange) and the hash configuration is wrong, you can get cache collisions that serve stale CWs. Disable cacheex on the reader and test clean.

How to Judge Whether an N-line Source Is Worth Keeping

Getting a cccam N-line in OScam connected is one thing. Knowing whether the source is actually reliable is another. Here's how to evaluate it on measurable criteria — no guesswork.

Objective criteria: ECM time, uptime, and freeze rate

A decent source delivers consistent ECM response times under 400ms. Under 200ms is good. Over 500ms and you'll notice freeze artifacts on channels with fast CW rotation (most HD sports channels rotate every 10 seconds; some rotate faster).

Run the reader for 24 hours and check the ECM/reject counters in the WebIf. A healthy ratio is well under 1% rejected ECMs. If you're seeing 10%+ rejects, either the entitlements are partial or the source is under load. Check back at different times — a source that performs fine at 3am but freezes during prime time is oversubscribed.

Hops matter directly. A hop-1 reader (direct card) beats a hop-3 re-share on both latency and reliability. Fewer nodes in the chain means fewer single points of failure.

Matching the source CAID/ident to your actual channels

Before committing to a source, confirm via the WebIf Entitlements view that the CAID and provider IDs match what your channels actually broadcast. Your tuner picks up a channel, your EPG says it's on a specific satellite transponder, and you can verify the CAID from that transponder (databases like LyngSat or your receiver's signal info screen show this). If the source doesn't list that CAID in its entitlements, it can't decode those channels regardless of connection quality.

Multiple CAIDs from a single N-line is possible — a single card can carry several packages. But don't assume coverage; check the entitlement list explicitly.

Red flags in a shared line

A few things indicate a source isn't going to hold up:

• ECM times that spike wildly rather than staying consistent — suggests an overloaded or poorly-connected backend card
• The reader disconnects and reconnects every few hours — usually a server-side stability problem or an IP allowlist issue
• Entitlements show a CAID but with an expiry date that's already passed
• The source gives you a newcamd524-format DES key that doesn't work on newcamd525, and the provider can't tell you which protocol they're actually running — that's a support competence flag
• Dynamic IP on your end with no allowlist update process — you'll get periodic outages every time your ISP reassigns your IP

One practical test: find a channel that rotates CWs every 10 seconds on a known CAID, watch it for 20 minutes during peak hours, and count the freeze events. That's more informative than any stat a provider quotes you.