Snort mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Snort-devel Digest, Vol 55, Issue 11

From: Edri YUNIZAL <edriyunizal () iainbatusangkar ac id>
Date: Thu, 27 Jan 2022 06:05:28 +0700
Please Unsubscribe me.

Hormat saya,


Edri Yunizal

Pada tanggal Kam, 27 Jan 2022 02.07, <snort-devel-request () lists snort org>
menulis:


Send Snort-devel mailing list submissions to
        snort-devel () lists snort org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.snort.org/mailman/listinfo/snort-devel
or, via email, send a message with subject or body 'help' to
        snort-devel-request () lists snort org

You can reach the person managing the list at
        snort-devel-owner () lists snort org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Snort-devel digest..."


Today's Topics:

   1. Re: Snort 3.1.20: segfault when 16-core cpu, 2 interfaces and
      inspector appid (with stream/ssl/http) (Meridoff)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Jan 2022 22:03:55 +0300
From: Meridoff <oagvozd () gmail com>
To: "Steven Baigal (sbaigal)" <sbaigal () cisco com>
Cc: "snort-devel () lists snort org" <snort-devel () lists snort org>
Subject: Re: [Snort-devel] Snort 3.1.20: segfault when 16-core cpu, 2
        interfaces and inspector appid (with stream/ssl/http)
Message-ID:
        <
CAFfuDwynpmKGQa9KZx-BDsiKoL_QX71gjaq1FnGcs3n+HS18jg () mail gmail com>
Content-Type: text/plain; charset="utf-8"

Got it, thanks!
I've Tried "*--daq* afpacket *--daq-var fanout_type=hash --daq-dir
*/usr/lib/daq"
with -z in config only - it  doesn't help
Helps only if use -z in command line.

??, 25 ???. 2022 ?. ? 19:10, Steven Baigal (sbaigal) <sbaigal () cisco com>:


--daq-var always goes with ?daq, from command line:



*--daq* afpacket *--daq-var fanout_type=hash --daq-dir */usr/lib/daq



*From: *Meridoff <oagvozd () gmail com>
*Date: *Tuesday, January 25, 2022 at 7:18 AM
*To: *Oleksii Shumeiko -X (oshumeik - SOFTSERVE INC at Cisco) <
oshumeik () cisco com>
*Cc: *Steven Baigal (sbaigal) <sbaigal () cisco com>,
snort-devel () lists snort org <snort-devel () lists snort org>
*Subject: *Re: [Snort-devel] Snort 3.1.20: segfault when 16-core cpu, 2
interfaces and inspector appid (with stream/ssl/http)

Thanks , I've tried that.



Results:



1. threads.cpuset  (as suggested before by Steven) -didn't help

2. daq.modules = { { name = 'afpacket', mode='passive' , variables = {
'fanout_type=hash'} } }  - doesn't help

NB:* Specifing --daq-var fanout_type=hash from command line is

impossible:*


Jan 25 14:19:09 srv snort[25631]: ERROR: can't set --daq-var
fanout_type=hash

Jan 25 14:19:09 srv snort[25631]: ERROR: usage: --daq-var <name=value>
specify extra DAQ configuration variable
Jan 25 14:19:09 srv snort[25631]: FATAL ERROR: see prior 2 errors



3. It is very unusual ) , but "-z 0" from the command line - *HELPED*!
All works *OK !*











??, 25 ???. 2022 ?. ? 12:14, Oleksii Shumeiko -X (oshumeik - SOFTSERVE

INC

at Cisco) <oshumeik () cisco com>:

Hi



Another workaround you could try is to remove ["-z"]=0 from the lua file,
and specify the number of threads via the command-line option: snort -c
snort.lua -z=0 (or whatever number you need).



Regards,

Alexey



On 24 Jan 2022, at 22:53, Meridoff via Snort-devel <
snort-devel () lists snort org> wrote:



Hello, I've found minimal config that leads to segfaults (there are 2
different) and got backtraces.



1) I use a 16-core cpu Intel(R) Xeon(R) CPU E5-2650

2) A lot of memory: 16GB

3) Segfault when snort starts exists for z=0 (16 threads) and for z=15

and

14 too. For z = 13 and less it disappeared and all OK.

*4) If I remove 1 *of 3 the inspectors from config - segfault doesn't
appear in 1 one minute (may be will appear later, but I did not wait) .

*5) If all 3 inspectors* exist: segfault appears just immediately (in 1
second) after a snort run.



==========Snort starts add here is daemon.log (for z=14):



Jan 24 23:38:14 srv snort[24616]:
--------------------------------------------------
Jan 24 23:38:14 srv snort[24616]: o")~   Snort++ 3.1.20.0
Jan 24 23:38:14 srv snort[24616]:
--------------------------------------------------
Jan 24 23:38:14 srv snort[24616]: Loading /etc/snort/config:
Jan 24 23:38:14 srv snort[24616]: #011host_cache
Jan 24 23:38:14 srv snort[24616]: #011so_proxy
Jan 24 23:38:14 srv snort[24616]: #011stream_tcp
Jan 24 23:38:14 srv snort[24616]: #011packets
Jan 24 23:38:14 srv snort[24616]: #011stream_udp
Jan 24 23:38:14 srv snort[24616]: #011daq
Jan 24 23:38:14 srv snort[24616]: #011search_engine
Jan 24 23:38:14 srv snort[24616]: #011alerts

Jan 24 23:38:14 srv snort[24616]: #011snort
Jan 24 23:38:14 srv snort[24616]: #011binder
Jan 24 23:38:14 srv snort[24616]: #011stream
Jan 24 23:38:14 srv snort[24616]: #011trace
Jan 24 23:38:14 srv snort[24616]: #011wizard
Jan 24 23:38:14 srv snort[24616]: #011ips
Jan 24 23:38:14 srv snort[24616]: #011host_tracker
Jan 24 23:38:14 srv snort[24616]: #011process
Jan 24 23:38:14 srv snort[24616]: #011classifications
Jan 24 23:38:14 srv snort[24616]: #011active
Jan 24 23:38:14 srv snort[24616]: #011decode
Jan 24 23:38:14 srv snort[24616]: #011alert_fast
Jan 24 23:38:14 srv snort[24616]: #011references
Jan 24 23:38:14 srv snort[24616]: #011output
Jan 24 23:38:14 srv snort[24616]: #011hosts
Jan 24 23:38:14 srv snort[24616]: #011network
Jan 24 23:38:14 srv snort[24616]: Finished /etc/snort/config:
Jan 24 23:38:14 srv snort[24616]:
--------------------------------------------------
Jan 24 23:38:14 srv snort[24616]: afpacket DAQ configured to passive.
Jan 24 23:38:14 srv snort[24616]: initializing daemon mode
Jan 24 23:38:14 srv snort[24616]: child process is 24619
Jan 24 23:38:14 srv snort[24619]: Commencing packet processing
Jan 24 23:38:15 srv snort[24619]: ++ [0] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [1] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [2] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [3] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [4] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [5] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [6] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [7] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [8] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [9] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [10] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [11] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [12] eth0
Jan 24 23:38:15 srv snort[24619]: ++ [13] eth0
Jan 24 23:38:15 srv snort[24619]: Chroot directory = /
Jan 24 23:38:15 srv snort[24619]: Writing PID "24619" to file
"/var/log/snort/snort.pid"



6) Kernel log when segfault:

Jan 24 23:38:14 srv kernel: [61088.748755] device eth0 entered

promiscuous

mode
Jan 24 23:38:16 srv kernel: [61090.649729] snort3[24646]: segfault at
201aaef6a ip 00000000004abeac sp 00007fc8c1fc3e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649734] snort3[24649]: segfault at
201aaef76 ip 00000000004abeac sp 00007fc8abfc7e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649739] snort3[24648]: segfault at
201aaef72 ip 00000000004abeac sp 00007fc8c0fc1e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649744] snort3[24645]: segfault at
201aaef66 ip 00000000004abeac sp 00007fc8c27c4e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649749] snort3[24642]: segfault at
201aaef5a ip 00000000004abeac sp 00007fc8c3fc7e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649752] snort3[24638]: segfault at
201aaef4a ip 00000000004abeac sp 00007fc8e226be58 error 6
Jan 24 23:38:16 srv kernel: [61090.649756] snort3[24641]: segfault at
201aaef56 ip 00000000004abeac sp 00007fc8e0a68e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649760]
Jan 24 23:38:16 srv kernel: [61090.649763] snort3[24637]: segfault at
201aaef46 ip 00000000004abeac sp 00007fc8e2a6ce58 error 6
Jan 24 23:38:16 srv kernel: [61090.649767] snort3[24640]: segfault at
201aaef52 ip 00000000004abeac sp 00007fc8e1269e58 error 6
Jan 24 23:38:16 srv kernel: [61090.649770] snort3[24636]: segfault at
201aaef42 ip 00000000004abeac sp 00007fc8e326de58 error 6
Jan 24 23:38:16 srv kernel: [61090.649822] Code: e1 48 89 ea 48 89 df 5b
89 c6 5d 41 5c 41 ff e0 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 64 8b

14

25 d8 9c fd ff 48 8b 47 10 <f0> 83 04 90 01 c3 66 66 2e 0f 1f 84 00 00 00
00 00 0f 1f 00 64 8b
....
...
Jan 24 23:38:19 srv kernel: [61094.236784] device eth0 left promiscuous
mode



Now config and backtrace:



*1. config *(I've found for these 3 inspectors  and 16 processing threads
and at least 1 interface with daq mode ids)

HOME_NET = "any"
EXTERNAL_NET = "any"
dofile("/etc/snort/snort_defaults.lua")
dofile("/etc/snort/file_magic.lua")
references = default_references
classifications = default_classifications
output = { logdir="/var/log/snort/", show_year=true}
process = { daemon=true, chroot="/" }
snort = { ["-e"] = true, ["-M"] = true, ["--create-pidfile"] = true,
["-z"] = 0, ["--id-zero"] = true }
ips = { mode = "tap", enable_builtin_rules = false, variables =
default_variables }
wizard = default_wizard
alert_fast = {file=true}
stream={}
stream_tcp={}
stream_udp={}
binder={}
binder[1]={ use = { type = "wizard" } }
ips.mode="tap"
daq = { module_dirs = { "/usr/lib/daq" } }
daq.inputs = {'eth0'}
daq.modules = { { name = 'afpacket', mode='passive' } }



*If I remove 1 *of the inspectors - segfault doesn't appear in 1 one
minute (may be will appear later, but I did not wait) .

*If all 3 inspectors* exist: segfault appears just immediately (in 1
second) after a snort run.



*2. Backtrace #1* (for 1st segfault - which is successfully can be
replayed):



(gdb) bt(gdb) bt
#0  [34m0x00000000004abeac[m in [33mstd::__atomic_base<unsigned
int>::operator++[m ([36mthis[m=[2m<error reading variable: Asked for
position 0 of stack, stack only has 0 el
ements on it.>[m) at [32m/usr/include/c++/8.4.0/bits/atomic_base.h[m:295
#1  [33msnort::Inspector::add_ref[m ([36mthis[m=0x1bc4720) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/framework/
inspector.cc[m:117
#2  [34m0x00000000005f484e[m in [33msnort::Flow::set_client[m
([36mthis[m=0x7f37826604b0, [36mins[m=<optimized out>) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7a
c727a7373fb3/src/flow/flow.h[m:284
#3  [33mStuff::apply_session[m ([36mthis[m=0x7f37a77c6ee0,

[36mflow[m=...)

at


[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/network_inspectors/binder

/binder.cc[m:424
#0  [34m0x00000000004abeac[m in [33mstd::__atomic_base<unsigned
int>::operator++[m ([36mthis[m=[2m<error reading variable: Asked for
position 0 of stack, stack only has 0 el
ements on it.>[m) at [32m/usr/include/c++/8.4.0/bits/atomic_base.h[m:295
#1  [33msnort::Inspector::add_ref[m ([36mthis[m=0x1bc4720) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/framework/
inspector.cc[m:117
#2  [34m0x00000000005f484e[m in [33msnort::Flow::set_client[m
([36mthis[m=0x7f37826604b0, [36mins[m=<optimized out>) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7a
c727a7373fb3/src/flow/flow.h[m:284
#3  [33mStuff::apply_session[m ([36mthis[m=0x7f37a77c6ee0,

[36mflow[m=...)

at


[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/network_inspectors/binder

/binder.cc[m:424

#4  [34m0x00000000005f5412[m in [33mBinder::apply[m

([36mthis[m=<optimized

out>, [36mstuff[m=..., [36mflow[m=...) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac72
7a7373fb3/src/network_inspectors/binder/binder.cc[m:979
#5  [33mBinder::apply[m ([36mthis[m=<optimized out>, [36mflow[m=...,
[36mstuff[m=...) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/network_inspec
tors/binder/binder.cc[m:973
#6  [34m0x00000000005f557f[m in [33mBinder::handle_flow_setup[m
([36mthis[m=0x1b905d0, [36mflow[m=..., [36mstandby[m=<optimized out>) at
[32mtmp/snort-5f7ab9ead16
2c4766f3d8f479a7ac727a7373fb3/src/network_inspectors/binder/binder.cc
[m:730
#7  [34m0x00000000004aabb7[m in [33msnort::DataBus::_publish[m
([36mthis[m=<optimized out>, [36mkey[m=<optimized out>, [36me[m=...,
[36mf[m=0x7f37826604b0) at [32mtmp/
snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/framework/data_bus.cc
[m:186
#8  [34m0x00000000004aac3f[m in [33msnort::DataBus::publish[m
([36mkey[m=<optimized out>, [36me[m=..., [36mf[m=<optimized out>) at
[32mtmp/snort-5f7ab9ead162c4766
f3d8f479a7ac727a7373fb3/src/framework/data_bus.cc[m:127
#9  [34m0x00000000004aac96[m in [33msnort::DataBus::publish[m
([36mkey=key@entry[m=0x6af8cd "flow.state_setup", [36mp=p@entry

[m=0x7f37823dab70,

[36mf[m=<optimized out>, [36m
f@entry[m=0x0) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/framework/
data_bus.cc[m:141
#10 [34m0x00000000004a67e4[m in [33mFlowControl::process[m
([36mthis[m=0x7f378255d5d0, [36mflow[m=0x7f37826604b0,
[36mp[m=0x7f37823dab70) at [32mtmp/snort-5f7ab9e
ad162c4766f3d8f479a7ac727a7373fb3/src/flow/flow_control.cc[m:455
#11 [34m0x00000000004a6cd7[m in [33mFlowControl::process[m
([36mthis[m=0x7f378255d5d0, [36mtype=type@entry[m=PktType::TCP,
[36mp=p@entry[m=0x7f37823dab70, [36mnew_flow=new_f
low@entry[m=0x0) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/flow/
flow_control.cc[m:404
#12 [34m0x0000000000565a8b[m in [33mStreamBase::eval[m
([36mthis[m=<optimized out>, [36mp[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373
fb3/src/stream/base/stream_base.cc[m:268
#13 [34m0x000000000050fad5[m in [33mexecute<false>[m ([36mprobe[m=false,
[36mnum[m=1, [36mprep[m=0x1b6b4a0, [36mp[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c
4766f3d8f479a7ac727a7373fb3/src/framework/decode_data.h[m:146
#14 [33msnort::InspectorManager::internal_execute<false>[m ([36mp=p@entry

[m=0x7f37823dab70)

at [32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/managers
/inspector_manager.cc[m:1547
#15 [34m0x000000000050c6d9[m in [33msnort::InspectorManager::execute[m
([36mp=p@entry[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/
src/managers/inspector_manager.cc[m:1526
#16 [34m0x0000000000479c7c[m in [33msnort::DetectionEngine::inspect[m
([36mp[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/detec
tion/detection_engine.cc[m:615
#17 [34m0x00000000004eeb11[m in [33mprocess_packet[m
([36mp[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/
analyzer.cc[m:205
#18 [33mprocess_packet[m ([36mp[m=0x7f37823dab70) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/
analyzer.cc[m:189
#19 [34m0x00000000004efa1d[m in [33mAnalyzer::process_daq_pkt_msg[m
([36mthis=this@entry[m=0x24c3450, [36mmsg=msg@entry[m=0x2461840,
[36mretry=retry@entry[m=false) at [32mbu
ildroot/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/
analyzer.cc[m:391
#20 [34m0x00000000004efc17[m in [33mAnalyzer::process_daq_msg[m
([36mthis[m=0x24c3450, [36mmsg[m=0x2461840, [36mretry[m=<optimized out>)

at

[32mtmp/snort-5f7ab9ea
d162c4766f3d8f479a7ac727a7373fb3/src/main/analyzer.cc[m:410
#21 [34m0x00000000004f0465[m in [33mAnalyzer::process_messages[m
([36mthis[m=0x24c3450) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/analyze
r.cc[m:850
#22 [34m0x00000000004f06fd[m in [33mAnalyzer::analyze[m
([36mthis=this@entry[m=0x24c3450) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/analy
zer.cc[m:882
#23 [34m0x00000000004f0821[m in [33mAnalyzer::operator()[m
([36mthis[m=0x24c3450, [36mps[m=0x271d4c0, [36mrun_num[m=<optimized out>)
at [32mtmp/snort-5f7ab9ead162
c4766f3d8f479a7ac727a7373fb3/src/main/analyzer.cc[m:728
#24 [34m0x00007f3840aebb1f[m in [33m??[m ()
#25 [34m0x0000000000000000[m in [33m??[m ()



*2. Backtrace #2* (for 2nd segfault - it is very rare , and difficult to
replay  but I post it too):



#0  [34m0x000000000051dd04[m in

[33msnort::InspectorManager::thread_init[m

([36msc[m=0x2a694e0) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/managers/
inspector_manager.cc[m:901
#1  [34m0x0000000000500b64[m in [33mAnalyzer::init_unprivileged[m
([36mthis[m=0x31899c0) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/
analyzer.cc[m:577
#2  [34m0x0000000000500f50[m in
[33mAnalyzer::add_command_to_uncompleted_queue[m ([36mthis[m=0x31899c0,
[36maci[m=0x3189af0, [36macs[m=0x449900 <__pthread_key_create@plt>) a
t [32m/usr/include/c++/8.4.0/bits/stl_list.h[m:416
#3  [34m0x0000000000501dd2[m in [33m__gthread_mutex_lock[m
([36m__mutex[m=0x31899c0) at
[32m/usr/include/c++/8.4.0/x86_64-tmp-linux-gnu/bits/gthr-default.h[m:748
#4  [33mstd::mutex::lock[m ([36mthis[m=0x2ac2fd0) at
[32m/usr/include/c++/8.4.0/bits/std_mutex.h[m:103
#5  [33mAnalyzer::handle_command[m ([36mthis[m=0x2ac2ea0) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/
analyzer.cc[m:760
#6  [34m0x000000000050237c[m in [33mAnalyzer::process_messages[m
([36mthis[m=<optimized out>) at
[32mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/a
nalyzer.cc[m:864
#7  [34m0x00000000031899c0[m in [33m??[m ()
#8  [34m0x00000000005024f1[m in [33mAnalyzer::operator()[m
([36mthis[m=0x361b690, [36mps[m=0x50237c
<Analyzer::process_messages()+748>, [36mrun_num[m=<optimized out>) at [32
mtmp/snort-5f7ab9ead162c4766f3d8f479a7ac727a7373fb3/src/main/analyzer.cc
[m:711
#9  [34m0x00007f11bb7f9b1f[m in [33m??[m ()
#10 [34m0x0000000000000000[m in [33m??[m ()







??, 20 ???. 2022 ?. ? 18:15, Steven Baigal (sbaigal) <sbaigal () cisco com
:

You are right, perf_monitor.base = false, will disable reporting base
stats.

By the way, you can change the process affinity with process.thread
configuration, and see if it can make any differences.

Example can be found from here:

https://github.com/snort3/snort3_demo/blob/master/perf/3.0/common.lua



*From: *Meridoff <oagvozd () gmail com>
*Date: *Thursday, January 20, 2022 at 5:36 AM
*To: *Steven Baigal (sbaigal) <sbaigal () cisco com>
*Cc: *snort-devel () lists snort org <snort-devel () lists snort org>
*Subject: *Re: [Snort-devel] Snort 3.1.20: segfault when 16-core cpu, 2
interfaces and inspector appid (with stream/ssl/http)

Sure, will do that.

But perfmon  is disabled,and do nothing, because perfmon.base=false.

It doesn't collect statistics with such setup, isn't it?



??, 19 ???. 2022 ?., 19:50 Steven Baigal (sbaigal) <sbaigal () cisco com>:

Thanks for reporting the issue, could you share the backtrace from the
crash?

Also, I noticed you have enabled perf_monitor, please specify which peg
count from what module to limit output size, otherwise snort will try to
collect all stats from all modules, when appid is enabled, the peg counts
for each collection will exceed 3k+ for every thread. Try to comment out
perf_monitor from your configuration to see if it will help.



Steven B.



*From: *Snort-devel <snort-devel-bounces () lists snort org> on behalf of
Meridoff via Snort-devel <snort-devel () lists snort org>
*Date: *Wednesday, January 19, 2022 at 11:16 AM
*To: *snort-devel () lists snort org <snort-devel () lists snort org>
*Subject: *[Snort-devel] Snort 3.1.20: segfault when 16-core cpu, 2
interfaces and inspector appid (with stream/ssl/http)

Hello, I have snort 3.1.20 running on 16-core CPU with 2 interfaces.

Also good traffic goes through snort, and appid detect applications from
it (as shown below in Statistics)

And  snort randomly does segfalts, also segfault and even GP occurred

when

snort disabled.

If I configure number of threads to 8 or 4 or 2 - then all *OK*, no
segfaults and snort runs OK.



I think it is only when a lot of CPUs used. And number of ifaces
significantly less then number of threads.



Segfaults are in

1. During running: *Inspector:add_ref() *function in  *lock add dword ptr
[rax+rdx*4], 1*

2. During stopping by sending SIGTERM: InspectorManager:thread_stop()

after* get_thread_local_plugin(). *I think it in the* if (
phg.instance_initialized ) ,* when *phg* is NULL or smth..



*My config is next:*

(removed dofiles (magic and defaults))

HOME_NET = "any"

EXTERNAL_NET = "any"

dofile("/etc/snort/snort_defaults.lua")

dofile(""/etc/snort/file_magic.lua")

references = default_references
classifications = default_classifications
output = { logdir="/var/log/snort/", show_year=true}
process = { daemon=true, chroot="/" }
snort = { ["-e"] = true, ["-M"] = true, ["--create-pidfile"] = true,
        ["-z"] = 0, ["--id-zero"] = true}
ips = { mode = "tap", enable_builtin_rules = false, variables =
default_variables }
perf_monitor = { base = false, format = "text",

max_file_size=100999999999

}
alerts = { order ="pass reset block drop alert log" }
binder={

{use = { type = "ssl" }, when = { service = "ssl" }},

{ use = { type = "http_inspect" }, when = { service = "http" } },

{ use = { type = "wizard" } }

}
wizard = default_wizard
stream={}
stream_tcp={}
stream_udp={}
http_inspect={}
ssl={}
appid = { rna_conf_path = "/tmp/rna.conf",  app_stats_rollover_size=0,
app_detector_dir = "/var/cache/snort/openappid/" }

ips.mode="tap"
daq = { module_dirs = { "/usr/lib/daq" } }
daq.inputs = {'eth0','eth2'}
daq.modules = { { name = 'afpacket', mode='passive' } }
daq.modules[1].variables = { 'debug'}



=====

Content of /tmp/rna.conf:



config Analyze 0.0.0.0/0 -1



=========================

*Some statistics:*



--------------------------------------------------
Packet Statistics
--------------------------------------------------
daq
                 received: 10956
                 analyzed: 10940
              outstanding: 16
                    allow: 10940
                 rx_bytes: 3722585
--------------------------------------------------
codec
                    total: 10940       #011(100.000%)
                    other: 39          #011(  0.356%)
                 discards: 3762        #011( 34.388%)
                      arp: 87          #011(  0.795%)
                      eth: 10940       #011(100.000%)
                    icmp4: 74          #011(  0.676%)
                    icmp6: 258         #011(  2.358%)
                     ipv4: 10720       #011( 97.989%)
                     ipv6: 321         #011(  2.934%)
            ipv6_hop_opts: 217         #011(  1.984%)
                      llc: 8           #011(  0.073%)
                      tcp: 8201        #011( 74.963%)
                   teredo: 32          #011(  0.293%)
                      udp: 1717        #011( 15.695%)



Appid Statistics

--------------------------------------------------
detected apps and services
              Application: Services   Clients    Users      Payloads
Misc       Referred
                   dhcpv6: 14         0          0          0          0
       0
                      dns: 0          28         0          0          0
       0
                     http: 3          0          0          0          0
       0
                      ntp: 24         0          0          0          0
       0
                    https: 21         0          0          0          0
       0
                     mdns: 14         0          0          0          0
       0
                 telegram: 0          108        0          0          0
       0
           dns_over_https: 129        0          0          0          0
       0
                  unknown: 755        0          0          24         0
       0

_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.snort.org/pipermail/snort-devel/attachments/20220126/ccbaaa23/attachment.htm




------------------------------

Subject: Digest Footer

_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel


------------------------------

End of Snort-devel Digest, Vol 55, Issue 11
*******************************************


_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!
Previous By Date Next
Previous By Thread Next

Current thread: