Date: Fri, 03 Sep 2021 15:31:25 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 258087] net/asterisk: 18.6.0 is crashing silently Message-ID: <bug-258087-7788-BeMuxNVvHB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-258087-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-258087-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258087 --- Comment #2 from O. Hartmann <ohartmann@walstatt.org> --- (In reply to Oljas Kuzembaev from comment #1) Well, I do not have an clue at all. But I thing there is an issue with the network. My router is utilizig mpd5 as pppoe service. To force a change of = the IPv4 given by the provider, I restart the service mpd5 via cron at a specif= ic time and as I wrote earlier in the PR, that is also in almost all cases the time when the last log entry of asterisk was registered. This time I had to restart mpd5 due to some development on my dynDNS scripts and, voila!, asterisk raise CPU usage shortly after mpd5 has been restarted= and crashes afterwards with a SIGNAL 11. I use IPFw as one and only IP filtering system. Now I try to restart also I= PFW with the mpd5 link-up script when IPS are going to change and see what's happening to asterisk. By the way: my asterisk configuration uses the symbolic name (therefore dyn= DNS) and I also use a special setup of dns/bind916. Means: I resolve the ISP's S= IP proxy/SIP server with the DNS given by the ISP and all others with "free and open" resolver. This kind of setup seemed to force some trouble in the past, although I can't be specific on that. This is the crash scenario when I'm forcing the change of address. I have n= ot investigated so far whether asterisk dies the same way when the ISP is chan= ging the outbound addresses. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258087-7788-BeMuxNVvHB>