< Previous by Date Date Index Next by Date >
  Thread Index  

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


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

 

Scott

 

From: Dan Tifrea [mailto:dan.tifrea@xxxxxxxxx]
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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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 ). I create a virtual ip address  (eth0:1, ip address 192.168.17.155). I start the resiprocate app and add a TCP transport for the virtual 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 (and not 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. Any thoughts?
I may provide logs and/or wireshark capture if needed.

Best regards,
Dan Tifrea

_______________________________________________

resiprocate-users mailing list