- Package:
- libiksemel-dev
- Source:
- libiksemel
- Description:
- C library for the Jabber IM platform - development files
- Submitter:
- David Hoces Pérez
- Date:
- 2014-09-13 06:06:04 UTC
- Severity:
- important
Function "iks_recv" does not returns after no data arrives for timeout seconds.
Can you give some more information? Do you use some transport of yours or the default? Why isn't there any data arriving? Doesn't the other end send anything application-wise or is the TCP connection dead? I was just preparing a new upstream version to upload, but it does not change anything related to the transports, so I guess that will not fix it. I will see if we can fix this soon and hold the upload for now. Regards, Cascardo.
Hi, my english is not good but will try it.
En Wed, 14 Jan 2009 14:23:55 -0200
Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org> escribió:
I use default XMPP transport.
Yes, the XMPP connection deads after no data arrives for timeout seconds because the other end does not send anything (application-wise). TCP connection is fine.
I have a loop to keep XMPP connection alive but it fails because iks_recv does not return.
do
{
switch(retorno = iks_recv(sesion.analizador, 1))
{
default:
if (--tiempo_conexionViva < 0 )
{
iks_send_raw(sesion.analizador, " ");
tiempo_conexionViva = JBOT_TIEMPO_CONEXION_VIVA;
}
}
}while(retorno == IKS_OK);
Thank you very much.
One more information. Do you use TLS? That is, does iks_is_secure (analizador) return something different than 0 (zero)? There is no current timeout in the code when using TLS. If that is the case, I have a fix in mind already that will solve the issue.
I had not received your question but I have read it on the web (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511808). Yes, I have not tried iks_is_secure but I was using TLS. Ok, thank you very much.
---
src/stream.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/stream.c b/src/stream.c
index 6bb316e..e0839a4 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -33,6 +33,7 @@ struct stream_data {
#ifdef HAVE_GNUTLS
gnutls_session sess;
gnutls_certificate_credentials cred;
+ int timeout;
#endif
};
@@ -55,8 +56,9 @@ tls_pull (iksparser *prs, char *buffer, size_t len)
struct stream_data *data = iks_user_data (prs);
int ret;
- ret = data->trans->recv (data->sock, buffer, len, -1);
- if (ret == -1) return (size_t) -1;
+ ret = data->trans->recv (data->sock, buffer, len, data->timeout);
+ if (!ret) gnutls_transport_set_errno (data->sess, EAGAIN);
+ if (ret == -1 || ret == 0) return (size_t) -1;
return ret;
}
@@ -91,6 +93,8 @@ handshake (struct stream_data *data)
gnutls_transport_set_pull_function (data->sess, (gnutls_pull_func) tls_pull);
gnutls_transport_set_ptr (data->sess, data->prs);
+ data->timeout = -1;
+
ret = gnutls_handshake (data->sess);
if (ret != 0) {
gnutls_deinit (data->sess);
@@ -489,6 +493,7 @@ iks_recv (iksparser *prs, int timeout)
while (1) {
#ifdef HAVE_GNUTLS
if (data->flags & SF_SECURE) {
+ data->timeout = timeout;
len = gnutls_record_recv (data->sess, data->buf, NET_IO_BUF_SIZE - 1);
} else
#endif
--
1.6.0.6
Hello, David. I've written and tested this fix. Please, test it too. If you are satisfied, I will be uploading it soon. Regards, Cascardo.
Hello, David. I've written and tested this fix. Please, test it too. If you are satisfied, I will be uploading it soon. Regards, Cascardo.
---
src/stream.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/stream.c b/src/stream.c
index 6bb316e..e0839a4 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -33,6 +33,7 @@ struct stream_data {
#ifdef HAVE_GNUTLS
gnutls_session sess;
gnutls_certificate_credentials cred;
+ int timeout;
#endif
};
@@ -55,8 +56,9 @@ tls_pull (iksparser *prs, char *buffer, size_t len)
struct stream_data *data = iks_user_data (prs);
int ret;
- ret = data->trans->recv (data->sock, buffer, len, -1);
- if (ret == -1) return (size_t) -1;
+ ret = data->trans->recv (data->sock, buffer, len, data->timeout);
+ if (!ret) gnutls_transport_set_errno (data->sess, EAGAIN);
+ if (ret == -1 || ret == 0) return (size_t) -1;
return ret;
}
@@ -91,6 +93,8 @@ handshake (struct stream_data *data)
gnutls_transport_set_pull_function (data->sess, (gnutls_pull_func) tls_pull);
gnutls_transport_set_ptr (data->sess, data->prs);
+ data->timeout = -1;
+
ret = gnutls_handshake (data->sess);
if (ret != 0) {
gnutls_deinit (data->sess);
@@ -489,6 +493,7 @@ iks_recv (iksparser *prs, int timeout)
while (1) {
#ifdef HAVE_GNUTLS
if (data->flags & SF_SECURE) {
+ data->timeout = timeout;
len = gnutls_record_recv (data->sess, data->buf, NET_IO_BUF_SIZE - 1);
} else
#endif
--
1.6.0.6
Hello. I just have be realized that, perhaps, the bug is not on AMD64. My personal computer, at home, is an AMD64 and it seems iksemel just runs fine. Is it that possible? So, tomorrow (Monday) I will test the patch on the computer with I usually work. It's the computer from which I reported to you the bug. Thanks. En Fri, 16 Jan 2009 22:34:18 -0200 cascardo@minaslivre.org escribió:
Hi, these two lines: + if (!ret) gnutls_transport_set_errno (data->sess, EAGAIN); + if (ret == -1 || ret == 0) return (size_t) -1; should not be added, as it will hide EOF conditions. Note that this bug can be sidestepped by providing an ikstransport in which the read function does an additional select(). Also note that even with this workaround, there is another bug in libiksemel in that it does not handle continuing the ssl handshake. (I'll post a bug upstream to http://code.google.com/p/iksemel/).