Opened 11 years ago
Closed 11 years ago
#3175 closed defect (fixed)
Radegast connection is getting switched off
Reported by: | LePouSAT | Owned by: | |
---|---|---|---|
Priority: | critical | Component: | Protocol - Radegast |
Severity: | high | Keywords: | |
Cc: | Sensitive: | yes |
Description
Revision
8100+
Issue Description
I have a radegast connection to a local LAN reader and when I switch to a channel that is NOT decoded by the card in the "radegast" reader, the connection between the Dreambox and the "radegast" reader is switched off and the reader must be reinitialized through the Dreambox OSCam webif.
When the issue occurs
<Please fill in>
How the issue is reproducable
Every time I switch to a channel that is not supported by the card inside the reader (connected by radegast)
Attachments (3)
Change History (23)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
@LePouSat: overall you should bring an evidence of when you request again on that connexion you get nothing and no re-connexion...
comment:3 by , 11 years ago
and what do you think should a dev do with your description? try to log the problem or we close the ticket. or make services that only supported channels are requeste.
comment:4 by , 11 years ago
here attached a log showing a part of the phenomenon.
-we can see here how a radegast reader blocked (not responding) is able to answer again after restarting.
Knasson
comment:5 by , 11 years ago
Isn't that maybe a loadbalancer problem? Does it also happen with lb disabled?
follow-up: 10 comment:7 by , 11 years ago
I disabled LB but it is still disconnecting the radegast reader ... My only current solution is to add the radegast box under a "CCcam 2.3.0" emu and the nto connect using OSCam to the CCcam emu ...
follow-up: 9 comment:8 by , 11 years ago
Ever thought about that the radegast server in the Atlas doesn't answer sometimes?
This could explain the behaviour.
comment:9 by , 11 years ago
Replying to Bit:
Ever thought about that the radegast server in the Atlas doesn't answer sometimes?
This could explain the behaviour.
Not at all ..I you had a look at the logs what you saw is that the radegast reader is blocked after asking a SID not present on the server.
Secondly all witnesses (never experimented by myself) show that this phenomenon desappears when you connect the Atlas server to a CSP radegast connector.
If this was due to a missing response of the server this would happen even in this case.
comment:10 by , 11 years ago
Replying to LePouSAT:
I disabled LB but it is still disconnecting the radegast reader ... My only current solution is to add the radegast box under a "CCcam 2.3.0" emu and the nto connect using OSCam to the CCcam emu ...
@ lePouSat: another best way to avoid the oscam problem seems to be to connect Atlas directly to CSP radegast connector.
comment:11 by , 11 years ago
Yes but as the radegast module in OSCam has not been modified since a while, another good solution could be that it is updated to current other stuff ...
comment:12 by , 11 years ago
evrey time you get these comments the reader is definitely blocked and unable to start again by himself:
"
2013/03/19 09:39:10 518FA8 p radegast: no dcw
2013/03/19 09:39:10 518FA8 p atlas [radegast] disconnected: reason disconnect on receive"
Please have a look in the code to see what could be happening in this case.
Thank you
comment:13 by , 11 years ago
anyone has planned or may plan to update the radegast stuff so that this problem is fixed ??
comment:14 by , 11 years ago
Tried with 8646 and 8647. Good news is that the new Atlas TNTSAT 030B00 HD emu is available thru a radegast connection but still blocking. So the problem is not solved. Can someone have a closer look at this please? Maybe compare the radegast protocol handling of CSP and oscam?
Cheers.
LJ
comment:15 by , 11 years ago
patch :
inactivitytimeout = # en seconds
-1 # reconnect on network failure for newcamd and radegast based readers, even in idle
0 # par défaut rien n'est donné
Index: module-radegast.c
===================================================================
--- module-radegast.c (revision 8648)
+++ module-radegast.c (working copy)
@@ -209,12 +209,12 @@
{
int32_t handle;
+ handle = network_tcp_connection_open(cl->reader);
+ if(handle < 0) return -1;
+
cs_log("radegast: proxy %s:%d (fd=%d)",
cl->reader->device, cl->reader->r_port, cl->udp_fd);
- handle = network_tcp_connection_open(cl->reader);
- if(handle < 0) return -1;
-
cl->reader->tcp_connected = 2;
cl->reader->card_status = CARD_INSERTED;
cl->reader->last_g = cl->reader->last_s = time((time_t *)0);
@@ -236,6 +236,41 @@
return;
}
+static int32_t radegast_connect(void)
+{
+ struct s_client *cl = cur_client();
+
+ if (cl->reader->tcp_connected < 2 && radegast_cli_init(cl) < 0)
+ return 0;
+
+ if (!cl->udp_fd)
+ return 0;
+
+ return 1;
+}
+
+void radegast_idle(void) {
+ struct s_client *client = cur_client();
+ struct s_reader *rdr = client->reader;
+
+ if (!rdr) return;
+
+ if (rdr->tcp_ito > 0) {
+ inactivitytimeout > 0 enables protocol
+ time_t now;
+ int32_t time_diff;
+ time(&now);
+ time_diff = abs(now - rdr->last_s);
+ if (time_diff>(rdr->tcp_ito)) {
+ network_tcp_connection_close(client->reader, "inactivity");
+ }
+ }
+ else if (rdr->tcp_ito == -1) {
+ idle reconnect
+ radegast_connect();
+ }
+}
+
void module_radegast(struct s_module *ph)
{
ph->ptab.nports = 1;
@@ -248,6 +283,7 @@
IP_ASSIGN(ph->s_ip, cfg.rad_srvip);
ph->s_handler=radegast_server;
ph->s_init=radegast_server_init;
+ ph->c_idle = radegast_idle;
ph->recv=radegast_recv;
ph->send_dcw=radegast_send_dcw;
ph->c_init=radegast_cli_init;
comment:16 by , 11 years ago
@goodsat. YOU ARE A BOSS! Thanks!!! You patch works very well!
Rest to adapt radegast reader webif editor to include the inactivitytimeout parameter (I dont see it anymore) and add it to the documentation.
One more time. Thanks. I think you can add it to the trunk.
comment:17 by , 11 years ago
Correction after more testing.
The patch works, It keeps the connection active but now if you ask for a non subscribed channel, you get a "disconnect on receive" message in the log and you loose the connection to the reader. Then it after a few time, it reconnects automatically. That's the good point of the patch but the main issue of this ticket is still existing. A little progress anyway. Thanks.
I hope someone can compare the CSP radegast gestion to the way oscam does and find the problem.
So don not add this patch to the trunk yet please.
LJ
comment:18 by , 11 years ago
Hi,
I can confirm the same not really the same in fact, the connection goes to unknown after few ecm and seems to never reconnect (until i restart proxy/reader).
Thanks.
comment:19 by , 11 years ago
Hi , look this post http://www.streamboard.tv/wbb2/thread.php?threadid=38175&threadview=0&hilight=&hilightuser=0&sid=2acb8b3178b31189213341fbab99fc83&page=2
files.patched.svn8654.zip
zip patch.svn8654.zip
comment:20 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
@LePouSat: you should had some evidences of what you observe..Because radegast looks like a UDP protocol perhaps what you see is only a timeout of your connexion.