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.
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?
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
|