CCcam.cfg Line Format: C-Line, D-Line & F-Line Explained

If you've got a CCcam.cfg file open right now and you're staring at a line someone handed you on a forum, trying to figure out which chunk is the password and which chunk is a flag — this is for you. This breakdown of the cccam.cfg line format: c-line d-line f-line explained covers every field, in order, with the failure modes that actually happen when one of them is wrong.

I've spent a lot of time in these config files, mostly at 1am trying to figure out why a "connected" peer was serving zero cards. So this isn't theory. It's the stuff that actually trips people up, field by field.

How CCcam.cfg Is Parsed: Line Types, Order, and Syntax Rules

CCcam.cfg is a flat text file. No sections, no nesting, no JSON-style brackets except for the sharelimit blocks we'll get to. Every line starts with a letter and a colon, and that letter tells the parser what role the line plays: C for an outbound client connection, F for an inbound account you're offering to someone else, N for newcamd, D for a legacy line type you almost never need, and a handful of global options that have no letter prefix at all, written as KEY : value.On most Enigma2 boxes the file lives at /var/etc/CCcam.cfg. On generic Linux builds it's often just /etc/CCcam.cfg. Check both before you assume the box isn't reading your edits — I've lost time editing the wrong copy more than once.

Here's the part almost nobody tells you plainly: CCcam reads this file exactly once, at startup. There's no reload signal, no SIGHUP handling, nothing. If you edit the file while CCcam is running, nothing happens until you kill and restart the process. The standard pattern is:

killall -9 CCcam && CCcam -C /var/etc/CCcam.cfg

On most images there's a softcam start/stop script that wraps this for you — use it if it exists, but know what it's doing underneath.

The line-type prefix system and why the colon matters

The letter-colon prefix isn't decorative. C:, F:, N:, D:, L:, M: — each maps to a specific parser branch. If you type C without the colon, or the colon gets mangled somehow, the parser doesn't throw an error. It just doesn't recognize the line as anything, and moves on. This is, genuinely, the single biggest cause of "I added the line and nothing happened" reports. There's no log message, no warning. The line is just invisible to CCcam.Comments start with # and the parser tolerates them fine, along with leading whitespace and tabs between fields — CCcam splits fields on whitespace generically, so extra spaces between fields don't usually break anything. What does break things is whitespace inside a field, which brings me to the next problem.

Whitespace, invisible characters, and the copy-paste trap

If you copied a line off a web page or out of a PDF, there's a real chance it's carrying garbage characters you can't see. Non-breaking spaces (U+00A0) look identical to a normal space in most text editors but the parser won't treat them as a field separator, and if one lands inside your password field, auth just fails — silently, with no useful error. Same story with CRLF line endings from a file someone edited on Windows: the trailing \r gets treated as part of whatever field precedes it, usually the password.The fix is to actually look at the raw bytes:

cat -A /var/etc/CCcam.cfg | head

CRLF endings show up as ^M at the end of each line. Non-breaking spaces and smart quotes from a web page typically show as M-BM- sequences. If you see either, run dos2unix on the file, or just retype the affected line by hand instead of trusting the paste.

Case sensitivity and why CCcam is a dead end long-term

Usernames and passwords are case sensitive, always. There's no quoting mechanism in the file format, so a username or password with a space in it is simply not possible — the parser will split it into two fields and everything after breaks.One more thing worth saying up front: CCcam is unmaintained. The last builds anyone actually uses are the 2.3.x line, and there hasn't been meaningful development on it in years. OScam is the actively maintained path, supports the CCcam protocol on both the client and server side, and gives you real logging instead of CCcam's near-silent failures. Treat this article as reference for configs you already have running, or lines someone's handed you to read — not a recommendation to build something new on CCcam in 2026.

The C-Line: Connecting Your Box to a Remote Server

This is probably why you're here, so let's get into it properly. The canonical C-line looks like this:

C: server.example.net 12000 myusername mypassword

Four mandatory fields, space separated, in this exact order.

Field-by-field breakdown

Host — an FQDN or a bare IPv4 address. This is the first place people get burned, and I'll explain why in a second.

Port — an arbitrary TCP port chosen by whoever runs the server. There's no reserved CCcam port. You'll see 12000-13000 used a lot by convention, but that's just habit, not a standard. Use whatever the server operator tells you.

Username and password — case sensitive, plain text, no quoting. A trailing space on either field, which happens constantly when people paste from a webpage, breaks authentication and gives you no useful indication why.

Optional field 5 and 6: the EMU flags

Beyond the four mandatory fields, some builds accept a fifth field controlling EMU/wantemus behavior, and a sixth for a related flag. I'll be straight with you here: the exact semantics of these fields drifted between 2.1.x, 2.2.x, and 2.3.x builds, and I've seen conflicting behavior reported across images. Unless the server operator explicitly tells you to set one, the safest move is to omit them entirely and let the defaults apply. Guessing at these fields causes more problems than it solves.

The sharelimit block

You'll often see a C-line with a curly-brace block tacked onto the end:

C: server.example.net 12000 myusername mypassword { 0100:000068:2, 0500:032830:1 }

Each entry is CAID:ident:sharelimit. The number on the end is the maximum hop depth you're willing to accept for cards matching that CAID/ident pair. A value of 0 means "local cards on that server only, don't relay anything they got from someone else." This matters a lot for line quality — I'll come back to hop depth later, but the short version is that a hop-1 card is fundamentally more reliable than a hop-4 card, and this block is how you enforce that ceiling on your end.

Hostname vs IP, and the DDNS trap nobody mentions

Here's the thing that catches people out constantly and that almost no other page on this topic covers properly: CCcam resolves the hostname in a C-line exactly once, at startup. If your peer's server sits behind a dynamic DNS hostname and their IP changes after your CCcam process has already started, your connection will keep failing — indefinitely — until you restart CCcam. It won't re-resolve on its own, ever, no matter how long you wait. If a previously-working C-line suddenly stops connecting and you've verified the credentials are fine, this is worth checking before anything else. Just restart CCcam and see if it picks up the new IP.

Verifying a C-line actually works

Don't just paste a line and hope. Work through it in layers:

First, check the port is reachable at all, from the box itself — not from your laptop on a different network, since carrier-grade NAT and ISP-level blocks can make a port look open from one network and closed from another:

nc -vz server.example.net 12000

If that connects, open the CCcam web interface, which by default runs on port 16001 (configurable via the WEBINFO LISTEN PORT directive) — http://<box-ip>:16001. It'll show whether the peer is Connected, and critically, how many cards it's actually sending you. "Connected" and "sending cards" are two completely different states, and mixing them up wastes a lot of debugging time.

In the logs, you'll see a few distinct messages that each mean something different: "connect failed" is a network/firewall problem, not a credentials problem. "Connection closed by server" almost always means the server rejected your auth or the account's disabled. And "no cards" means auth succeeded fine but the server sent back an empty share list — which is a completely different problem, covered in the debugging section below.

One thing worth being explicit about: a C-line is outbound only. It doesn't open a listening port on your box, so it needs no port forward, no NAT rule, nothing on your router. If you're not receiving cards, the problem is never "I forgot to forward a port for my C-line" — that's an F-line concern.

Multiple C-lines and priority

You can have as many C-lines as you want in one config. CCcam will attempt to connect to all of them and pull cards from whichever ones respond, merging the share pools. There's no strict priority field — it's not "try this one first, fall back to the second." If two C-lines both offer the same CAID/ident, CCcam picks based on internal routing logic (generally favoring lower hop count and better ECM response time), not line order in the file.

The F-Line: Serving Cards to Other People From Your Box

If the C-line is you consuming someone else's cards, the F-line is the reverse: it's an account on your box that lets someone else's C-line connect in and pull cards from you. Canonical form:

F: peeruser peerpass 1 0

Field-by-field, and the two numbers everyone gets backwards

Fields 1 and 2 are the username and password this peer will use in their own C-line to reach you. Fields 3 and 4 are where people consistently mess up, so let's be very direct about it:

Field 3 — uphops. This governs what you give. It's how deep into your own card tree this peer is allowed to reach. 0 means they only see cards local to your box. 1 means they also see cards you're pulling in from one hop away — i.e., cards from your own C-line connections. 2 and higher cascades further, and this is exactly where sharing trees turn into loops if two peers are also each other's upstream source.

Field 4 — downhops. This governs what you take. It's how many hops of the peer's own cards you're willing to accept back from them.

Say it plainly: uphops is what you give, downhops is what you take. The classic beginner mistake is setting uphops to 5 "to be generous" toward a new peer. That doesn't make you generous, it floods the entire downstream sharing tree with cards several hops removed from their origin, and it's the kind of thing that gets a peer quietly banned by everyone else on the network for degrading share quality.

Per-peer share filtering

Same curly-brace syntax as the C-line, but here it restricts what that specific peer is allowed to receive:

F: peeruser peerpass 1 0 { 0100:000068, 0500:032830 }

There's no explicit "deny" syntax in CCcam.cfg — the model is allow-by-listing. If a CAID/ident isn't in the block, that peer doesn't get it. Omit the block entirely and they get everything your uphops setting permits.

F-lines need a listening port — this is where people get stuck

An F-line does nothing on its own if your box isn't actually accepting inbound connections. You need the global directive present in the same config:

SERVER LISTEN PORT : 12000

And that port needs to actually be open — forwarded through your router's NAT table if you're behind one, and not blocked by any firewall rule on the box itself. Your peer also needs a way to reach you: a static IP, or a DDNS hostname that they put into their own C-line. If either side of this pair is sitting behind carrier-grade NAT — increasingly common on mobile connections and some fibre ISPs — the peer's F-line is unreachable no matter what you do on the router, because there's no public IP to forward a port on in the first place.

One F-line per peer, or you'll get a disconnect loop

Don't hand the same F-line credentials to two different people. CCcam allows one active session per username by default, so if two devices try to use the same account simultaneously, each new connection kicks the previous one off. The result looks like a flaky, constantly-dropping line, when the actual cause is two people fighting over one login. It's a genuinely common failure mode and it's easy to miss because both people will swear their own setup is fine — and individually, it is.

The ALLOW TIMEOUT and ALLOW CONNECT global options can further gate when F-lines are accepted (time-of-day restrictions, connection retry limits), and the exact behavior around MAXCONNECTIONS varies a bit by build, so check what your specific version supports before assuming a setting works.

The D-Line and N-Line: DVN, Newcamd, and the Lines People Confuse

I want to be honest with you about the D-line, because most pages covering this topic just make up field definitions to fill space, and I'm not going to do that.

What a D-line actually is

In the CCcam ecosystem, the D-line was a legacy DVN-protocol client line. It's effectively obsolete. On the 2.3.x builds that make up basically everything still running today, you will almost never write one, and modern CCcam doesn't meaningfully use it. If someone hands you something they're calling a "D-line," it's most likely one of two things: a mislabeled C-line, or a line intended for an entirely different softcam application that happens to reuse the letter D for something unrelated. I'm not going to invent field-by-field semantics for a line type that isn't in active use — if you genuinely need to work with one, verify against the specific softcam and build actually parsing your file, because guessing here will waste your time.

The N-line: what you actually need for newcamd servers

This one's real, current, and worth knowing properly, because it's the line you need when the server on the other end speaks newcamd instead of the CCcam protocol. Full form:

N: server.example.net 34000 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Host, port, username, password — same idea as a C-line so far. Then a trailing run of fourteen hex byte pairs, space separated. That's the DES config key. It has to be exactly fourteen bytes. If it's short — thirteen bytes, or fifteen — CCcam will still accept the line without complaint, but the session will connect and then drop instantly. That looks exactly like an auth rejection in the logs, and it's easy to burn time double-checking a correct username and password when the actual problem is a key with the wrong byte count.Newcamd doesn't have an official port standard either, but 34000-35000 shows up often by convention. And unlike a C-line, which can carry a whole card portfolio through one login, an N-line maps to exactly one card or profile on the server side — that's baked into how newcamd handles reader mapping.

L-line and M-line: old prefixes still floating around

You'll occasionally see L: and M: prefixed lines in older configs pulled from legacy images. These relate to local card reader and multi-CAM handling from earlier CCcam eras. They're rare in anything actively maintained today — if you find one in a config you inherited, it's worth checking whether it's still doing anything on your current build before assuming it matters.

Mapping to OScam, since most people end up here eventually

If you're migrating off CCcam — and you probably should be, at some point — the concepts map over cleanly, just into a different file structure. OScam splits things across /etc/tuxbox/config/oscam.conf, oscam.server, and oscam.user instead of one flat file.

OScam gives you actual structured logging per reader, which — after years of CCcam's near-silent failures — is genuinely a relief the first time you see it.

Debugging a Line That Will Not Connect: A Decision Tree

Work through this in order. Don't skip ahead — each layer rules out a category of problem before you waste time on the next one.

Layer 1: is the port even reachable?

From the box itself, not your laptop:

nc -vz server.example.net 12000

If this fails, stop. The line's contents are irrelevant — you have a network problem, not a config problem. Check firewall rules, port forwards, and whether the server is actually up. tcpdump on the box can confirm whether packets are leaving at all if nc's result seems inconsistent.

Layer 2: does the peer even see your attempt?

If the port's reachable but the connection still fails, ask the peer to check their own log for your connection attempt. If it's not showing up on their end at all, you're likely hitting a different port or IP than you think — double check for typos, and rule out DDNS resolving to a stale IP if your C-line has been running a while (remember, CCcam only resolves at startup).

Layer 3: connected, but zero cards

This is the confusing one, and it's the most common support question I've seen. The web interface shows Connected, but you're getting nothing. In order of likelihood:

The peer's F-line entry for your account has uphops set to 0, and they simply don't have local cards to send you — nothing wrong on your end at all. Or your own C-line has a sharelimit block filtering on a CAID the server doesn't even carry, so everything gets silently rejected by your own filter. Or, less commonly, the server genuinely has nothing matching the CAIDs it's willing to send. Check the sharelimit block on your C-line first — it's the thing you control, and it's an easy typo to make.

Layer 4: cards present, but the channel's still black

Cards are showing in the web interface, the connection is healthy, and you still get a black screen. Compare the CAID and provider ident your receiver reports for that channel against what's actually listed in the web interface's card list. A card for CAID 0500 ident 032830 will never decrypt a channel needing CAID 0100 ident 000068 — the connection being "healthy" tells you nothing about whether it's the right card. This also happens with matching CAID/ident but a different provider subgroup underneath it, which looks identical in the card list but still won't decrypt.

Also worth checking here: ECM response time. If a card's ECM response is sitting above roughly 800ms, you'll see visible freezing on channel changes even though the card is technically working. The web interface shows per-card ECM timing — it's worth glancing at even on a "working" setup.

Reading the actual logs

CCcam writes to stdout by default. Depending on the image, that might be piped to /tmp/CCcam.log, or it might go nowhere at all if the softcam start script doesn't redirect it. If you're stuck, the fastest way to see what's actually happening is to kill the running process and launch it in the foreground over SSH with debug output:

CCcam -d

You'll see the parser's real-time behavior, including lines it's silently skipping — which is often the fastest way to catch a malformed line you'd otherwise never notice.

Choosing a Line Source Without Getting Burned

I'm not going to point you at any specific source here — that's not what this article's for, and frankly, a name I recommend today could be gone next month. What I can give you is what to actually check before trusting a line.

What a legitimate source discloses upfront

A source that's confident in what it's offering will tell you the specific CAID and provider ident list, not just "how many cards." They'll state the hop depth plainly — and if a source won't tell you the hop depth, that's a real signal something's off, because hop depth is the actual thing determining whether the line holds up under real use. They'll usually give you a sense of ECM response time too, and most legitimate setups offer some kind of test window before you commit to anything.

Red flags

"Unlimited" anything. Card counts in the thousands — that's not one server with a huge card inventory, that's a reshare aggregation stacking multiple hops together, which is exactly the kind of setup that falls apart under load. No CAID list at all. And any pressure to pay before you're allowed to test.

Why hop count is the metric that actually matters

Every hop between you and the physical card adds latency and one more point of failure. A card sitting three hops behind two resellers will freeze on fast channel changes no matter how good your own network and box are — there's nothing you can configure locally to fix a problem that's happening three servers upstream. This is why the sharelimit and uphops fields we covered earlier aren't just abstract syntax — they're the actual mechanism for keeping hop depth under control on lines you're consuming or serving.

The legal picture, briefly

Sharing a card you legally own across your own devices, on your own network, is close to the original intent behind card sharing as a technology. Using it to obtain decryption for channels you haven't paid for is unlawful in most jurisdictions, and no amount of correct C-line or F-line syntax changes that. This article documents the protocol — how the fields work, why lines fail, how to debug them — not a way around a subscription you don't have.