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.coup...@atosorigin.com> wrote:
> Hello,
>
> -----Message d'origine-----
> De : Andrei Pelinescu-Onciul [mailto:and...@iptel.org]
> Envoyé : vendredi 20 août 2010 12:35
> À : Couprie Geoffroy
> Cc : sr-users@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 <and...@iptel.org>
> wrote:
> > > On Aug 20, 2010 at 10:18, Couprie Geoffroy <
> geoffroy.coup...@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@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
