[SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux

[Sean O'Donnell]

Hi Marius,

Thanks for the reply.  I found the patch in the 1.5 CVS branch.  

By the way, the 1.5.5 source tarball in /pub/kamailio/1.5.5/src was created
before this
patch was written, so the patch is not in there.  The tarball I created from the
1.5 branch
did have it.

Thanks again,

Sean O'Donnell
Senior Engineer
uReach Technologies, Inc.





---- On Mon, 14 Feb 2011, marius zbihlei (marius.zbihlei at 1and1.ro) wrote:

On 02/11/2011 09:14 PM, Sean O'Donnell wrote:
> Hi all,
>    
Hello Sean,
> I checked the GIT repository and noticed that there was a patch in forward.c
for
> this issue.  Looks like it was done 11/4/2010.  Two questions:
>
> 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ?
>    

Indeed, there is no reason. Actually I have cherry-picked the patches 
into the 3.1 branch (commit_notice 3.1 3ec1e9  and 9ef0a1e). Thanks for 
noticing.

> 2) Any reason I shouldn't apply that patck to my 1.5.4 release?
>    
The patch was already applied to the svn 1.5 branch (don't know if the 
latest 1.5.5 tar ball has it) but you can install it from svn and you 
can find it there (commit 6050)

Cheers
Marius
> Thanks,
> Sean O'Donnell
> Senior Engineer
> uReach Technologies, Inc.
>
>
>
>
>
> ---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell at ureach.com) wrote:
>
> Hi all,
>
> I just started deploying Kamailio release 1.5.4, and I think there's an issue
> with how Kamailio identifies an outgoing interface when mhomed is enabled
under
> Linux.
>
> I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a
> voicemail platform.  It
> runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and
is
> configured such that it listens on both interfaces.  One interface (public
> interface) handles traffic with the SBC, the other (private interface) handles
> with the VM platform. The 'mhomed' option is enabled.
>
> After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP
> packets coming out of the public interface.  After looking at some ngrep
> captures on that interface, I noticed that some packets had the source IP
> address of the private interface and also had Record-Route and Via headers for
> the private interface only - no headers for the public interface were there.
>
> Usually when I see the wrong source IP in a UDP packet, it's an issue with how
> routes are set up on the host.  However, I had our network engineer double
check
> them, and they seem fine (no ambiguous routes).  The fact that I captured
these
> messages on the public interface also indicates to me that the kernel is
routing
> the message correctly.  The missing Record-Route and Via for the public
> interface, however, lead me to believe that the proxy didn't correctly
identify
> the outgoing interface in the first place.
>
> After looking at the ChangeLog for 1.5.4, I noticed that the some new logic
was
> put in to improve performance when mhomed is enabled (r5971) in forward.c, and
I
> think this is the issue.
>
> As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio
determined
> the outgoing interface by creating a temporary UDP socket, invoking connect()
on
> the socket with the packet destination, then checking the source IP of the
> socket that the kernel assigned using getsockname().  After the source address
> was determined, the temp socket was closed closed. As of 1.5.4, this was
> modified to reuse the temporary socket and just re-invoking connect() with a
new
> destination address.
>
> The problem with the enhancement is that Linux (again, at least in the 2.6
> kernels I'm using)
> doesn't seem to rebind a new source address to the socket when connect() is
> called more than once on
> a UDP socket.  Instead, it keeps the original one, and thus the wrong
interface
> is assumed.
>
> I wrote a small program to confirm this - basically creates a UDP socket,
calls
> connect()/getsockname()
> multiple times using different destination addresses.  I ran it on several 2.6
> kernels, including
> Centos4.x and Centos5.  The result was always that the source address of the
> socket wasn't changed after the first connect(), regardless of the destination
> address.  The only way I could get it work as
> required was to first do a connect() using a zero'd out AF_UNSPEC address
before
> doing the
> connect() to the remote address.  I also ran it on Solaris and it worked.  Go
> figure.
>
> I've downloaded the latest stable release (3.1.2) but I think the issue is
still
> there, and I don't see
> anything in the user groups that addresses this.
>
> Any help would be appreciated.
>
> Thanks,
>
> Sean
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at 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 at 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 at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users