CCcam Reshare Setup: Config Guide & Troubleshooting

If you’re diving into the world of satellite card sharing, you’ve likely encountered the need for CCcam reshare configuration. This involves taking cards received from a peer and passing them along to your own clients or even sharing them back to other peers. But it’s not always straightforward. Misconfigurations can lead to cards not appearing, showing incorrect hop levels, or being outright rejected by your upstream provider. Let’s break down the essentials of CCcam reshare configuration to get you on the right track.

What CCcam Reshare Actually Does (Hops and the F-line)

CCcam reshare means taking the cards that your server receives through a peer connection (using a C-line) and resharing that information to your local clients (via F-lines) or to another peer. The concept of hops is crucial here. Each server in the chain adds +1 to the hop value. So, if a card arrives at hop 2 from your peer, it becomes hop 3 when it reaches your clients. The reshare process is dictated not only by your CCcam configuration but also by the F-line settings of your upstream peer.

Reshare vs. direct share: the hop concept

Direct sharing means you’re providing cards directly to clients without any intermediary servers. In contrast, reshare involves sharing cards that you received from another peer. The key difference lies in the hop count. A card shared directly is still at hop 1, while reshared cards get incremented based on how many servers they’ve passed through.

How the uphops/downhops fields work

In your F-line configuration, the uphops field dictates how many hops away your clients can receive that card. Conversely, the downhops field determines how many hops away cards from that client can be accepted upstream. Understanding these values is vital to managing your network effectively.

Why 0 means 'do not reshare'

Setting downhops to 0 effectively means you’re blocking any cards from that client from being reshared further. This is particularly useful if you want to maintain control and prevent potential loops in your sharing network.

Configuring Reshare in CCcam.cfg

The core of CCcam reshare configuration lies in the CCcam.cfg file. The F-line format you need to remember is: F: username password uphops downhops. The uphops value controls how many hops down the line your clients can access the card, while downhops controls what they can send back. Let’s take a look at a few examples.

F-line syntax and the reshare value field

Here’s a basic example of an F-line:

F: user pass 1 1

This means the client can receive cards from one hop away and can reshare cards back to another peer. If you want to allow deeper sharing, you can increase the uphops value accordingly.

Setting uphops and downhops per line

For a more specific configuration, you might use:

F: user2 pass2 2 0

This setting allows the client to receive cards from two hops away but prevents them from resharing any cards they receive back to peers.

Global vs. per-line reshare control

CCcam allows you to set global directives for resharing, which can be overridden by specific F-line settings. For example, if your global setting allows resharing but you set a specific F-line to 0 for downhops, that particular line will not be able to reshare any cards.

Example: resharing a peer's card to local clients

To illustrate, if you have a peer supplying cards at hop 2, your F-line might look like this:

F: peeruser peerpass 2 1

This grants your local clients access to the reshared cards while still allowing for upstream sharing.

Controlling Which Cards Get Reshared

With CCcam, you can control which specific cards are reshared using inline brace syntax on your C-lines. This lets you specify per-card reshare limits and even block certain cards while still using them locally.

Limiting reshare per CAID/provider with the C-line block syntax

The syntax looks something like this:

C: hostname port user pass no { caid:provid:reshare }

This allows you to set specific CAID and provider combinations for resharing. If you set resharing to 0, you can still utilize the card for local viewing without allowing it to be shared further.

Using the { } reshare directive

By leveraging the inline braces, you can limit specific providers or CAIDs without affecting your entire configuration. This is vital for maintaining control over your sharing setup.

Blocking specific cards from being reshared

If you need to block a card from being reshared, simply set its reshare value to 0 within the braces. For instance:

C: hostname port user pass no { 1234:5678:0 }

This configuration allows local viewing of the card while preventing it from being shared further.

Reshare depth limits to protect your upstream

Be cautious not to over-share. If your upstream peer doesn’t allow resharing or limits it to hop 1, ensure your reshare settings reflect that to avoid being cut off from their service.

Network and Port Requirements for Reshare

Understanding the network and port requirements is key to successful CCcam reshare configuration. By default, CCcam listens on port 12000, but this can be changed using the SERVER LISTEN PORT directive.

Listen port and the SERVER LISTEN PORT directive

To change the port, simply add the following line to your CCcam.cfg:

SERVER LISTEN PORT 12345

Make sure to set your routers and firewalls accordingly to allow traffic through this port.

Port forwarding and NAT for incoming F-line clients

If you want clients to connect to your server for resharing, you’ll need to forward the TCP port through your NAT/router to your box's LAN IP. This is crucial for ensuring clients can reach your CCcam server.

Firewall rules and dynamic DNS for changing IPs

If you’re using a dynamic IP address, consider setting up Dynamic DNS (DDNS) to keep your clients connected. This way, even if your IP changes, your clients can still find your server without needing to update their configurations manually.

Troubleshooting: Reshared Cards Not Showing

When things go wrong, troubleshooting is essential. Here’s a step-by-step process to diagnose issues with reshared cards.

Reading CCcam logs and the Entitlements / share list

Start by checking the web info page, typically at http://box-ip:16001, to confirm whether the card is being received. This page will also show you the hop levels and any potential issues.

Hop level too high — card silently dropped

If the hop level of a card exceeds what your clients are permitted, the card will be silently dropped. Check your F-line settings and ensure they align with what your clients are allowed to receive.

Peer's F-line toward you set to no-reshare

Often, cards won’t be reshared because the upstream peer’s F-line does not permit reshare. It’s critical to verify this with your peer to ensure you have the right permissions.

Local cards vs. reshared cards confusion

Sometimes users confuse locally received cards with reshared ones. Ensure you’re looking at the correct list when troubleshooting.

Cache/EMM vs. ECM share issues

If a card shows up but channels still freeze, you’re likely facing an ECM timing issue rather than a reshare configuration error. This is where understanding your network’s response time is crucial.

Choosing a Reliable Upstream Peer (Generic Criteria)

When selecting an upstream peer for your CCcam reshare configuration, there are several factors to consider. Always prioritize quality over quantity.

Stability and uptime indicators to evaluate

You want a peer with a solid track record of uptime. Downtime can severely impact your service and client satisfaction.

Reshare permissions and hop policy to ask about

Always inquire whether your peer permits resharing and, if so, what their hop policy is. This can save you a ton of headaches down the line.

Local vs. reshared card quality

Prefer peers that offer local cards over those that rely heavily on reshared cards. Local cards tend to be more stable and reliable.