Opened 10 years ago
Closed 9 years ago
#3569 closed defect (expired)
SmargoV2 reader is not working with CAID 0604 using smartreader protocol
Reported by: | MISC | Owned by: | |
---|---|---|---|
Priority: | major | Component: | Reader |
Severity: | high | Keywords: | SmargoV2, smartreader, 0604, Ziggo |
Cc: | Sensitive: | no |
Description
Revision
9170
Issue Description
SmargoV2 hardware in combination with CIAD 0604 Ziggo NL using smartreader protocol returns “card system not supported” .
When the issue occurs
Initialisation fails
How the issue is reproducable
Just initialise with the mentioned hardware and it will result in:
2013/12/24 21:02:12 10D4A8 r Ziggo [smartreader] IO: SR: Transmit:
2013/12/24 21:02:12 10D4A8 01 02 09 03 00 40 XX XX XX XX XX XX XX XX XX XX
2013/12/24 21:02:12 10D4A8 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
2013/12/24 21:02:12 10D4A8 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
2013/12/24 21:02:12 10D4A8 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
2013/12/24 21:02:12 10D4A8 XX XX XX XX XX XX 14
2013/12/24 21:02:12 10D4A8 r Ziggo [smartreader] IFD: Transmit succesful
…..
2013/12/24 21:02:17 10D4A8 r Ziggo [smartreader] IO: SR: Receive:
2013/12/24 21:02:17 10D4A8 01 02 00 00 09
2013/12/24 21:02:17 10D4A8 r ERROR, function call reader->crdr.receive(reader, data, size, delay, timeout) returns error.
2013/12/24 21:02:17 10D4A8 r Ziggo [smartreader] TRACE: ERROR: Protocol_T14_Command returns error
2013/12/24 21:02:17 10D4A8 r Ziggo [smartreader] failed history check
2013/12/24 21:02:17 10D4A8 r Ziggo [smartreader] card system not supported
Quick and dirty containment
Attach to this ticket you’ll find a .diff file which can be used to patch the reader-irdeto.c source file. It will simply ignore the return code of the camkey exchange command, which is triggering the fatal init error for this hardware/protocol combination. For some reason only 5 (sometimes 4) bytes are returned (in time?) and default reader_chk_cmd macro triggers the error due to this.
As I have no idea why it works (from a hardware point of view) and due to lack of regression test options I’ve decided to make the change as local as possible (for easy removal), explicitly checking for the mentioned configuration in combination with the smartreader protocol. A quick and dirty hack/containment, but as many people (at different forums) are trying to make this setup to work, I just thought it would be best if a containment is out there. Off course now it’s up to you guys, if you’re willing to integrate this containment. (especially when you continue reading… ;-))
One more problem with this containment… The init is not 100% stable. :-s It is still likely to fail every 1 out of 15 init attempts. If cardinit fails and/or no entitlements are found, just restart oscam for another try. As soon as it’s initialised properly, it will run flawless. (Yes, I did quite some extensive testing.)
So please integrate this change, as it will likely make some people happy while the investigation for the root cause can/will continue.
Also please notice that this change is not provided as is. If someone understands the root cause (and/or is willing to dive into it) and wants to make some code changes for me to test, please let me know. I’d say it’s a timing issue, but then I cannot explain why it works perfectly after initialisation. Just keep in mind that my spare time is limited (especially for the next couple of weeks), so I might not be able to respond quickly.
Attachments (2)
Change History (18)
by , 10 years ago
Attachment: | 0604SmargoV2.diff added |
---|
comment:1 by , 10 years ago
Retested with wipeout time() patch tpreloadedV13fixed. (Builds with and without clockfix defined)
That does not solve this particular init issue.
comment:2 by , 10 years ago
for test try current 9209
With
autospeed = 0
cardmhz = 369
mhz = 600
or just
autospeed = 1
and omit cradmhz and mhz.
extra log outputs are inserted to be able to trace a potential error.
comment:5 by , 10 years ago
Now You should really try svn9227
Just omit all cardmhz, mhz and autospeed parameters.
(autospeed default is 1 so just omit it in configs)
with a bit luck it should be fine on v2 and triple ass well. (on v1 the card works)
comment:6 by , 10 years ago
svn9335 does contain increased time out patch which may solve this issue.
comment:8 by , 10 years ago
svn 9347 does has this hack into trunk.
The ziggo card should now work on v2 and triple.
comment:9 by , 10 years ago
@stefansat: you should add a logmessage in -d0 that this dirty hack is in use. Thanks in advance.
comment:10 by , 10 years ago
Next time I need to try a patch somewhere I will add a rdr_log if that hack is in use. But need to whatch out that it's only showing up once . As if I add it by patch self it will fill up logs endlessely.
At this time it will only be used if caid is 0604,you are using smartreader protocol and the smartreader is v2 or triple.
comment:11 by , 10 years ago
@Bit
I did an update but did not add an extra rdr_log cause I personally can't test this card. And there is a risk it will be displayed to much. Since this work-around is really temporary up to we find the real cause and solution. It will be removed. The sooner the better. In the source I added comments to draw the attention about this work-around.
by , 10 years ago
Attachment: | smartreaderT14Try1.zip added |
---|
smartreader patch on svn9446 may solve irdeto t14 problem on v2 and triple
comment:12 by , 10 years ago
Stefansat,
Tried your patch on svn9446, but it's not working.
As the hack is removed using /*...*/, camkey for type 0 is used again (as expected), but still only 5 bytes are received.
ps: Lost my password for my MISC account... had to create a new one.
comment:15 by , 10 years ago
Then It's quit possible that there is no reader problem . But card support problem.
Perhaps a combination of both . that's the question.
comment:16 by , 9 years ago
Resolution: | → expired |
---|---|
Status: | new → closed |
reader-irdeto.c patch file