[asterisk-bugs] [JIRA] (ASTERISK-29230) pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253344#comment-253344 ] 

Friendly Automation commented on ASTERISK-29230:
------------------------------------------------

Change 15292 merged by Friendly Automation:
Revert "res_pjsip_outbound_registration.c:  Use our own scheduler and other stuff"

[https://gerrit.asterisk.org/c/asterisk/+/15292|https://gerrit.asterisk.org/c/asterisk/+/15292]

> pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29230
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29230
>             Project: Asterisk
>          Issue Type: Security
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.1.0
>         Environment: CentOS 7, x86_64
>            Reporter: Michael Maier
>            Assignee: Unassigned
>            Severity: Blocker
>              Labels: fax, patch
>         Attachments: easybeltrace.png, forced-tcp-kill.tar.gz, no-abort.patch.tar.gz, obr_abort.patch
>
>
> If registration is impossible because of an error sending a packet, asterisk goes crazy and spams the log with > 6740(!) identical entries during 2 seconds like this one (-> no mediasec involved!):
> [2020-12-29 22:34:09] ERROR[4871] res_pjsip_outbound_registration.c: easybellPJSIP: Failed send registration to server 'sip:secure.sip.easybell.de' from client 'sip:[number]@secure.sip.easybell.de'
> There is a warning at the beginning of the spam attack:
> [2020-12-29 22:34:09] WARNING[3661] taskprocessor.c: The 'pjsip/outreg/easybellPJSIP-00000069' task processor queue reached 500 scheduled tasks.
> Another problem was at this time: The reRegistration started 14s too early (can't see any reason why)!  The first package seen in the pcap maps to the end of the timeline of the spam entries, means:
> - 6740 spam entries
> - first package seen in the pcap trace (written by asterisk)
> The account is a standard account, configured using tcp/tls.
> I consider this problem as a security problem, because it has the ability to kill a machine completely, depending on the machine's resources and the duration of the problem and the affected numbers in parallel (I could see the same problem some time later affecting 2(!) other numbers in parallel, but it luckily ended after about 0.1 seconds).



--
This message was sent by Atlassian JIRA
(v6.2#6252)