link_contact_to_impu() does not behave as intended - it will return immediately because ptr==contact . This will lead to a crash when current contact is always different than the previous. To prevent this, I set ptr to 0 as it points to a chunk of freed memory anyway. Removed call to unlink_contact_from_impu() as I believed is redundant and it leads to double free. This is an usual scenario and it happens with devices that reconnect on TCP , and they change the src port every time , and then the contact will be different.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/512
-- Commit Summary --
* ims_usrloc_scscf: fix link_contact_to_impu() (was crashing when maxcontact_behaviour == 2)
-- File Changes --
M modules/ims_usrloc_scscf/impurecord.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/512.patch https://github.com/kamailio/kamailio/pull/512.diff
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512
Ping to @jaybeepee, @richardgood and @ngvoice for comments or merging.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-185741874
Hi Jason,
Sure, send me the patch , I will test it.
Cheers, Dragos
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-185745995
Here you go Dragos. This is the full patch (from modules directory). There are a few changes across various modules, mostly improvements and fixes. So you can test them all. But let me know if the usrloc fixes fix your immediate issue.
Cheers Jason
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-185752447
+attachment
[kamailio-diff-dragos.zip](https://github.com/kamailio/kamailio/files/136361/kamailio-diff-dragos.zip)
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-185753719
Thank you Jason, looks good so far. I compiled and ran the patches on a test machine. I will keep on using the machine these days and report back.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-185779575
Hi Jason, I had no crash so far with your patches.
However, I observed some strange behaviour which I have not seen before applying the patches: 1. A timeout for a reply to REGISTER. A 200 OK reply is expected but nothing happens. This is with the P-cscf and it does not occur all the time. I restart the P and it starts replying again. I have not noticed anything peculiar in the logs which might explain this.
2. when I stop kamailio, there is a process hanging for 1 minute (cdp) . log : DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id pcscf.ims.mnc001.mcc001.3gppnetwork.org;2979852027;5 and hash 103 [it waits 1 minute and then shuts down: ] CRITICAL: <core> [main.c:637]: sig_alarm_abort(): shutdown timeout triggered, dying...
Regards, Dragos
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-187081646
Hey Dragos, thanks for the feedback.
Re. the REGISTER/200OK problem. Is there any chance you can send me a debug log and pcap? how easily recreatable?
Also can you confirm the following signalling so I understand your use case:
REG=> <=401 REG=> <=200 (At this stage the P-CSCF is not forwarding back to UE) - is that correct?
Cheers Jason
On Mon, 22 Feb 2016 at 11:09 Dragos Oancea notifications@github.com wrote:
Hi Jason, I had no crash so far with your patches.
However, I observed some strange behaviour which I have not seen before applying the patches:
- A timeout for a reply to REGISTER.
A 200 OK reply is expected but nothing happens. This is with the P-cscf and it does not occur all the time. I restart the P and it starts replying again. I have not noticed anything peculiar in the logs which might explain this.
- when I stop kamailio, there is a process hanging for 1 minute (cdp)
- . log : DEBUG: cdp [session.c:305]: cdp_get_session(): called get session
with id pcscf.ims.mnc001.mcc001.3gppnetwork.org;2979852027;5 and hash 103 [it waits 1 minute and then shuts down: ] CRITICAL: [main.c:637]: sig_alarm_abort(): shutdown timeout triggered, dying...
Regards, Dragos
—
Reply to this email directly or view it on GitHub https://github.com/kamailio/kamailio/pull/512#issuecomment-187081646. _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Jason,
Actually is more strange, and I do not exclude a diameter problem or an issue with my environment now. The P forwards the REGISTER to the I , I to the S , S sends back 401 back to the I , and then it arrives at the P , and then on UE. Then UE sends REGISTER again (challenge/response) but this second REGISTER does make it past the I , nothing comes back from the I , and then the P generates a 504 Server Time-out which is being sent to UE. Funny thing is that when I restart the P (and not the I !) , registration starts to function normally again. I could not reproduce today . I will send some logs from last week to your email if it's okay with you.
Dragos
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-187193160
Yes, that does sound strange. Yes, by all means, send to my email.
Cheers Jason
On Mon, 22 Feb 2016 at 16:13 Dragos Oancea notifications@github.com wrote:
Hi Jason,
Actually is more strange, and I do not exclude a diameter problem or an issue with my environment now. The P forwards the REGISTER to the I , I to the S , S sends back 401 back to the I , and then it arrives at the P , and then on UE. Then UE sends REGISTER again (challenge/response) but this second REGISTER does make it past the I , nothing comes back from the I , and then the P generates a 504 Server Time-out which is being sent to UE. Funny thing is that when I restart the P (and not the I !) , registration starts to function normally again. I could not reproduce today . I will send some logs from last week to your email if it's okay with you.
Dragos
—
Reply to this email directly or view it on GitHub https://github.com/kamailio/kamailio/pull/512#issuecomment-187193160. _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
What is the status for this PR? Still needs time or already handled with other commits?
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-196260208
Fixed with other commits. On 14 Mar 2016 1:02 PM, "Daniel-Constantin Mierla" notifications@github.com wrote:
What is the status for this PR? Still needs time or already handled with other commits?
— Reply to this email directly or view it on GitHub https://github.com/kamailio/kamailio/pull/512#issuecomment-196260208.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
OK, closing it.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#issuecomment-196273627
Closed #512.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/512#event-588574689