Cache-EX Loopback

[turbopower]

There is new released patch for cacheex in oscam. Most of the peoples report that the improved appear after this patch

http://www.streamboard.tv/oscam/atta...nlder_11.patch

Hi people, here the patch i promise to you.

V11 changes:
- change thread handling, now use default oscam
- remove lock on ecm_request, so no more warnings about writelock/readlock
- fix group stuff, now ecm will get group of only correct (found cw) answering readers/cacheex-clients
- now "pending handling" is based on ecm answer and not more on ecm request. (each ecm has its life indipendently from others!)

Now! mode-1 re-request possible!
If you want test cacheex mode 1 readers now and cacheex 1 clients, i advise to start oscam with "-p 255", to avoid table overflow in big oscam instances.


Please, test with gdb, valgrind or simple with -a parameter, so we can get crash log if crashes.
@capncook reported me that crashes also happen with svn too, in latest revisions more than before.

Thank a lot @capncook for hard tests.


P.S. I have no practice in webif stuff, so ask someone can add these paramters:
- lb_whitelist_services : reader section, use it for whitelist reader in LB when it fails.
- fallbacktimeout_percaid : global section.
- fallback_percaid : reader section, use reader as fallback for only caid defined.
fallback_percaid=<CAID>[,<CAID>]... wildcard CAIDs with two-digit CAIDs possible, default none.
If both fallback and fallback_percaid are used, only fallback_percaid is considered. It acts as a filter.

[CapNCooK]

Client

test_c3

X

X

REVERSE CACHE PUSH

0

1178

0

0

19

Reader

test_c3

X

X

REVERSE CACHE PUSH

1178

0

0

0

0

> Client receive 2 hops
> Reader send 3 hops (+1)

I have put drop CSP on and the problem is still the same.

The test user is sending cache to me in a different group and I am sending cache back from the same group. I have add no other groups to the reader and no other cache. It is the same cache I am receiving.

The test user don't received cache because it is the same cache in his group.

Tested Oscam version: 8440,8743,8778

Hmm.

I cannot replicate this loopback problem. I have setup a testoscam, and push to this testoscam.
In testoscam i setup a return-line just like you. Both user/reader have group 1.

None of my received cache in testoscam is returned to its origin! (as it should)

So need more info to replicate this problem. You run plain SVN ?
What protocols ? If CC-Cam, are you sure nodeid is different for each oscam used in the test ?
In the table above, IP's are hidden with 'X'. Are these the same ? (as they should)

[sat4ber]

Hmm.

I cannot replicate this loopback problem. I have setup a testoscam, and push to this testoscam.
In testoscam i setup a return-line just like you. Both user/reader have group 1.

None of my received cache in testoscam is returned to its origin! (as it should)

So need more info to replicate this problem. You run plain SVN ?
What protocols ? If CC-Cam, are you sure nodeid is different for each oscam used in the test ?
In the table above, IP's are hidden with 'X'. Are these the same ? (as they should)

I am use CCcam with a different node id.
The IP's are the same and I am not using a plain SVN.

[Dimmie]

Its a know problem and there is also a ticket for it in oscam timeline. But... they close the ticket again and again instead of solving the problem. So please everybody make a ticket at the oscam streamboard if you want this problem to be solved.

[CapNCooK]

Its a know problem

It is ?

I still cant reproduce.. Did you try ?

If you have a latest SVN, and really experiencing this.. Let me know, i would like to run some tests.

[bunbunsat]

Did the test with svn8905 (IIRC). Put both user and reader in same group. Reader had 1 hop more than user. All cache received was sent back. Send a PM if you would like to test (currently on plain 1.20-unstable_svn build r8917).

[CapNCooK]

Did the test with svn8905 (IIRC). Put both user and reader in same group. Reader had 1 hop more than user. All cache received was sent back. Send a PM if you would like to test (currently on plain 1.20-unstable_svn build r8917).

Do you know which last build processed correctly ?

[bunbunsat]

Do you know which last build processed correctly ?

Can't really say. I've put all my readers and users in seperate groups from the start to avoid this. Only did the test with a peer to verify the loop-back behaviour.

[Dimmie]

Till 8894 it works fine. The problem starts with 8895.

[CapNCooK]

Can't really say. I've put all my readers and users in seperate groups from the start to avoid this. Only did the test with a peer to verify the loop-back behaviour.

Putting all CE users in seperate groups is a very bad idea.. since it destroys deduplication methods, and cache-size will contain many duplicates.

However., according to Dimmie, i will try to replicate with 8894.. (thx)