r8441 massive EMM erros on viaccess

[Bit]

Revision

beginning with r8441

Issue Description

Many, many EMM errors

When the issue occurs

using built-in dvbapi and a via card

@gfto:
You wrote in the changeset r8441:

The downside is that there would be some EMM writing errors because
the reader would try to write not assembled EMMs instead of waiting
for reassembly.

"SOME" EMM writing errors? I have manymanymany errors.
Are these EMMs going to the card?
Or is it just a cosmetic problem?

If this is now "normal", please close this ticket

PS: I have EMM logs. Please contact me if you need them.

[gf]

It is just a cosmetic error. Similar same thing happened before if you sended EMMs over network protocol. If they bother you can revert the quoted patch, because it helps clients that manipulate EMMs, dvbapi is not such client. Maybe I could think of some check if the client is dvbapi, let me think about it...

[Bit]

OK. I'll leave this ticket open until you tell me to close it.
By the way, I tested AU via network protocol (camd3x) before. There were no errors like this.
But having thousands of EMM errors in the statistics makes me afraid. :)
You say that these EMMs don't hit the card? (I hope so).
Thanks gfto.

[Gorgone Impertinence]

i can confirm that

2013/03/02 12:32:45 8D2158 r sf_easy [viaccess] dvbapi emmtype=shared, len=82, idx=11, cnt=2: written (195 ms) 
2013/03/02 12:32:45 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:45 8D2158 8D 70 22 90 03 04 08 11 91 08 50 0C 9F 29 5F BD 
2013/03/02 12:32:45 8D2158 AE 42 92 08 C4 8E 7F 26 5E 4B 0B 01 81 07 DA E9 
2013/03/02 12:32:45 8D2158 65 E5 5D 3B 89 
2013/03/02 12:32:47 8BFA58 c dvbapi (0500&040810/038B): found (250 ms) by sf_easy (L/1/2/2) - 0500:038B unknown 
2013/03/02 12:32:47 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:47 8D2158 8C 70 22 90 03 04 08 11 91 08 0D EB 1F 36 1C 83 
2013/03/02 12:32:47 8D2158 FB 62 92 08 B7 C8 0F 30 6D 5D 87 22 81 07 9C 62 
2013/03/02 12:32:47 8D2158 22 E0 4A AC B4 
2013/03/02 12:32:49 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:49 8D2158 8D 70 22 90 03 04 08 11 91 08 F1 B5 1F 0B 96 39 
2013/03/02 12:32:49 8D2158 E8 1A 92 08 18 74 9B 2F 9A 53 36 53 81 07 6A 64 
2013/03/02 12:32:49 8D2158 25 E7 D4 9F 97 
2013/03/02 12:32:51 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:51 8D2158 8C 70 22 90 03 04 08 11 91 08 0F 34 F3 34 5C E0 
2013/03/02 12:32:51 8D2158 EB 34 92 08 86 B1 8F 7A 70 4F CD 31 81 07 11 5D 
2013/03/02 12:32:51 8D2158 D4 59 32 45 E1 
2013/03/02 12:32:52 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:52 8D2158 8D 70 22 90 03 04 08 11 91 08 67 D5 CD 54 F3 92 
2013/03/02 12:32:52 8D2158 02 12 92 08 56 43 4F 27 BF CC C4 77 81 07 04 4E 
2013/03/02 12:32:52 8D2158 CD 43 45 4E F3 
2013/03/02 12:32:54 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:54 8D2158 8C 70 22 90 03 04 08 11 91 08 B4 94 D8 4E 6E 3C 
2013/03/02 12:32:54 8D2158 72 79 92 08 33 CD 39 37 02 3B 4C 2A 81 07 7C A2 
2013/03/02 12:32:54 8D2158 EE EB D5 FC DB 
2013/03/02 12:32:55 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:55 8D2158 8D 70 22 90 03 04 08 11 91 08 AD C0 67 77 A2 B3 
2013/03/02 12:32:55 8D2158 89 5C 92 08 74 B9 21 54 C6 83 82 3B 81 07 60 42 
2013/03/02 12:32:55 8D2158 57 1C 1E F7 BF 
2013/03/02 12:32:56 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:56 8D2158 8C 70 22 90 03 04 08 11 91 08 4E 2F 2B 25 C9 F8 
2013/03/02 12:32:56 8D2158 05 14 92 08 D0 08 A0 04 12 1E 95 02 81 07 A6 66 
2013/03/02 12:32:56 8D2158 A2 69 C8 B2 27 
2013/03/02 12:32:57 8BFA58 c dvbapi (0500&040810/038B): found (217 ms) by sf_easy (L/1/2/2) - 0500:038B unknown 
2013/03/02 12:32:58 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:32:58 8D2158 8D 70 22 90 03 04 08 11 91 08 93 D4 EE 68 61 C8 
2013/03/02 12:32:58 8D2158 E1 55 92 08 3A 2C EB 44 FD FA A5 06 81 07 E4 14 
2013/03/02 12:32:58 8D2158 6A FE 2B 47 53 
2013/03/02 12:32:59 8D2158 r sf_easy [viaccess] dvbapi emmtype=shared, len=82, idx=21, cnt=2: written (334 ms) 
2013/03/02 12:33:00 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:33:00 8D2158 8C 70 22 90 03 04 08 11 91 08 D0 02 A6 0E 7D 7B 
2013/03/02 12:33:00 8D2158 38 19 92 08 4B D9 3C 29 A9 7E A9 18 81 07 78 19 
2013/03/02 12:33:00 8D2158 7A D2 E5 98 E6 
2013/03/02 12:33:00 8D2158 r can't find 0xf0 in emm... 
2013/03/02 12:33:00 8D2158 8D 70 22 90 03 04 08 11 91 08 45 C2 CE 6F 17 AB 
2013/03/02 12:33:00 8D2158 FA 19 92 08 8C F9 7D 0A 1F 2D D4 2E 81 07 FD DA 
2013/03/02 12:33:00 8D2158 4A EF DA F4 09 
2013/03/02 12:33:02 8D2158 r sf_easy [viaccess] dvbapi emmtype=shared, len=82, idx=24, cnt=2: written (198 ms)

[gf]

Please try this. If it works for you I have get confirmation that it works for users of ACamd and mgcamd (which send reassembled EMMs).

[Gorgone Impertinence]

not solved all

2013/03/02 12:55:26 870A58 c dvbapi (0500&040820/1260): found (250 ms) by sf_easy - 0500:1260 unknown 
2013/03/02 12:55:26 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:26 86F308 8D 70 0C 90 03 04 08 21 A9 05 42 56 42 88 04 
2013/03/02 12:55:28 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:28 86F308 8C 70 0C 90 03 04 08 21 A9 05 42 32 42 64 04 
2013/03/02 12:55:32 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:32 86F308 8D 70 0C 90 03 04 08 21 A9 05 42 33 42 65 04 
2013/03/02 12:55:33 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:33 86F308 8C 70 0C 90 03 04 08 21 A9 05 42 57 42 89 04 
2013/03/02 12:55:33 86DBB8 r hd_plus [nagra] dvbapi emmtype=global, len=150, idx=0, cnt=1: written (467 ms) 
2013/03/02 12:55:33 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:33 86F308 8D 70 0C 90 03 04 08 21 A9 05 42 35 42 67 04 
2013/03/02 12:55:34 870A58 c dvbapi (0500&040820/1260): found (213 ms) by sf_easy - 0500:1260 unknown 
2013/03/02 12:55:35 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:35 86F308 8C 70 0C 90 03 04 08 21 A9 05 42 36 42 67 04 
2013/03/02 12:55:36 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:36 86F308 8D 70 0C 90 03 04 08 21 A9 05 42 37 42 6A 04 
2013/03/02 12:55:36 86F308 r can't find 0xf0 in emm... 
2013/03/02 12:55:36 86F308 8C 70 0C 90 03 04 08 21 A9 05 42 39 42 6B 04 

[gf]

Wait a little bit for 0x8e emm to arrive. It turns off writing of emm-s-hdr emms (0x8c and 0x8d).

[Gorgone Impertinence]

but why i got this updates ????

there is no nagra PID

2013/03/02 13:10:32 870A58 c [ADD PID 0] CAID: 0500 ECM_PID: 1FE0 PROVID: 040820 
2013/03/02 13:10:32 870A58 c [ADD PID 1] CAID: 0500 ECM_PID: 1FE1 PROVID: 050810 
2013/03/02 13:10:32 870A58 c Found 2 ECMpids and 2 STREAMpids in PMT 
2013/03/02 13:10:32 870A58 c New program number: 1260 (0500:1260 unknown) [pmt_list_management 3] 
2013/03/02 13:10:32 870A58 c Start descrambling PID #0 (CAID: 0500) 1 
2013/03/02 13:10:32 870A58 c dvbapi (0500&040820/1260): found (210 ms) by sf_easy - 0500:1260 unknown 
2013/03/02 13:10:37 870A58 c dvbapi (0500&040820/1260): found (210 ms) by sf_easy - 0500:1260 unknown 
2013/03/02 13:10:43 87B480 r hd_plus [nagra] dvbapi emmtype=global, len=150, idx=33, cnt=2: written (467 ms) 
2013/03/02 13:10:44 870A58 c dvbapi (0500&040820/1260): found (211 ms) by sf_easy - 0500:1260 unknown 

[MadMaxx]

There is!

On the same Astra-Transponder from "BetaResearch" is Nagra N3 from HDplus for the SD-Testchannels active. So you get EMMs for other cards too, when the filter matches.

In this case you have a nagra_card on your Server and the filter filters out the usual HDPlus Global EMMs for the CG6 RomUpdate.

[Bit]

Looks better on via card. Now only had 2 errors (the first 2 EMMs). All following OK (skipped and written - as usual).
Thanks.

[gf]

@bit: You got "Received EMM-SB (0x8e), assuming we receive non-assembled EMMs." right? After this there should be no more wrongly written EMMs.

[Bit]

Thanks gf.

[gf]

Lets not close this yet, because mgcamd and acamd users have not spoken if my test patch breaks emms for them (and I haven't applied the patch to trunk anyway :)

[Bit]

Oops. Reopen this until patch is committed. ;)

[amet]

Hi,

could this have any impact on irdeto cards as well? seems I cant get any EMM to it atm.

​http://paste.ubuntu.com/5580345/

if you need more info let me know... sorry if this is incomplete, not sure what is needed

a

[gf]

@atmet: Do not discuss unrelated things there is a ticket that discusses irdeto EMMs.

[amet]

aha, sorry... didnt see it.. will stop trying to help

[gf]

Fixed in r8454. Since I can't work out how to make both non-assembled and assembled EMMs to work I chose to leave the defaults better for OSCam and if some client does reassembly then the users of such client should disable emm reassembly in oscam by setting emmreassembly = 0 in their reader section.

[MadMaxx]

I think this confuse new users much more as before....
A mostly list of all possible clients and the supported "emm-modes" can make sense.

In my case i have no difference with ACamd & MGcamd 1.38 on dbox2 for old ORF CW-Card and new ORF ICE-Card in CW-Mode using the "Default-Parameters" (not defined=1)
But for updating my new SRG Via5-Card i need now at the VIACCESS-Reader "0" for the new Parameter, otherwise i no longer got shared EMMs writen to the local card.

Looks like the Default for CW and VIA is not the same by using MGcamd/ACamdD ?

For VIA i suggest to "swap" the default mode internaly, so acamd/mgcamd works like
before without a "manual" setting. I think a very lot of peoples are using this
clients in newcamd mode, and now, without the knowledge of this changed Parameter,
EMM is no longer working in minimal config "on-the-fly" as before...

It can be interessting how other clients and gbox, cccam and camDxx is working with different systems now... ?

[gf]

If someone uses binary client that we have no idea what it does he is on his own.

[MadMaxx]

I noted that proxy-EMM via oscam <-> oscam newcamd-protocol was no longer working
as before for a remote SRG VIA4-Card.

I get it working again by set on the remote/local-reader "emmreassembly = 0"

AND, that is the importent part: I MUST set it on the PROXY-Oscam at the "Remote-newcamd-reader", too!!!

The default-Mode (=1) on a Proxy, that forwards EMMs to Via-Remote-Cards, is no longer working on the fly without manual modification from now on.

So now we have a new Problem: A "oscam-client-user", that get EMMs rights for updating friends cards, must always know what mode the "Master" Server is using.

The first oscam-proxy always fowards the emms, but there is no confirmation from the other end, that emm is really written or not. This sees only the owner of the
Oscam with the physical card...

[gf]

I think your analysis is completely wrong.

1. EMM reassembly is done only on the local reader side.
2. This have *nothing* to do with network protocols and proxying.

It is very simple:

• If the client sends reasembled emms - set emmreassembly to 0.
  • some binary clients does that (they probably use newcamd protocol to talk to oscam, because over newcamd they can get card number and apply their own filtering. Without knowing the card number, they can't do emm reassembly).
• If the client sends all emms, don't touch anything it works.
  • oscam does that.

There are no other options.

[MadMaxx]

OK, i will say:

oscam-proxy <-> oscam-master does newcamd-proto other way as MGcamd & ACamd <-> oscam-master.

[Entity]

Although I'm not affected by this, I guess I understand what MadMaxx is up to:

Lets assume I would have two boxes and one server:

Box 1: Crappy binary client / Connection to server via some network protocol
Box 2: Oscam / Connection to server via some network protocol
Server: Running the reader with "emmreassembly = 0"

Now you will have a mismatch between re-assembled and "all emms" on the same reader at server side.

Maybe this setting should move to the user account to avoid this (or maybe I just do not understand the problem :p)

[gf]

@MadMaxx: This have nothing to do with the protocol and everything to do with what the client sends. Since we can't control what the client sends and can't guess from what it is sending if it sends reassembled emms or all emms the setting was born. If you think of a way to kill the setting and do the right thing in both cases I would be very, very happy.

@entity: you are correct, but in this case (two senders, one reassembles, other does not) it'll still work :)

[Bit]

This "mismatch" you are talking about is the old behaviour.
So, everything is working as before.
But using the new parameter makes it possible to use crappy clients to update the card.
Anyway, there is mo reason to use more than one client to update the card.