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@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@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@iptel.org> wrote:
> > On Aug 20, 2010 at 10:18, Couprie Geoffroy <geoffroy.couprie@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