IDEA: Fake descramble

[lars18th]

Hi @catalinii ,

I have the idea to make this installation:

• SAT Tuner --> minisatip A --> delayer (2 seconds) --> minisatip B --> SAT>IP Client

And both minisatip servers (A & B) are connected to the same Oscam server.

The objective is that the server A only requests and pass ECM/EMM data, but not decrypt at all. This function will be done in the server B, that receives the stream with a delay of 2 seconds.

What you think about this "crazy" idea?

[catalinii]

I think it could work,but potentially would be much better use of the time by looking into creating this buffering in minisatip. Basically if a packet comes and u do not have keys for all the pids, queue more data and retry later.

[lars18th]

Hi @catalinii ,

Thank you for your response!

So your idea (summarizing it) is:

1. Queue all incoming data (TS packets) to a buffer.
2. For each incoming data, check if it has ECM/EMM data before queue it, and send it to the decrypt module asynchronously.
3. When dequeuing data from the buffer, process all data. And if it's ECM/EMM resend it another time to the decrypt module but in this case synchronous.

The expected behaviour with this algoritm is to lookahead over the ECM/EMM data, with a length size of the buffer size.

Is that your idea?

[catalinii]

Are you talking here about CAM or dvbapi ?

[lars18th]

Are you talking here about CAM or dvbapi ?

In my case, the target is dvbapi.

[catalinii]

Probably the simplest way to achieve this would be to block (with a timeout) when sending a ECM to dvbapi until you get an answer.

Basically you would have to wait for an answer from dvbapi here: https://github.com/catalinii/minisatip/blob/master/src/pmt.c#L839

[lars18th]

Hi @catalinii ,

Basically you would have to wait for an answer from dvbapi here

I feel this is a bad idea. Why? Because you're waiting for... what?

My suggested strategy is different: Inmediatly a packet enters in minisatip, then send it to the dvbapi (when apply). But, the packet is put in a buffer (in fact, the full TS that is readed goes inside this buffer). And only after a some time (1 second, 2 seconds...) the buffer is consumed. Then at this time, the packet is resended to the dvbapi.

What is the advantage?

1. The "waiting" buffer is (relatively) simple to implement. It's only manager by the time.
2. The Oscam server can handle a "cache". Therefore when a command is repeated after some time, it is served from the cache.
3. The code inside minisatip for decoding doesn't need to change at all. Only the first send is new (and only applies to ECM and EMM packets).

What you think?

[lars18th]

Hi @catalinii ,

Any news? At time my decoding has some glitches (time to time) just when a new key comes. So just when the parity key changes, some packets aren't right decoded as the new key not has come.

This the reason to insert a delay in the deconding path.

[catalinii]

I have added some fixes, can you check if now is better ?