<div dir="ltr">Hi,<div>I've been playing with SO_REUSEPORT (included in kernel since 3.9) and Kamailio quite successfully.</div><div>I have a branch for this in my personal fork (<a href="https://github.com/grumvalski/kamailio/tree/tcp_reuseport">https://github.com/grumvalski/kamailio/tree/tcp_reuseport</a>) that I've been planning to submit as a PR since a while.</div><div>If you agree I can do it to start the discussion.</div><div><br></div><div>Regards,</div><div><br></div><div>Federico</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:36 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I will try to follow up with more on this discussion after I get the<br>
time to check the resources at the links you mentioned. I know that<br>
forcing a source port for a tcp connection was not reliable, but things<br>
may have changed with newer versions of kernels.<br>
<br>
Cheers,<br>
Daniel<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 05/12/2016 14:01, Daniel Pocock wrote:<br>
><br>
> RFC 3261 doesn't appear to require anything more than the default random<br>
> selection of source port for transports like TCP and TLS<br>
><br>
> Section 18[1] even appears to anticipate that two proxies communicating<br>
> over reliable transports may have two different connections open at the<br>
> same time, one for requests initiated in each direction.<br>
><br>
> However, I've seen a couple of situations where using the listening port<br>
> as the source port would be beneficial:<br>
><br>
> - peer has buggy implementation that tries to connect back to source<br>
> port / rport (which should only happen for unreliable transports),<br>
> observed in reSIProcate[2]<br>
><br>
> - firewall policy is particularly strict and prefers or even expects<br>
> specific source ports to be used<br>
><br>
> - potentially halves the number of sockets / FDs required (better use of<br>
> system resources)<br>
><br>
><br>
> It is not hard to configure a TCP (or TLS) client socket to use a<br>
> specific[3] source port, although as that example[3] demonstrates, there<br>
> could be situations where a socket is not fully closed and a new one<br>
> can't be opened immediately for the same source/dest port combination.<br>
> That type of issue doesn't arise for randomly selected source ports.<br>
><br>
><br>
> Has anybody else tried setting a fixed source port for TCP/TLS<br>
> connections and can you share any observations about this for better or<br>
> worse?<br>
><br>
> Has anybody seen similar behaviour to the bug[2] in other SIP<br>
> implementations?<br>
><br>
> We are thinking about implementing this as an optional feature in<br>
> reSIProcate, partly to help people mitigate the impact of peers who have<br>
> the bug #137.<br>
><br>
> Regards,<br>
><br>
> Daniel<br>
><br>
><br>
> 1. <a href="https://tools.ietf.org/html/rfc3261#section-18" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>rfc3261#section-18</a><br>
><br>
> 2. <a href="https://www.resiprocate.org/bugzilla/show_bug.cgi?id=137" rel="noreferrer" target="_blank">https://www.resiprocate.org/<wbr>bugzilla/show_bug.cgi?id=137</a><br>
><br>
> 3.<br>
> <a href="http://stackoverflow.com/questions/2605182/when-binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reuse" rel="noreferrer" target="_blank">http://stackoverflow.com/<wbr>questions/2605182/when-<wbr>binding-a-client-tcp-socket-<wbr>to-a-specific-local-port-with-<wbr>winsock-so-reuse</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> sr-dev mailing list<br>
> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>dev</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Daniel-Constantin Mierla<br>
<a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
Kamailio World Conference - May 8-10, 2017 - <a href="http://www.kamailioworld.com" rel="noreferrer" target="_blank">www.kamailioworld.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>