GBox reshare: setting up reshare on CCcam/OScam

If you are reading this article, it means your basic connection is working, but the GBox reshare setup did not go as expected. Either the peer is not connecting, or the channels are not opening, or everything seems to be online, but the picture freezes every 30 seconds. Let's break it down step by step — with real config lines, specific ports, and step-by-step diagnostics.

What is GBox reshare and when is it needed

GBox is a card sharing protocol that operates over UDP and was originally created specifically for exchange between boxes (peer-to-peer), rather than for the classic client-server scheme. This fundamentally distinguishes it from CCcam and OScam in their standard applications.

The principle of operation of the GBox protocol and the concepts of peer/SID

Each participant in the exchange is a peer. Each peer has a unique HostID (usually generated from the MAC address of the network interface) and a password for mutual authentication. Boxes exchange lists of available SIDs (Service IDs — channel identifiers), and when an ECM request is made, a specific SID is searched for among the peers in the chain.

Local cards are physical smart cards in the card reader of your receiver. Remote cards are what is available from the peer. Reshare means that you are passing on channels that you received from another peer, not just your local ones.

How reshare differs from regular sharing

In regular sharing (without reshare), your box receives the decryption from the source and does not pass it on to anyone else. Reshare adds a level: you become an intermediary and can pass on what you received to other boxes in your local network or trusted peers outside.

This is the key mechanism of GBox reshare. Each "retransmission" adds a hop to the chain, and the level parameter limits how many times the channel can be passed on further. Most guides are silent about this, although it is the level that is the cause of half the problems.

In what scenarios is reshare justified, and in what scenarios is it not

Reshare is needed when you have multiple receivers in a local network and you want all of them to use one subscription. Or when you are exchanging channels with a trusted partner — they have what you don't, and vice versa.

If you have only one receiver and you are simply connecting to an external server via CCcam — you do not need GBox at all. Use a regular CCcam client or reader in OScam. Bringing in GBox for a single connection is unnecessary hassle.

Preparation: ports, firmware, and dependencies

Before writing configs at all, you need to ensure that the network part is set up correctly. GBox works only over UDP, and most problems with connecting peers are resolved at the network level, not in configuration files.

Opening UDP port (default 8888) on the router

The standard GBox port is UDP 8888. It is specified in the config and can be changed, but if you do not know why to change it — leave it at 8888. On the router, you need to create a forwarding rule: incoming UDP traffic on port 8888 should be directed to the local IP of your receiver.

In most home routers, this is done in the "Port Forwarding" or "Virtual Server" section. Specify: protocol UDP, external port 8888, internal IP of the receiver (for example, 192.168.1.100), internal port 8888. Save and reboot the router.

Port forwarding and checking availability from the outside

After configuring the router, check that the port is actually open from the outside. For UDP ports, this is more complicated than for TCP — regular online checkers like canyouseeme.org do not always work correctly with UDP. It is better to ask a peer to try to connect and watch the GBox log.

Through telnet on the receiver itself, you can check if the process is listening on the required port:netstat -ulnp | grep 8888. If there is no line — the cardserver is not running or the port in the config is different.

A separate story is a gray IP or double NAT from the provider. If your external IP starts with 10.x.x.x or 100.64.x.x — this is CG-NAT, and incoming UDP packets will not physically reach you. In this case, your box must initiate the connection, not the peer. Or you need to contact the provider for a public IP.

Requirements for firmware and installed cardserver

GBox is not supported by all builds. If you are using OScam — make sure that the build is compiled with the flag--enable-gbox. You can check this with the commandoscam --version and by searching for the string "gbox" in the output. If the module is not present — you need a different OScam build that supports GBox.

For Enigma2 receivers, GBox often comes as a separate emulator (gbx-emulator or built into the oscam-emu package). Make sure that the correct package is installed, and conflicting cardservers (for example, CCcam and OScam running simultaneously without the correct binding) are disabled.

Step-by-step setup of GBox reshare

This is where the reason you came here begins. Gbox reshare: setting up configs — this involves several files with very specific syntax, where one extra space or incorrect HostID breaks everything. Let's break it down line by line.

Structure of the config and file locations

If GBox operates as a standalone cardserver (not through OScam), the main files are usually located in/var/keys/:

• /var/keys/gbox_cfg — main config (IP, port, host password)
• /var/keys/peers.gbox or/var/keys/my_peers — list of peers
• /var/keys/sharing.info — reshare levels and permissions

When working through OScam, GBox module files are read from/etc/oscam/, and parameters are specified inoscam.conf andoscam.server.

Specifying peers and exchange passwords

In classic GBox, a peer file looks like this:

M: { 01020304 }  # your HostID

Where01020304 — is the HostID of your box in hex (8 characters),05060708 — HostID of the peer,password — the shared password that you agree upon with the peer in advance (the same on both sides),192.168.1.200 — IP of the peer,8888 — its UDP port.

Critical point: HostID must match what your box actually generates. GBox takes it from the MAC address of the network interface. If you changed the firmware or the MAC changed — the HostID will change, and the peer will no longer recognize you. You can check the current HostID in the GBox logs at startup — it is written in the first lines.

Reshare level parameters (depth of forwarding)

The level parameter (level or reshare level) defines how many hops are allowed. The logic is as follows:

• 0 — reshare is prohibited. The channel is received only by you, and you do not forward it further.
• 1 — you forward to the peer, but the peer cannot forward further.
• 2 — the peer can forward to the next peer. And so on.

In the filesharing.info or in the peer settings it looks something like this:

P: { 05060708 } { password } { 192.168.1.200 } { 8888 } { 01 }  # the last parameter is the level

Do not set the level higher than 2-3 without understanding the consequences. A high level leads to requests traveling through a long chain of peers, ECM time increases, and freezes begin. There is also the possibility of looping: box A resharing to box B, B resharing back to A, and they start cycling the same SIDs. GBox detects this through HostID in the chain, but not always reliably — it's better to control the levels manually.

Binding local cards to GBox

If you have a local card and want to reshare it through GBox, make sure that the config specifies permissions for exporting specific CAIDs. In GBox, this is controlled through the available CAID parameters in the config file or throughsharing.info.

When using OScam through the section[gbox] the card must be available to the GBox module as a reader. Inoscam.server add a reader with the corresponding CAID and group that GBox reads.

Configuring GBox through OScam: section [gbox]

This is a section that most guides skip. Which is a pity — many now use OScam as the main cardserver, and GBox as a module within it.

In/etc/oscam/oscam.conf add the section:

[gbox]

The parameterreshare = 1 here means the reshare level.nodelay disables the Nagle algorithm for the UDP socket — I recommend enabling it, it reduces ECM delay.

In/etc/oscam/oscam.server add a reader for each peer:

[reader]

Herecaid — is the list of CAIDs that you expect to receive from this peer. If left empty — OScam will try all. It's better to specify explicitly — this speeds up the routing of ECM requests.

Checking operation and reading logs

After starting, do not expect a miracle — go straight to the logs. A good GBox reshare setup is visible in the logs within 10-15 seconds after startup.

Where to look for the GBox log and peer status (online/offline)

For classic GBox, the log is written to/tmp/gbox.log or/var/log/gbox.log — it depends on the build. Check it with the commandtail -f /tmp/gbox.log.

Upon successful connection of the peer, you will see a line like this:

peer 05060708 connected from 192.168.1.200:8888

If the peer does not connect, there will either be silence or a linepeer timeout orauthentication failed. The first indicates a network problem (port closed, incorrect IP). The second indicates an incorrect password or HostID mismatch.

Connection and ECM time check commands

In OScam, ECM time is visible in the web interface (default port 8888 or 83 — depends on theoscam.conf section[webif]). Normal ECM time for reshare is up to 800 ms. Anything above 1500 ms indicates a problem, there will be freezes.

Through telnet to OScam (telnet localhost 8789, if[monitor] is enabled) you can view the status of readers in real time. The commands shows statistics,r — list of readers.

OScam web interface for reshare control

In the OScam web interface, the "Readers" section shows each GBox peer as a separate reader: status (connected/disconnected), number of ECM requests, average response time. If the reader is in "connected" status but ECM requests are not coming — it means either the peer does not have the appropriate CAID/SID, or OScam routing is not directing requests to this reader.

The "Clients" section shows who is connected to your OScam. If you are resharing to another box — it should appear here as a client.

Typical GBox reshare configuration errors and their solutions

Here is a specific breakdown of what is going wrong and why.

Peer does not connect (offline) — reasons

The most common reason is a closed port. Checknetstat -ulnp | grep 8888 on both boxes. If the port is listening but the peer is still offline — check the firewall:iptables -L -n | grep 8888. GBox uses UDP, and iptables may block incoming UDP even with an open port on the router.

The second reason is an incorrect HostID. It must exactly match what your box generates at startup. Look at the beginning of the log for a line likeMy HostID: 01020304. This ID must be registered with the peer.

The third reason is a gray IP / CG-NAT. If you do not have a public IP, incoming UDP will not arrive. Either use a VPN with a public IP or agree with the peer on a different scheme.

Channels do not open with an online peer

The peer is online, the handshake has passed, but specific channels do not open — this is already a routing problem. Check:

• Is the CAID of the required channel specified in the reader settings of the peer?
• Does the peer really have this card/subscription?
• Is the reshare level exhausted? (The channel came to the peer with level=1, and you are asking it to forward — but the level is already 0)
• Is the channel SID not in the blocklist?

In the OScam log, there will be a line likeno card found for CAID 0500 / provider 000000. If such a line is completely absent — OScam doesn't even try to send a request to this reader, meaning the problem is in the routing config (groups, CAID in the reader).

Freezes, long ECM time, and loss of synchronization

Freezes during active reshare — almost always high ECM time or loss of UDP packets. GBox does not have a built-in retransmission mechanism like TCP, so a lost UDP packet = missed ECM = frozen picture for 3-5 seconds.

A typical cause of losses is MTU. If your internet is through a mobile provider or VPN, MTU may be lowered (1280-1400 bytes instead of the standard 1500). GBox UDP packets are fragmented, some are lost. Try explicitly setting MTU:ip link set eth0 mtu 1400 and see if the situation changes.

A long chain of peers (3+ hops) also kills ECM time. Each hop adds 50-200 ms. With four hops, you easily get 800 ms just for delivering the request, plus the time to decrypt the card.

Conflict of reshare levels and looping

Looping looks like this: both boxes see each other online, channels seem to exist, but ECM time is huge and channels do not open consistently. In the log, you can notice that the same SID is requested multiple times in a short period.

This happens when box A reshapes channels to box B, and B has set reshare back to A. A sends ECM, B tries to respond through A — a loop. Solution: one of the boxes must have level=0 for the direction towards the other. Or use different CAIDs in each direction.

How to choose a source/peer for reshare (without risks)

The technical part is set up. Now about who and how to exchange with.

Criteria for a stable peer: uptime, ping, ECM time

A good peer for GBox reshare should have an uptime above 95% over the last 30 days, ping to it no higher than 50-80 ms (critical for UDP), and ECM time within 400-700 ms. If a peer gives ECM time above 1000 ms — there will be freezes regardless of the quality of your setup.

Check the ping to the peer:ping -c 20 ip_peer. Look not only at the average value but also at the jitter (variance). Jitter above 30-40 ms for UDP — this indicates future freezes.

Signs of an overloaded or unreliable source

An overloaded peer usually manifests as high and unstable ECM time — it jumps from 300 ms to 2000 ms. This means that there are too many clients on the server relative to the number of cards. Another sign is frequent connection drops (the peer goes offline 2-3 times an hour).

If the peer limits the number of simultaneous connections — this is a good sign. It indicates that the owner is controlling the load. A peer without connection limits is most often overloaded.

Legal and technical disclaimers

GBox reshare is a technology that is neutral in itself. It can be used legally for transmitting channels between your own receivers under one subscription for one household — if it is not prohibited by your operator's terms. Transmitting the signal to third parties beyond one connection point in most countries violates the terms of subscription use and may be illegal. Act only with those subscriptions for which you have rights.