Newcamd vs CCcam Protocol: Which Is Better in 2026?

If you're picking between newcamd and CCcam for an OScam setup in 2026, here's the answer before you read another 300-word listicle: Newcamd is a card-emulation protocol that exposes exactly one card per port, built for moving a single smartcard reader across a LAN. CCcam is a proxy protocol that multiplexes many cards over one TCP connection, with hop counting and reshare baked in. When people ask newcamd protocol vs cccam protocol: which is better in 2026, they're usually asking the wrong question — these solve different problems, and the right pick depends entirely on your topology.

I've run both in production sharing setups, and the short version is this: if you own the card and want deterministic, low-latency access from a second box, use Newcamd. If you're aggregating CAIDs from multiple sources over a single link, use CCcam. This article walks through the actual protocol internals, gives you copy-pasteable OScam config blocks, and covers the failure modes nobody bothers to explain.

Newcamd vs CCcam at a Glance: The Real Technical Difference

Newcamd was designed around a simple idea: take a physical smartcard sitting in a reader and make it available over a network connection as if it were local. One card, one listening port. That's not a limitation someone forgot to fix — it's the architecture. A server with 5 physical cards running Newcamd needs 5 separate listening ports, and every client that wants access to all 5 cards needs 5 separate [reader] blocks in its oscam.server, one per port.

CCcam takes the opposite approach. One login gets you a connection, and the server pushes down a full card list — every CAID and provider ID it's willing to share, each tagged with a hop value. The client can then reshare those same cards to its own downstream clients at hop 2, hop 3, and so on. That's the whole point of CCcam: it's a peering and aggregation protocol, not a point-to-point card link.

Newcamd: a one-card, point-to-point card protocol

Think of Newcamd as a network extension cord for a physical card. The client connects, authenticates, and gets ECM/CW traffic for exactly the CAID and provider IDs configured on that port. No card list negotiation, no reshare logic. It's deliberately dumb, and that's a feature.

CCcam: a multi-card proxy/peering protocol

CCcam clients don't know in advance what they're getting — the server tells them on connect. This is what makes CCcam good at aggregating: one connection can carry a dozen CAIDs from a dozen different physical cards sitting behind that server, possibly reshared from further upstream.

Why 'which is better' is the wrong question

In 2026, almost every serious setup out there is OScam talking to OScam, and OScam speaks both protocols natively out of the box. Neither one is a software limitation anymore — it's purely an architectural decision you make based on how many cards you have, who owns them, and how many hops you're willing to tolerate. Asking newcamd protocol vs cccam protocol: which is better in 2026 without specifying your topology is like asking whether a wrench is better than a socket set without saying what bolt you're turning.

Quick decision table: topology, card count, hop needs

Protocol Internals: Encryption, Handshake, Ports and Packet Flow

This is where most articles stop and mine keeps going, because the internals are exactly what explains the behavior you'll see in your logs later.

Newcamd: DES key handshake, the 14-byte DES key, login/password auth

When a Newcamd client connects, it presents a login and password. The server derives a session key from a configured 14-byte DES key — written out as 28 hex characters in your config — and both sides use that derived key to encrypt the ECM/CW exchange for the rest of the session. Get one hex character wrong on either end and you don't get a helpful error. You get a silent authentication failure. The socket connects, the handshake completes at the TCP level, and then nothing decodes. This trips up more first-time setups than any other single config mistake in Newcamd.

Newcamd carries exactly one card's CAID and provider IDs per port. The client either has to know them in advance from the server operator, or read them off the connection when OScam performs its initial handshake and reports entitlements.

CCcam: node ID, username/password, CCcam's obfuscated framing

CCcam auth is username/password like Newcamd, but the framing underneath uses CCcam's own obfuscation scheme rather than DES, and the server identifies itself with a node ID as part of the handshake. Once authenticated, the server immediately pushes the card list — CAID, provider ID, and hop count for every card it's offering — and the client's OScam instance builds its internal reader map from that list on the fly.

Default and conventional port ranges

Newcamd doesn't have one official port — conventionally you'll see it running somewhere in the 34000-34009 range, one port per card, though plenty of operators use whatever's free. CCcam traditionally sits somewhere in the 12000-13000 range, most commonly 12000 or 15963 depending on the build, but again this is convention, not a spec requirement. Check your own oscam.conf or CCcam.cfg rather than assuming.

How ECM requests actually travel: request, forward, CW return

Under Newcamd: your receiver tunes a channel, OScam generates an ECM request, sends it over the Newcamd socket to the card server, the physical card processes it, and the control word comes straight back over the same socket. One hop, one round trip.

Under CCcam: your receiver generates the same ECM request, but now OScam has to pick a reader from potentially several candidates offering that CAID at different hop depths. If the card you're hitting is itself a reshare from another CCcam server upstream, your ECM request has to travel to that box, get processed by the physical card, and the CW has to travel back through the same chain. Every hop adds a full round trip.

Hop counting and card reshare — a CCcam-only concept

Newcamd has no concept of hops because it's structurally incapable of reshare — there's no card list to pass along, just one card on one port. Hop counting exists purely in CCcam because reshare is the whole design. A card at hop 1 came straight from the physical reader. A card at hop 3 has been reshared twice, meaning your ECM request is now dependent on three separate boxes all being online and responsive at the same time.

Keepalives, timeouts and why one protocol drops first

OScam's inactivitytimeout and reconnecttimeout settings apply to both protocol types, but they behave differently in practice. A Newcamd reader with no traffic for the configured inactivity window just reconnects — it's a single link, so recovery is fast and obvious. A CCcam reader that goes quiet might be waiting on an upstream hop that's slow rather than actually dead, so a card can sit in a degraded state longer before OScam decides to reconnect. Set reconnecttimeout deliberately rather than leaving defaults if you're chaining multiple hops.

Configuring Both Protocols in OScam (Working Config Blocks)

Before you touch anything, confirm where OScam is actually reading its config from. Common candidates are /etc/tuxbox/config/, /usr/local/etc/, and on some embedded receivers /var/keys/. The definitive answer is whatever path your init script passes with the -c flag — check ps aux | grep oscam if you're not sure, and edit the config that flag actually points to, not the one that looks right.

OScam file layout

You're working with three files at minimum: oscam.conf for the protocol listeners, oscam.server for reader definitions (both the cards you own and the ones you connect to remotely), and oscam.user for the accounts you're serving out.

Newcamd server: the [newcamd] block and per-port card mapping

In oscam.conf:

[newcamd]port = 34000@0500:000000key = 0102030405060708091011121314allowed = mgclient = 0

The port line binds 34000 to CAID 0500, provider 000000. If you're serving a second card, that's a second port line with its own CAID/provider pair — this is the one-port-per-card rule in practice. The key is your 28-hex-char DES key; the value above is a placeholder, generate your own.

Newcamd client: a [reader] block with protocol = newcamd525

In oscam.server on the client box:

[reader]label = card1_newcamdprotocol = newcamd525device = 192.168.1.50,34000user = clientuserpass = clientpassdes_key = 0102030405060708091011121314group = 1caid = 0500inactivitytimeout = 30

des_key here must match the server's key line character for character. This is the single most common silent-failure point in Newcamd setups.

CCcam server: [cccam] block, port, reshare and stealth settings

[cccam]port = 12000reshare = 1stealth = 0version = 2.3.0nodeid = 0011223344556677

On the account side in oscam.user, you can override reshare depth per user:

[account]user = frienduserpass = friendpassgroup = 1cccmaxhops = 1cccreshare = 0

CCcam client: [reader] with protocol = cccam, cccversion and cccmaxhops

[reader]label = upstream_cccamprotocol = cccamdevice = share.example-host,12000user = myuserpass = mypasscccversion = 2.3.0cccmaxhops = 2group = 2inactivitytimeout = 20

Per-user [account] entries, group matching and why group = 1 mismatches silently

Here's the thing that breaks more first attempts than anything else in this whole article: the group number in your [reader] block and the group number in the matching [account] entry have to overlap, or OScam will never route an ECM to that reader for that user. There's no error for this. The reader shows CONNECTED, the account shows valid, and nothing decodes. If your reader is group = 1 and your account is group = 2, they simply never talk to each other as far as OScam's routing logic is concerned. Groups are a bitmask, not a single number comparison — group 3 matches both 1 and 2.

Verifying with the OScam web interface and the live log

Open the webif, default port 8888, and check the Readers page. A working reader shows CONNECTED and its Entitlements list should show the CAID and provider you expect — if entitlements are empty, the card side is the problem, not routing. Then set debug level 1 (ECM) in the log and watch a real zap: you should see the ECM go out to that reader by label, and a CW come back with an actual time in milliseconds. That millisecond number is the only ECM time you should ever trust — not anything published on a forum.

Legacy CCcam.cfg syntax for readers maintaining old boxes

If you're still touching a box running native CCcam rather than OScam, the config is /etc/CCcam.cfg, and it uses a completely different line syntax: C: lines for clients you connect out to, F: lines for accounts you serve.

C: share.example-host 12000 myuser mypassF: frienduser friendpass 0 0 0 0 friend-note

Do not try to paste an oscam.server [reader] block into CCcam.cfg or vice versa — they are not interchangeable syntaxes, and this mix-up is one of the most common broken-config posts you'll see in forums.

Latency, Stability and Failover: How They Behave Under Real Load

Most "CCcam is unstable" complaints aren't actually about CCcam as a protocol — they're about hop depth. A card at hop 3 means your ECM request depends on three separate boxes being online, responsive, and not overloaded, all at the same time. That's not a protocol defect, that's math. Chain enough hops and something in the chain will eventually be slow or down.

Newcamd, by contrast, fails loudly. One card, one link — when it breaks, the reader disconnects and you know immediately. That's genuinely useful for troubleshooting even though it feels worse in the moment.

Where ECM time actually goes

Break it down: network round-trip time between boxes, the physical card's own processing time, and any queueing if the card or CPU is busy handling multiple simultaneous requests. Check your OScam log's ecm time field to see which of these is actually your bottleneck rather than guessing.

Why CCcam's card list can hide a dead card

A CCcam server can keep advertising a card in its list even after the physical card behind it has gone unresponsive upstream. Your client sees the card in its entitlements, tries to use it, and gets nothing back — because the card list itself doesn't carry real-time health data, just an advertisement of what's theoretically available.

Newcamd's fail-fast behavior vs CCcam's silent degradation

This is the core behavioral difference under load. Newcamd tells you fast: reader disconnected, fix it. CCcam can degrade quietly — the reader stays connected, entitlements still show, but individual requests start timing out or coming back empty because a card three hops away is choking.

Building failover: multiple readers, fallback readers and cache

OScam supports fallback readers — configure a primary and a secondary reader for the same CAID, set sane reconnecttimeout values, and let OScam fail over automatically. Combine that with cacheex if you're running a cluster of OScam boxes, since cache exchange shares control words rather than card access and adds resilience on top of whichever protocol you're using underneath.

Zapping speed, freezing and the difference between a slow card and a slow link

If channel changes are slow but ECM times in the log look fine, that's a link problem — RTT, congestion, or a bad reshare hop. If ECM times themselves are consistently high even on a direct connection, that's the card, not the network.

What to measure and where

Don't add readers because "more should be better." Every reader OScam has as a candidate for a given CAID is one more thing it might try during a zap, and in the worst case that increases zap time rather than improving it. Watch the per-reader ECM stats page in the webif and prune readers that consistently underperform instead of stacking more of them.

When to Choose Which: Concrete Scenarios

One card, two receivers in the same house → Newcamd

This is the textbook Newcamd case. Direct, one port, one reader block on each end, fail-fast if something goes wrong. No reason to introduce CCcam's reshare machinery for a setup with zero aggregation need.

Aggregating multiple CAIDs from several sources → CCcam

If you're pulling cards from three different physical sources and want a single client connection to see all of them, CCcam's card-list model is the right tool. Trying to do this with Newcamd means managing a separate reader block and port for every single card, which doesn't scale past a handful.

Feeding a friend's box a single service → Newcamd (least exposure)

When you're sharing exactly one card to exactly one other person, Newcamd exposes the minimum surface — one port, one CAID, no reshare path for them to accidentally (or deliberately) pass your card further downstream.

Legacy client that only speaks CCcam → CCcam or a protocol bridge

Some old set-top boxes only ever got a CCcam client built for them and never got a Newcamd option. If you're stuck serving one of those, run a CCcam listener on your OScam box specifically for that client, even if everything else you run is Newcamd.

Running both simultaneously on one OScam instance

This is worth repeating because almost nobody mentions it: OScam can run a [newcamd] listener and a [cccam] listener at the same time, on different ports, serving the same underlying readers to different clients. You don't have to pick one protocol for your whole setup — pick per client based on what that client needs.

Choosing a provider link: what to evaluate technically, not who to buy from

If you're evaluating a link from an outside source, judge it on technical merit, not marketing. Does it publish a real hop value rather than hiding it? Does it permit or forbid reshare, and is that stated up front? Will they give you a test line so you can measure ECM times yourself before committing? Does the CAID and provider set actually match your card and region? Is there any transparency around uptime, and do they support configuring a fallback line alongside the primary? Any link you can't verify in your own OScam log — actual ecm time, actual entitlements, actual CW returns — is a link you're taking entirely on faith.

What Doesn't Work: Common Myths and Broken Advice

'Newcamd is encrypted so it's safe' — DES here is obfuscation, not security

Newcamd's DES session key is a 1990s-era mechanism for obscuring the ECM/CW exchange between two trusted endpoints. It was never designed to withstand a determined attacker, and treating it as a security boundary is a mistake. If you actually care about someone observing or tampering with that link, put it inside a WireGuard or OpenVPN tunnel, or wrap it with stunnel, and firewall the raw port so it isn't reachable from the open internet at all.

'Higher cccversion means faster' — it doesn't

cccversion is a compatibility string that tells the peer what protocol dialect you're speaking. It has zero effect on ECM latency. Setting it higher doesn't unlock some faster mode — it can actually break a handshake with an older peer that doesn't recognize that version string.

'Just raise cccmaxhops to get more cards' — you get more failures

Raising cccmaxhops doesn't make your existing cards better, it just admits deeper, slower, less reliable cards into your candidate list. A longer card list built this way is not a healthier one — it's more surface area for dead-card entries and freezing.

Copy-pasting a config from a forum with the wrong group numbers

Group numbers aren't arbitrary labels, they're the routing mechanism between readers and accounts. A forum config written for someone else's group scheme, pasted in verbatim, is one of the most reliable ways to end up with a CONNECTED reader that never actually decodes anything.

Using a public/default DES key

If your Newcamd key is one that's been posted publicly or shipped as a default in some firmware image, you don't have a private link — you have an open door with a lock everyone has the key to.

Expecting CCcam.cfg syntax to work inside oscam.server

C: and F: lines belong to native CCcam's own config format. oscam.server uses bracketed [reader] blocks with key = value pairs. Mixing the two is a guaranteed parse failure or, worse, a config that half-loads and silently ignores the parts it doesn't understand.

Edge Cases Worth Knowing

A few situations come up often enough to call out directly. If your client and server are both behind CGNAT or double NAT, the sharing port simply isn't reachable inbound — port forwarding won't help because there's no public IP to forward on your side. The fix is either arranging port forwarding on whichever end actually has a routable IP, or building an outbound-only design with a VPN tunnel between the two boxes so neither side needs an open inbound port.

If a card's CAID shows up across multiple providers and OScam keeps picking the wrong reader for a channel, don't add more readers — add caid and ident filtering directly in the reader block so OScam only considers that reader for the exact provider ID you want.

Old CCcam clients on ancient set-top boxes sometimes only speak a legacy cccversion and will refuse a handshake with a modern OScam server entirely — this is a compatibility floor, not a config error, and the fix is usually a dedicated lower-version listener for that one client.

If your firewall only allows a single outbound or inbound port and you've got more physical cards than that policy allows ports for, that alone can force a CCcam design purely for network-policy reasons, since one CCcam port can carry many cards where Newcamd would need one port each.

A reader showing CONNECTED with entitlements listed but returning no CW is almost always a card-side problem — unpaired card, wrong provider on that card, or the card itself is dead. That's not a protocol bug in either direction.

Dynamic IP on the server side combined with clients configured by raw IP instead of hostname is a classic silent-failure generator — every ISP re-lease breaks every client until someone notices and updates the IP, or better, switches to a hostname with dynamic DNS.

Also check that OScam is running as a user with actual write access to its config directory — if it isn't, webif changes will appear to save successfully and then vanish on the next restart, which is maddening to debug if you don't know to check permissions first. And if you're running two OScam instances on one host, make sure they're not both trying to bind the same listening port or grab the same physical card reader device node — only one process can hold either at a time.

Clock skew on an embedded receiver can quietly break timeout logic and produce phantom disconnects that look like a network problem but are actually a wrong system clock. And on IPv6-only or IPv6-preferred networks, check that your sharing daemon is actually bound to the interface your clients are using — plenty of older OScam builds default to IPv4 only and will silently refuse IPv6-only connections.

Whatever your topology looks like, the underlying question of newcamd protocol vs cccam protocol: which is better in 2026 comes down to matching the protocol's actual design to your card count and hop tolerance — not picking whichever one a forum post called "easier."