Opened 11 years ago
Closed 9 years ago
#3338 closed enhancement (expired)
ONID on oscam and cacheex to others or csp
Reported by: | drmacsoft | Owned by: | bowman |
---|---|---|---|
Priority: | minor | Component: | Cache-EX |
Severity: | low | Keywords: | |
Cc: | Sensitive: | no |
Description
Revision
8666 8667
Issue Description
General Oscam correct me if i am wrong dont use Network Id (ONID) on readers
When the issue occurs
exist on any version
How the issue is reproducable
Add option to readers to set ONID
According the new oportunity to get csp cache and push cache back to it, oscam cache goes but csp only get the caid and not right ONID, it gets ffff as ONID and that csp drop it because in csp profile is set caid/onid/provid.
I suggest if possible to add more options to set cache or seperate csp handling and configure what caid/onid/provid is on air.
regards
Change History (6)
comment:1 by , 11 years ago
Owner: | set to |
---|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
Priority: | critical → minor |
---|---|
Severity: | medium → low |
Type: | defect → enhancement |
comment:4 by , 11 years ago
if it is not dropped the onid ffff how can be merged with existing right onid because if set a profile with same as the other caid and different onid , one right and other ffff the csp respond with flag RME.
comment:5 by , 11 years ago
RME indicates that it is a successful cache hit, but the response is being blocked by the somewhat misleading sanity check "block-caid-mismatch" (yes even though caid is correct). Set this to false to disable (check proxy-reference for the correct place).
In the future, more ecm sources in oscam (besides dvbapi) could perhaps be extended to include the right onid.
Besides this issue, for oscams to work like full csp clusteredcache peers, they would have to send pending request indications for every new ecm that they start to process (before cw is obtained). This is currently not done (and may not be feasible at all, I haven't looked at it yet).
comment:6 by , 9 years ago
Resolution: | → expired |
---|---|
Status: | new → closed |
This is a fairly complex issue, but I'll at least say this:
Csp does not drop any incoming cache traffic as long as onid and caid is nonzero, regardless of what profiles exist (meaning it will never drop onid ffff, unless it has been modified to do so). This meta-data in cache updates does not affect cache hits in any way, it is there to make troubleshooting possible (and in certain very specific case allow some partial filtering).
Allowing users to configure the onid to be placed in cache updates could perhaps be somewhat useful in that it allows the recipient to see what the sender *thinks* the traffic is, but the only way it would indicate what it actually was is if it came from the transport stream itself (which only happens for local oscam-dvbapi clients atm).