Hi Andrei,
Which version has this change? I don't see it in 3.0.4, the realease note
says that it is fixed. Here is the function
int tls_h_fix_read_conn(struct tcp_connection *c)
{
int ret;
struct tls_extra_data* tls_c;
ret = -1;<=== Isn't it to be zero. Thats what i understood from the patch.
tls_c = 0;
if (unlikely(c->extra_data==0)){
lock_get(&c->write_lock);
if (unlikely(tls_update_fd(c, c->fd) < 0)){
ret = -1;
} else {
tls_c=(struct tls_extra_data*)c->extra_data;
switch(tls_c->state){
case S_TLS_ACCEPTING:
ret=tls_accept(c, 0);
break;
case S_TLS_CONNECTING:
ret=tls_connect(c, 0);
break;
default:
/* fall through */
ret=1;
break;
}
}
lock_release(&c->write_lock);
} else {
tls_c=(struct tls_extra_data*)c->extra_data;
switch (tls_c->state) {
case S_TLS_ACCEPTING:
lock_get(&c->write_lock);
tls_c=(struct tls_extra_data*)c->extra_data;
/* It might have changed meanwhile */
if (likely(tls_c->state == S_TLS_ACCEPTING)) {
ret = tls_update_fd(c, c->fd);
if (ret == 0) ret = tls_accept(c, 0);
else ret = -1;
}
lock_release(&c->write_lock);
break;
case S_TLS_CONNECTING:
lock_get(&c->write_lock);
tls_c=(struct tls_extra_data*)c->extra_data;
/* It might have changed meanwhile */
if (likely(tls_c->state == S_TLS_CONNECTING)) {
ret = tls_update_fd(c, c->fd);
if (ret == 0) ret = tls_connect(c, 0);
else ret = -1;
}
lock_release(&c->write_lock);
break;
default: /* fall through */
ret=1;
break;
}
}
return (ret>=0)?(tls_c->state==S_TLS_ESTABLISHED):ret;
}
On Mon, Aug 23, 2010 at 11:00 AM, Couprie Geoffroy <
geoffroy.couprie(a)atosorigin.com> wrote:
Hello,
-----Message d'origine-----
De : Andrei Pelinescu-Onciul [mailto:andrei@iptel.org]
Envoyé : vendredi 20 août 2010 12:35
À : Couprie Geoffroy
Cc : sr-users(a)lists.sip-router.org
Objet : Re: [SR-Users] Setting up TLS between proxy and authentication
server
On Aug 20, 2010 at 12:32, Andrei Pelinescu-Onciul
<andrei(a)iptel.org>
wrote:
> On Aug 20, 2010 at 10:18, Couprie Geoffroy
<
geoffroy.couprie(a)atosorigin.com> wrote:
> > Hello,
> >
> > I am testing TLS communication with Kamailio 3.0.2, and I encounter a
strange problem. My setup is like this:
> >
> > Client <-UDP-> Proxy server <- TLS with client certificate
authentication -> Authentication server
>
192.168.24.1 192.168.24.128
192.168.24.129
> >
> > The two servers are instance of Kamailio 3.0.2
> >
> > When the client sends a REGISTER, the proxy retransmits the message
to
the authentication server, which sends back a 401 Unauthorized. But it
seems the proxy closes the TLS connexion right after forwarding the
REGISTER, and doesn't receive the 401 message. The TLS handshake is OK, and
the client certificate is required (I didn't add the verification part yet).
The REGISTER message goes through TLS, and is received by the authentication
server. Then, the proxy sends a TLS alert (Close-notify), and after that
message, the authentication server sends back the 401, and the proxy ignores
that message.
> >
> > Could it be caused by a timeout? Is there a way to keep the TLS
connection opened?
It looks like a bug.
Could you try the attached patch and report back if it fixes the
problem?
Sorry, forgot to actually attach it. Here it is.
This patch fixed my problem. Now the proxy receives and retransmits the
401. Thank you very much!
Best regards,
Geoffroy
Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
ne pourra être recherchée quant au contenu de ce message. Bien que les
meilleurs efforts soient faits pour maintenir cette transmission exempte de
tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être recherchée pour tout dommage résultant d'un
virus transmis.
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its integrity
cannot be secured on the Internet, the Atos Origin group liability cannot be
triggered for the message content. Although the sender endeavours to
maintain a computer virus-free network, the sender does not warrant that
this transmission is virus-free and will not be liable for any damages
resulting from any virus transmitted.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users