decoder.xml decodes asterisk IPv6 addresses with their square brackets

[martin9959]

Hi all,

asterisk (16.2.1~dfsg-1+deb10u1, Debian Buster) logs IPv4 and IPv6 like this.:

Jul 14 11:12:05 dsc asterisk[524]: NOTICE[798][C-000000f2]: chan_sip.c:26695 in handle_request_invite: Call from '' (145.239.11.166:33098) to extension '00441111111' rejected because extension not found in context 'default'.

Jul 16 02:45:55 dsc asterisk[524]: NOTICE[10568][C-00000109]: chan_sip.c:26695 in handle_request_invite: Call from '' ([2002:3ead:93e0::3ead:93e0]:65031) to extension '00048222222' rejected because extension not found in context 'default'.

this line of decoder.xml:

<decoder name="asterisk-denied3">
  <parent>asterisk</parent>
  <prematch_pcre2>^NOTICE\[\d+?\]\[[A-Za-z0-9@_-]+?\]: \S+ in \S+: Call from </prematch_pcre2>
  <pcre2 offset="after_prematch">^'\S*' \((\S+):(\d+?)\) to extension '(\S+)' rejected because extension not found in context '(\S+)'\.$</pcre2>
  <order>srcip, srcport, extra_data, extra_data</order>
</decoder>

detects IPv4 addresses fine, but IPv6 addresses keep their square brackets, like this:

**Phase 2: Completed decoding.
       decoder: 'asterisk'
       srcip: '[2002:3ead:93e0::3ead:93e0]'
       srcport: '65031'
       extra_data: '00048222222'
       extra_data: 'default'

This makes active response (ip6tables drop rule) fail (active response works fine with IPv6 addresses without their square brackets, though).

I don't see an obvious solution, probably one would need separate decoders for IPv4 and IPv6(?)

I assume that other decoders show similar problems if other services also log IPv6 addresses with square brackets (I don't have other examples at hand though). A proper solution might be an internal logic that would allow active response to use IPv6 addresses with and without brackets?