module-cccam.c: reconnect to server: wrong password (fix added)

[speedfrog]

If the CCcam remote reader died, the oscam reconnects, but at this moment the password to that connection was already encrypted.

In cc_cli_connect() the reader[ridx].r_pwd get's encrypted again resulting in a wrong password on the CCcam server.

Below is a patch to module-cccam.c to solve this issue.

---

Still not found out, why at the 2nd command after reconnect the CCcam server disconnects with a

 CCcam: deleting client 172.20.1.254(oscam), bad command

So it seems, that after a reconnect, the module-cccam send a bad command, but I'm still searching for that...

reconnect after CCcam server gone down

2010/01/05 10:17:55  26176 p02 cccam: proxy 172.20.1.200:12000 cccam v (), maxhop = 10 (fd=3, ridx=0)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 1 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 2 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: n = -1
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 5 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 6 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 9 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: server init seed:
2010/01/05 10:17:55  26176 p02 cccam: sha1 hash:
2010/01/05 10:17:55  26176 p02 cccam: send:
2010/01/05 10:17:55  26176 p02 cccam: username 'oscam':
2010/01/05 10:17:55  26176 p02 cccam: send:

now logging in again with the password not encrypted before

2010/01/05 10:17:55  26176 p02 cccam: 'CCcam' xor StdPwd
2010/01/05 10:17:55  26176 p02 cccam: send:
2010/01/05 10:17:55  26176 p02 cccam: pwd ack received:
2010/01/05 10:17:55  26176 p02 cccam: login succeeded
2010/01/05 10:17:55  26176 p02 cccam: last_s=1262683075, last_g=1262683075
2010/01/05 10:17:55  26176 p02 cccam: send client data
2010/01/05 10:17:55  26176 p02 cccam: user: oscam, version: , build:
2010/01/05 10:17:55  26176 p02 cccam: send:
2010/01/05 10:17:55  26176 p02 cccam: ecm trylock: got lock
2010/01/05 10:17:55  26176 p02 cccam: ecm crc = 0x9bf6f32a
2010/01/05 10:17:55  26176 p02 cccam: no suitable card on server
2010/01/05 10:17:55  26176 p02 cccam: received 4 bytes from remote server
2010/01/05 10:17:55  26176 p02 cccam: client data ack
2010/01/05 10:17:55  26176 p02 cccam: received 76 bytes from remote server
2010/01/05 10:17:55  26176 p02 cccam: srv AC4E2370AFC305F4 running v2.1.0 (2944)
2010/01/05 10:17:55  26176 p02 cccam: received 4 bytes from remote server

So far, everything is right, but at the next command, the CCcam server tells me:

10:18:16.779 CCcam: deleting client 172.20.1.254(oscam), bad command

resulting in a reconnect from the oscam:

2010/01/05 10:17:55  26176 p02 cccam: proxy 172.20.1.200:12000 cccam v (), maxhop = 10 (fd=3, ridx=0)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 1 (fd=3)
2010/01/05 10:17:55  26176 p02 cccam: conn_nb 2 (fd=3)

... a.s.o.

[crisman]

I think we need to logout first and then trying to reconnect.
I see no functions that do logout before the reconnect...
This should solve the issue about bad command

[Vlado Fogo]

your patch is bad '''

2010/01/05 12:01:46 28272 s >> OSCam << cardserver started version 0.99.4svn, build #1068 (i686-pc-linux)
2010/01/05 12:01:46 28272 s auth size=6084
2010/01/05 12:01:46 28272 s services reloaded: 0 services freed, 7 services loaded
2010/01/05 12:01:46 28272 s userdb reloaded: 0 accounts freed, 5 accounts loaded, 0 expired
2010/01/05 12:01:46 28272 s signal handling initialized (type=sysv)
2010/01/05 12:01:46 28272 s 2276 service-id's loaded
2010/01/05 12:01:46 28272 s 22 lengths for caid guessing loaded
2010/01/05 12:01:46 28272 s monitor: initialized (fd=5, port=18000)
2010/01/05 12:01:46 28272 s camd 3.3x: disabled
2010/01/05 12:01:46 28272 s camd 3.5x: disabled
2010/01/05 12:01:46 28272 s cs378x: disabled
2010/01/05 12:01:46 28272 s newcamd: initialized (fd=6, port=5000, crypted)
2010/01/05 12:01:46 28272 s CAID: 0604
2010/01/05 12:01:46 28272 s provid #0: 000000
2010/01/05 12:01:46 28272 s provid #1: 000001
2010/01/05 12:01:46 28272 s provid #2: 000002
2010/01/05 12:01:46 28272 s radegast: disabled
2010/01/05 12:01:46 28272 s resolver thread started
2010/01/05 12:01:46 28272 s logger started (pid=28274)
2010/01/05 12:01:46 28272 s resolver started (pid=28275, delay=30 sec)
2010/01/05 12:01:46 28272 s http started (pid=28276)
2010/01/05 12:01:46 28272 s proxy started (pid=28278, server=xxx.xxxxx.com)
2010/01/05 12:01:46 28272 s Waiting for local card init ....
2010/01/05 12:01:46 28278 p04 cccam: proxy xxx.xxxxx.com:16666 cccam v2.1.3 (3165), maxhop = 5 (fd=3, ridx=1)
2010/01/05 12:01:46 28276 h HTTP Server listening on port 8060
2010/01/05 12:01:46 28278 p04 cccam: login failed, pwd ack not received (n = -1)

[speedfrog]

Strange: Patch working here... All it does is copying the pwd to a buf before encrypting it.

[speedfrog]

Just found out: If it reconnected once, it tries to reconnect again and again resulting in this behaviour. When not having reconnected, e.g. CCcam server never died, oscam just knows, that the CAID is not present on server and doesn't query the server again.

The message "bad command" is produced by CCcam server itself without receiving anything from oscam. It just disconnects with a FIN/ACK. See attached wireshark trace.

Maybe something with reinitting everything in cc_cli_connect() w/o "logout" as crisman said.

So I suggest also the following in cc_cli_connect():

@@ -877,10 +884,18 @@
   uint8 data[20];
   uint8 hash[SHA_DIGEST_LENGTH];
   uint8 buf[CC_MAXMSGSIZE];
+  char pwd[64];
   struct cc_data *cc;

+  if (reader[ridx].cc) free(reader[ridx].cc);
+
   // init internals data struct
   cc = malloc(sizeof(struct cc_data));
+  if (cc==NULL) {
+    cs_log("cccam: cannot allocate memory");
+    return -1;
+  }
+
   reader[ridx].cc = cc;
   bzero(reader[ridx].cc, sizeof(struct cc_data));
   cc->cards = llist_create();

}}}

[speedfrog]

Replying to Vlado Fogo:

your patch is bad '''

2010/01/05 12:01:46 28272 s >> OSCam << cardserver started version 0.99.4svn, build #1068 (i686-pc-linux)

...

2010/01/05 12:01:46 28278 p04 cccam: proxy xxx.xxxxx.com:16666 cccam v2.1.3 (3165), maxhop = 5 (fd=3, ridx=1)
2010/01/05 12:01:46 28276 h HTTP Server listening on port 8060
2010/01/05 12:01:46 28278 p04 cccam: login failed, pwd ack not received (n = -1)

Did you use latest SVN version? Because in older versions the

  bzero(buf, sizeof(buf));
  memcpy(buf, reader[ridx].r_usr, strlen(reader[ridx].r_usr));

line initing the username is missing. Since it might be, that the local buf get's used again having other bytes stored in there before, the username is not the one you have in your cfg scripts.

And as you can see, the terminating \0 of r_usr isn't copied.

[crisman]

Replying to speedfrog:

Just found out: If it reconnected once, it tries to reconnect again and again resulting in this behaviour. When not having reconnected, e.g. CCcam server never died, oscam just knows, that the CAID is not present on server and doesn't query the server again.

The message "bad command" is produced by CCcam server itself without receiving anything from oscam. It just disconnects with a FIN/ACK. See attached wireshark trace.

Maybe something with reinitting everything in cc_cli_connect() w/o "logout" as crisman said.

So I suggest also the following in cc_cli_connect():

@@ -877,10 +884,18 @@
   uint8 data[20];
   uint8 hash[SHA_DIGEST_LENGTH];
   uint8 buf[CC_MAXMSGSIZE];
+  char pwd[64];
   struct cc_data *cc;

+  if (reader[ridx].cc) free(reader[ridx].cc);
+
   // init internals data struct
   cc = malloc(sizeof(struct cc_data));
+  if (cc==NULL) {
+    cs_log("cccam: cannot allocate memory");
+    return -1;
+  }
+
   reader[ridx].cc = cc;
   bzero(reader[ridx].cc, sizeof(struct cc_data));
   cc->cards = llist_create();

}}}

Does this patch solve the reconnect problem?

[speedfrog]

Replying to crisman:

Replying to speedfrog:

Just found out: If it reconnected once, it tries to reconnect again and again

[...]

So I suggest also the following in cc_cli_connect():

@@ -877,10 +884,18 @@
   uint8 data[20];
   uint8 hash[SHA_DIGEST_LENGTH];
   uint8 buf[CC_MAXMSGSIZE];
+  char pwd[64];
   struct cc_data *cc;

+  if (reader[ridx].cc) free(reader[ridx].cc);
+
   // init internals data struct
   cc = malloc(sizeof(struct cc_data));
+  if (cc==NULL) {
+    cs_log("cccam: cannot allocate memory");
+    return -1;
+  }
+
   reader[ridx].cc = cc;
   bzero(reader[ridx].cc, sizeof(struct cc_data));
   cc->cards = llist_create();

}}}

Does this patch solve the reconnect problem?

No, this is one just does some cleanups: free allocated memory before overwriting the pointer again, checking malloc result. Otherwise each reconnect would waste memory of sizeof(struct cc_data).

I'm still trying to find out, why oscam retries to connect again and again after a disconnect from server, but doesn't when not beeing disconnected at least once.

[speedfrog]

Replying to speedfrog:

Replying to crisman:

Replying to speedfrog:

Just found out: If it reconnected once, it tries to reconnect again and again

[...]

So I suggest also the following in cc_cli_connect():

@@ -877,10 +884,18 @@
   uint8 data[20];
   uint8 hash[SHA_DIGEST_LENGTH];
   uint8 buf[CC_MAXMSGSIZE];
+  char pwd[64];
   struct cc_data *cc;

+  if (reader[ridx].cc) free(reader[ridx].cc);
+
   // init internals data struct
   cc = malloc(sizeof(struct cc_data));
+  if (cc==NULL) {
+    cs_log("cccam: cannot allocate memory");
+    return -1;
+  }
+
   reader[ridx].cc = cc;
   bzero(reader[ridx].cc, sizeof(struct cc_data));
   cc->cards = llist_create();

}}}

Does this patch solve the reconnect problem?

No, this is one just does some cleanups: free allocated memory before overwriting the pointer again, checking malloc result. Otherwise each reconnect would waste memory of sizeof(struct cc_data).

I'm still trying to find out, why oscam retries to connect again and again after a disconnect from server, but doesn't when not beeing disconnected at least once.

To be more precise: The attached patch at least solves the reconnect problem, so that oscam could reconnect after a CCcam server downtime ("wrong password after disconnect" issue).

[speedfrog]

SOLUTION:
Apply the attached patches to the latest SVN, if not already done.

Ad CCcam server message bad command

CCcam: deleting client 172.20.1.254(oscam), bad command

This is not a bad command, this is just because the oscam closes the connection.

Ad Why does this happen after reconnect to CCcam server?
In oscam-reader.c:network_tcp_connection_close() does a reconnect try immideately, but after that, even if successful, sets reader[ridx].last_g = 0, resulting in a laaarge reconnect timeout the next time :-(
Solution: Moved this initialization in front of reconnect. (Maybe = time(0) was ment here)
See attached oscam-reader.c.patch

Ad reconnection timeout
This was hardcoded to 60 hours and thus was not configurable. Since after reconnect the last access time was set to 0 (1.1.1970), after reconnect it retried all the time.
reconnection timeout is configurable now as documented.

Ad wrong password on reconnect
This was clearly a bug and is fixed with the patch.

Ad changes in modules-cccam.c:cc_recv()

  if (n < 4) {
    cs_log("cccam: packet to small (%d bytes)", n);
    n = -1;
  } else if (n == 0) {
    cs_log("cccam: Connection closed to %s", remote_txt());
    n = -1;
  }

is senseless, 2nd choice get's never called. Changed to

  if (n == 0) {
    cs_log("cccam: Connection closed to %s", remote_txt());
    n = -1;
  } else if (n < 4) {
    cs_log("cccam: packet to small (%d bytes)", n);
    n = -1;
  } else {
    // parse it and write it back, if we have received something of value
    cc_parse_msg(cbuf, n);
    memcpy(buf, cbuf, l);
  }

cc_parse_msg() is done only on valid bytes received now.
the buf[] is only filled on valid bytes received, otherwise the old buf is untouched. (Was this the intension - because why it is copied then?)

Other fixes are cosmetic and should provide more stability.

[crisman]

works for me too. I think is better if ticket is reopened until patch is being applied on official trunk

[cogsi]

Ok - thanks for all your hard work - i'll apply the patch today.

[cogsi]

Applied to SVN - thanks for the hard work speedfrog!
Lets try find otu why the rest of teh strange behaviour is happening!

[alno]

no feedback - assume solved