[reSIProcate] [reSIProcate-users] TCP/TLS question/problem

[Scott Godin]

Thanks Dan.  This looks good to me - just forwarding to the list for
more opinions.

 

Scott

 

From: Dan Tifrea [mailto:dan.tifrea at gmail.com] 
Sent: Tuesday, October 16, 2007 4:10 PM
To: Byron Campen
Cc: Scott Godin
Subject: Re: [reSIProcate-users] TCP/TLS question/problem

 

Byron, Scott

Thanks for your support. I took a look at what might be causing the
above mentioned problem. I found out that the
TcpBaseConnection::processAllWriteRequests(...) method doesn't do a
bind() when it creates a new connection. As such, the OS chooses the
source address from one of the physical interfaces available on the
system. Adding the following code in the above method seems to fix my
problem.  Please feel free to use it if you'd like to fix this issue. 

Best regards,
Dan Tifrea

         assert(sock != INVALID_SOCKET);
----begin code ----
         int port = mTuple.getPort(); // save current port
         mTuple.setPort(0);
         DebugLog (<< "Binding to " << Tuple::inet_ntop(mTuple) << ":"
<< mTuple.getPort());
         if ( ::bind( sock, &mTuple.getMutableSockaddr(),
mTuple.length()) == SOCKET_ERROR )
         {
            int e = getErrno();
            if ( e == EADDRINUSE )
            { 
               error(e);
               ErrLog (<< mTuple << " already in use ");
            }
            else
            {
               error(e);
               ErrLog (<< "Could not bind to " << mTuple); 

            }
         }
         mTuple.setPort(port); // restore port

         makeSocketNonBlocking(sock);

         DebugLog (<<"Opening new connection to " << data->destination);

         const sockaddr& servaddr = data->destination.getSockaddr();
----end code ----
         int e = connect( sock, &servaddr, data->destination.length() );

On 10/15/07, Byron Campen <bcampen at estacado.net> wrote: 

          Keep in mind that resip uses the linux socket API to send
stuff; it has no control over what is placed in the IP header. 

 

Best regards,

Byron Campen





The platform is RedHat Linux ES release 4. A simple TCP test program
showed no problems binding to a virtual IP address. 
The issue that the end user has is related to internal network
provisioning (firewall, public/private IP address management). 

Best regards,
Dan Tifrea

On 10/12/07, Byron Campen <bcampen at estacado.net> wrote:

          Sounds like a platform issue to me. Why is this hurting you?

 

Best regards,

Byron Campen





Hi all,

I have noticed the following TCP/TLS behavior. I have a physical
interface (eth0, ip address 192.168.17.144 <http://192.168.17.144/> ). I
create a virtual ip address  (eth0:1, ip address 192.168.17.155
<http://192.168.17.155/> ). I start the resiprocate app and add a TCP
transport for the virtual 192.168.17.155 <http://192.168.17.155/>
interface.  I send  an INVITE to a remote destination.  The problem is
that the INVITE message received on the remote has the IP frame src
address 192.168.17.144 <http://192.168.17.144/>  (and not 192.168.17.155
<http://192.168.17.155/> ). Note that all the resiprocate log messages
as well as the Via header indicate the correct ip address 192.168.17.155
<http://192.168.17.155/> . Any thoughts?
I may provide logs and/or wireshark capture if needed.

Best regards,
Dan Tifrea

_______________________________________________

resiprocate-users mailing list

resiprocate-users at resiprocate.org 

List Archive: http://resiprocate.org/archive/resiprocate-users/ 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20071016/1d1d2b6f/attachment.htm>