[OpenSIPS-Devel] proto_ipsec, Refcounters and recent (breaking) changes

[Larry Laffer]

Hi,

after validating that the issue (2) works fine on 3.5.5 (so definitely not
OS specific), I've created a bug for this issue:
https://github.com/OpenSIPS/opensips/issues/3660

Thanks,
Larry

On Fri, May 30, 2025 at 5:59 PM Larry Laffer <larrylaffer130 at gmail.com>
wrote:

> One more update:
> I've double checked that the SO_REUSEPORT is properly set on the socket -
> so potentially not an OpenSIPS issue.
>
> It is currently running as a container based on Debian 11 - running on
> Docker / Ubuntu 24.04. Probably worth further investigating.
>
> Thanks,
> Carsten
>
>
>
> On Fri, May 30, 2025 at 4:44 PM Larry Laffer <larrylaffer130 at gmail.com>
> wrote:
>
>> Hi,
>>
>> Some more observations regarding (2):
>> Actually, I get the same error on the originating call-leg without any
>> IPSec involvement (apart from receiving on IPSec):
>>
>> May 30 16:38:48 [66] NOTICE:[VZ6EldiqV8qbeiuVeEgV31uO] Relaying INVITE to
>> tel:+12108302268/sip:orig at scscf.ims.mnc001.mcc001.3gppnetwork.org:6060;lr
>> (Socket tcp:10.0.0.6:5060)
>> May 30 16:38:48 [66] WARNING:core:get_send_socket: not listening on the
>> requested socket, no fork mode?
>>
>> In this case, the outbound socket is only forced to TCP in script:
>> $socket_out = "tcp:${PCSCF_IP}:5060";
>>
>> So potentially, the warning is not that critical, as the request gets
>> forwarded using TCP (non-IPSec) afterwards.
>>
>> However, it seems, the "reuse_port" parameter to the socket has currently
>> no effect:
>> socket=tcp:${PCSCF_IP}:5060 reuse_port
>>
>> It uses an ephemeral port regardless of the setting and it throws no
>> warning. This could be potentially the root cause...
>>
>> Thanks,
>> Larry
>>
>>
>> On Wed, May 28, 2025 at 6:04 PM Larry Laffer <larrylaffer130 at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> First of all thank you, for all thank you for your effort on making
>>> OpenSIPS an exciting project. I find especially the recent, IMS related
>>> extensions exciting. I really appreciate the approach of using
>>> standard/common modules for the IMS use-case rather than customized modules
>>> as in other projects.
>>>
>>> I would have loved to join you in Amsterdam for the Summit, but it did
>>> not work out this time for various reasons. I hope you are enjoying the
>>> event, I am following on YouTube.
>>>
>>> I've found a few topics with the "proto_ipsec" module:
>>>
>>> 1) The Refcounter of the "ipsec_ctx" is occasionally incorrect. I've
>>> noticed, that during the registration process it is finally at a counter of
>>> "1", which seems correct to me. However, since we save multiple entries in
>>> the location-DB (for the IMPI and the associated URI's). the usrloc
>>> callbacks are executed per location entry and each time the refcounter is
>>> decreased, finally ending in an invalid state. If the data is overwritten
>>> (since the shmem is free'd, this leads occasionally to a crash).
>>> I've temporarily fixed this in my config by only storing one entry in
>>> the location/usrloc DB (and storing the associated URIs in a cache), in
>>> which case the ref-counter counts correctly.
>>> (also created an issue here:
>>> https://github.com/OpenSIPS/opensips/issues/3657)
>>>
>>> 2) Recent changes break the proto_ipsec module?!??
>>>
>>> Each time, I attempt a call to a subscriber (Network => UE), the inbound
>>> call fails with the following warning:
>>>
>>> May 28 17:57:04 [54] NOTICE:[tiPeQZeN3tfdVrNtNvWXgN37] Relaying INVITE
>>> to sip:10.46.0.206:55805/<null> (Socket tcp:10.0.0.6:6100)
>>> May 28 17:57:04 [54] WARNING:core:get_send_socket: not listening on the
>>> requested socket, no fork mode?
>>> May 28 17:57:04 [54] CRITICAL:core:su_setport: unknown address family 0
>>>
>>> This only happens with latest master, If I go back to the version as of
>>> early may, everything is fine - in between there was the commit regarding
>>> the new "sockets_mgm" module. Maybe that broke something (@Razvan)?
>>>
>>> Thanks,
>>> Larry
>>>
>>> P.S.: Any update on my PR https://github.com/OpenSIPS/opensips/pull/3608?
>>> It's open since march... - no issues, just a small ping!
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20250602/4ca78f56/attachment.html>