Opened 12 years ago

Closed 12 years ago

#248 closed defect (wontfix)

oscam: svn-trunk camd35 Protokoll error

Reported by: CyberSoft Owned by:
Priority: major Component:
Severity: medium Keywords:
Cc: MFco Sensitive: no

Description

oscam:
2009/12/20 22:11:56 9296 c01 camd3 emm-request sent (reader=hd+, caid=1830)

camd3:
20.12.2009 21:11:55 camd3: request from camd3 ( 192.168.64.105 ) dropped: CMD05 protokol error

Das Problem tritt mit allen camd3 clientversionen an, 3.86, 3.902, 2.908L. Server sowohl x84_64 wie auch mipsel-fritz.
nicht mit caid 1830 auch mit 1702 im Tunnel.

Wird die gleiche Einstellung gegen den mpcs gefahren, treten die Fehler nicht auf.

Change History (2)

in reply to:  description comment:1 by MFco, 12 years ago

Cc: MFco added

Replying to CyberSoft:

oscam:
2009/12/20 22:11:56 9296 c01 camd3 emm-request sent (reader=hd+, caid=1830)

camd3:
20.12.2009 21:11:55 camd3: request from camd3 ( 192.168.64.105 ) dropped: CMD05 protokol error

Das Problem tritt mit allen camd3 clientversionen an, 3.86, 3.902, 2.908L. Server sowohl x84_64 wie auch mipsel-fritz.
nicht mit caid 1830 auch mit 1702 im Tunnel.

Wird die gleiche Einstellung gegen den mpcs gefahren, treten die Fehler nicht auf.

Ich bin zwar kein Dev und von C habe ich auch wenig Ahnung, aber da
ich an einer anderen Sache dran bin, die auch ein bisschen mit der
module-camd35.c zu tun hat, habe ich mir das mal angeschaut.

Wie im Code- und im Log-Schnippsel zu sehen ist, wird der CMD05-Request
zweimal an den Client gesendet, einmal mit 111 (0x6F) und einmal mit
112 (0x70) Byte Datenlänge. Grund dafür dürfte sein, dass nicht
festgestellt werden kann, welche Camd3-/cs357x-Protokoll-Version der
Client verwendet oder es zuviel Aufwand wäre, die Version festzustellen
(Keine Ahnung, ob sich vlt. im Protokoll-Header ein Versions-Bit/Byte
versteckt.).

@Dukat wird deshalb, imho, den Weg des doppelten Sendens gegangen
sein (ab v0.9b1), da somit mit ziemlicher Sicherheit eine der beiden
CMD05-Anfragen (i.d.R.) dann immer angenommen wird, egal welche
Camd3-/Protokoll-Version beim Client verwendet wird, die falsche
CMD05-Anfrage wird dann eben dropped/abgelehnt/nicht beachtet. Diese
dropped-Meldungen (protokol error) hat m.W. @doz21 mit der Cand3 v3.705
eingeführt (strenge Validierung der Request-CMDs).

Meinen Erfahrungen nach, hat "dropped: CMD05 protokol error", falls
es so wie bisher weitergehandhabt wird, keine Auswirkungen auf AU
(EMM-Updates), ist halt nur eine Meldung, wie auch
"dropped: CMD44 protokol error" -> not found, mehr nicht. ;)

Mit welcher mpcs-version hast du gegengetestet?
Womöglich wurde das Doppel bei dieser Version entfernt und darauf
vertraut, dass der Client eine neuere Camd3-/Protokoll-Version
verwendet.

module-camd35.c Zeilen 198-200

    camd35_send(mbuf);		// send with data-len 111 for camd3 > 3.890
    mbuf[1]++;
    camd35_send(mbuf);		// send with data-len 112 for camd3 < 3.890

oscam.log (-d63):

2009/12/22 15:27:55    508 c02 db1n5wz emm-request sent (reader=s02_beta, caid=1702)
2009/12/22 15:27:55    508 c02 send 144 bytes to client
2009/12/22 15:27:55    508 c02 05 6F FF FF 27 B6 04 16 00 13 17 02 00 00 00 00 
2009/12/22 15:27:55            BB 2E 00 00 17 02 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 01 xx xx xx 1A 00 00 00 04 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 01 00 00 00 00 02 00 
2009/12/22 15:27:55            00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            01 01 01 FF FF FF FF FF FF FF FF FF FF FF FF FF 
2009/12/22 15:27:55    508 c02 send 144 bytes to client
2009/12/22 15:27:55    508 c02 05 70 FF FF 26 F1 EC D8 00 13 17 02 00 00 00 00 
2009/12/22 15:27:55            BB 2E 00 00 17 02 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 01 xx xx xx 1A 00 00 00 04 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 01 00 00 00 00 02 00 
2009/12/22 15:27:55            00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2009/12/22 15:27:55            01 01 01 00 FF FF FF FF FF FF FF FF FF FF FF FF 

comment:2 by alno, 12 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.