Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1617 closed defect (invalid)

cs357 login ok but ECM rejected - checksum error

Reported by: oscvasile Owned by:
Priority: major Component: Protocol - Camd3
Severity: high Keywords: cs357x
Cc: Sensitive: no

Description

Revision

4658

Issue Description

a mgcamd client, connecting with the cs357x protocol (UDP) does not get any reply, and gets disconnected each time once the first ECM is sent to oscam.
I use oscam for linux x32 on Debian
The channel I try to watch is 13eme Rue, 0500:032830 - CanalSat FR
The connection using cccam and newcamd protocol works using the same user/pwd, the reason I want to use cs357x is in the hope my card (remotely accessed on another PC) would be updated (AU) using mgcamd on the Azbox.

When the issue occurs

always

How the issue is reproducable

just connect to oscam from mgcamd using cs357x protocol

relevant log section:
2011/02/04 11:42:08 AFAFF280 c encrypted camd35-client 10.168.99.17 granted (upd, au=1)
2011/02/04 11:42:08 AFAFF280 c received 80 bytes from client
2011/02/04 11:42:08 AFAFF280 00 34 FF FF D0 A5 62 88 46 1F 00 05 30 28 03 00
2011/02/04 11:42:08 AFAFF280 24 00 FF FF 80 70 31 01 90 03 03 28 38 E2 03 3E
2011/02/04 11:42:08 AFAFF280 44 79 E2 03 3E 44 A2 E2 03 3E 44 93 EA 10 52 86
2011/02/04 11:42:08 AFAFF280 C9 2B 87 DF 57 11 7F 0D 33 53 16 37 59 77 F0 08
2011/02/04 11:42:08 AFAFF280 F8 41 24 3C 7B 38 9D F3 FF FF FF FF FF FF FF FF
2011/02/04 11:42:08 AFAFF280 c checksum error (wrong password ?)
2011/02/04 11:42:08 AFAFF280 c upd disconnected from 10.168.99.17

Attachments (4)

oscam-sanitized.conf (1.5 KB ) - added by oscvasile 13 years ago.
oscam-sanitized.server (838 bytes ) - added by oscvasile 13 years ago.
oscam-sanitized.user (327 bytes ) - added by oscvasile 13 years ago.
oscam-sanitized.log (6.9 KB ) - added by oscvasile 13 years ago.

Download all attachments as: .zip

Change History (10)

by oscvasile, 13 years ago

Attachment: oscam-sanitized.conf added

by oscvasile, 13 years ago

Attachment: oscam-sanitized.server added

by oscvasile, 13 years ago

Attachment: oscam-sanitized.user added

by oscvasile, 13 years ago

Attachment: oscam-sanitized.log added

comment:1 by oscvasile, 13 years ago

Update: same problem when oscam client attempts to connect to oscam server using cs357 protocol, so it's not related to mgcamd

comment:2 by Deas, 13 years ago

Resolution: invalid
Status: newclosed

for mgcamd: please use newcamd protocol. the dump looks ok, but we think mgcamd works not best with camd3 protocol and could have a bug. other clients (camd3, oscam, etc.) have no problem connecting via this protocol.

for oscam: we can´t believe that other clients also have this problem! a LOT are using camd3 protocol with oscam client and i never heard of such a bug. do you have any super special characters in your user/password? if yes, remove them and try with normal characters.

comment:3 by Deas, 13 years ago

what alno discovered now is that it could be a endianess problem on your client - the caid in your logs is written in wrong order. 00 05 instead 05 00. but you did not write anything about your client software/hardware platform...

comment:4 by oscvasile, 13 years ago

Client was on AZbox Premium HD+, server on Debian x86. I gave up since it just would not work, and changed to newcamd, although its inconvenient since it only deals with one CAID per port...

I stand by the bug report though, as it is reproductible. No "unusual" characters in user/pwd, already did that before reporting the bug...

rgds

comment:5 by _network, 13 years ago

this is an byte order issue.
the checksum is send in different byte order and so the server thinks the request is invaild.
since no one else has this issue we wont change anything here cause this possibly break other clients.
most likely emm will not work here anyways because serial, provider and caid are send in wrong byte order too and so emm processing will fail.

comment:6 by oscvasile, 13 years ago

I think you should look closer at the issue, although no one else reported it, clearly oscam behaves differently between being client and server on different platforms (x86 debian = server and AZBox client), and this is between oscam instances, so it has to do with the way the protocol is implemented...

Having said that, I see your point and will let this bug die :-) as long as it does not cause problems to others... I will manage with newcamd protocol that does the job, although I will have to use it only during card update period and revert to cccam otherwise as cccam allows me other CAIDs...

thanks & regards

Note: See TracTickets for help on using tickets.