Suricata6.0.0-beta1 on OpenWrt Illegal Instruction error

Help
21 
grommish@norwits:~/openwrt$ ./scripts/remote-gdb 192.168.1.1:9000 build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/src/suricata
Using target mips64_octeon3_64 (musl, )
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=mips64-openwrt-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/home/grommish/openwrt/build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/src/suricata": not in executable format: file format not recognized
Reading symbols from /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata...
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/grommish/openwrt/staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata.
Use `info auto-load python-scripts [REGEXP]' to list them.
0x000000fff7f58c00 in _dlstart () from /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1
(gdb) set remote exec-file /usr/bin/suricata
(gdb) set args -c /etc/suricata/suricata.yaml -i eth0
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/grommish/openwrt/staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata -c /etc/suricata/suricata.yaml -i eth0

Program received signal SIGILL, Illegal instruction.
0x0000000120d7d87c in decfloat (f=0xffffffd670, c=49, bits=53, emin=-1074, sign=1, pok=1) at src/internal/floatscan.c:67
67	src/internal/floatscan.c: No such file or directory.
(gdb) x/i $pc
=> 0x120d7d87c <decfloat+60>:	sdc1	$f24,8376(sp)
(gdb)

Someone suggested running the x/i $pc in gdb to see if it shows anyting interesting. That was the result.

22 
grommish@norwits:~/openwrt$ ./scripts/remote-gdb 192.168.1.1:9000 build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/src/suricata
Using target mips64_octeon3_64 (musl, )
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=mips64-openwrt-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/home/grommish/openwrt/build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/src/suricata": not in executable format: file format not recognized
Reading symbols from /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata...
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/grommish/openwrt/staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata.
Use `info auto-load python-scripts [REGEXP]' to list them.
0x000000fff7f58c00 in _dlstart () from /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1
(gdb) set remote exec-file /usr/bin/suricata
(gdb) set args -v -c /etc/suricata/suricata.yaml -i eth0
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/grommish/openwrt/staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/bin/suricata -v -c /etc/suricata/suricata.yaml -i eth0

Program received signal SIGILL, Illegal instruction.
0x0000000120ea19cc in decfloat (f=0xffffffd7a0, c=49, bits=53, emin=-1074, sign=1, pok=1) at src/internal/floatscan.c:67
67	src/internal/floatscan.c: No such file or directory.
(gdb) where
#0  0x0000000120ea19cc in decfloat (f=0xffffffd7a0, c=49, bits=53, emin=-1074, sign=1, pok=1) at src/internal/floatscan.c:67
#1  0x0000000120c8c0e4 in strtox (s=0xffffffd978 "100", p=0xffffffd8f0, prec=prec@entry=1) at src/stdlib/strtod.c:11
#2  0x0000000120c8c1ac in strtod (s=<optimized out>, p=<optimized out>) at src/stdlib/strtod.c:24
#3  0x0000000120510890 in ParseSizeString (size=0x12113ed60 "100kb", res=0xffffffdac8) at util-misc.c:113
#4  0x0000000120510d80 in ParseSizeStringU32 (size=0x12113ed60 "100kb", res=0x121107b10 <cfglist+48>) at util-misc.c:190
#5  0x0000000120275060 in HTPConfigParseParameters (cfg_prec=0x121107ae0 <cfglist>, s=0x12113ebe0, tree=0x12112fd80) at app-layer-htp.c:2528
#6  0x0000000120276b34 in HTPConfigure () at app-layer-htp.c:2817
#7  0x0000000120277de4 in RegisterHTPParsers () at app-layer-htp.c:3101
#8  0x0000000120288ef4 in AppLayerParserRegisterProtocolParsers () at app-layer-parser.c:1561
#9  0x000000012022f1cc in AppLayerSetup () at app-layer.c:812
#10 0x00000001204ab720 in PostConfLoadedSetup (suri=0x12111d570 <suricata>) at suricata.c:2494
#11 0x00000001204ac8d0 in SuricataMain (argc=6, argv=0xffffffdd38) at suricata.c:2777
#12 0x00000001202268bc in main (argc=6, argv=0xffffffdd38) at main.c:22
(gdb) list 67
file: "src/internal/floatscan.c", line number: 67, symbol: "???"
62	in src/internal/floatscan.c
file: "src/internal/floatscan.c", line number: 67, symbol: "???"
62		return neg ? -y : y;
63	}
64	
65	
66	static long double decfloat(FILE *f, int c, int bits, int emin, int sign, int pok)
67	{
68		uint32_t x[KMAX];
69		static const uint32_t th[] = { LD_B1B_MAX };
70		int i, j, k, a, z;
71		long long lrp=0, dc=0;
(gdb) x/i 0xffffffd7a0
   0xffffffd7a0:	dsra32	zero,zero,0x3
(gdb) x/1fw 0xffffffd7a0
0xffffffd7a0:	3.57331108e-43
(gdb) x/1dw 0xffffffd7a0
0xffffffd7a0:	255
(gdb)

In layout asm:

0x120ea19cc <decfloat+60>       sdc1   $f24,8376(sp) 
``

Suggestions?
23

Note that libc must be built with the compiler flag -msoft-float as well.

It’s not clear if that’s the case in your setup.

24

Yes. I am seeing -msoft-float in the gcc args. Doing an objdump on floatscan.lo pulled apart the decfloat function, and I failed to see any FPU calls (since I don’t have a hardware FPU), but when I run it on the device, I see the sdc1 call, which is where it was failing.

I am currently building out to ensure ccache isn’t causing issues and removing it from the build. I’ll test again (to make sure ccache wasn’t just placing already compiled objects back into the build-directory), and will let you know.

I am able to do whatever is suggested and put the output, just keep in mind I probably won’t understand what you’re asking to see :slight_smile:

Example: info sharedlibrary returns the following:

(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x000000fff7f4a700  0x000000fff7fd4a7c  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1
0x000000fff7ede810  0x000000fff7f1b540  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/liblua.so.5.1.5
0x000000fff7ea6360  0x000000fff7ec3290  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libhtp.so.2
0x000000fff7e2f7c0  0x000000fff7e8d850  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/liblz4.so.1
0x000000fff7e14fd0  0x000000fff7e1afb0  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libmaxminddb.so.0
0x000000fff7dc87c0  0x000000fff7df9d00  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libmagic.so.1
0x000000fff7da9f40  0x000000fff7dae500  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libcap-ng.so.0
0x000000fff7d79a70  0x000000fff7d92a60  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libnet.so.9
0x000000fff7d52150  0x000000fff7d61f00  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libjansson.so.4
0x000000fff7d0a630  0x000000fff7d3ace0  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libyaml-0.so.2
0x000000fff7c91410  0x000000fff7cdd680  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libpcre.so.1
0x000000fff7c54810  0x000000fff7c70180  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libz.so.1
0x000000fff7be89d0  0x000000fff7c281c0  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libpcap.so.1
0x000000fff7a4c330  0x000000fff7ba3920  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libnss3.so
0x000000fff79dd530  0x000000fff7a01340  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libnssutil3.so
0x000000fff79910e0  0x000000fff79be770  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libsmime3.so
0x000000fff78f8cf0  0x000000fff79699a0  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libssl3.so
0x000000fff7873880  0x000000fff78d1d50  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libsoftokn3.so
0x000000fff7858c60  0x000000fff785ab90  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libplds4.so
0x000000fff7843080  0x000000fff7846a20  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libplc4.so
0x000000fff77e0c10  0x000000fff7827f00  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libnspr4.so
0x000000fff778e960  0x000000fff77c13d0  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/libgcc_s.so.1
0x000000fff7743cd0  0x000000fff7772230  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/liblzma.so.5
0x000000fff7715620  0x000000fff772e470  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libbz2.so.1.0
0x000000fff754e450  0x000000fff76e7100  Yes         /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/usr/lib/libsqlite3.so.0

Edit: It was suggested that musl might be the issue, so I’m going to attempt to rebuild out with glibc instead and report back

25

Does this information (info shared lib) correlate with the output of ldd <suricata-binary>?

26

This is from the suricata bin on-device.

root@OpenWrt:/# ldd /usr/bin/suricata
        /lib/ld-musl-mips64-sf.so.1 (0xfff357b000)
        liblua.so.5.1.5 => /usr/lib/liblua.so.5.1.5 (0xfff3520000)
        libhtp.so.2 => /usr/lib/libhtp.so.2 (0xfff34e7000)
        liblz4.so.1 => /usr/lib/liblz4.so.1 (0xfff3473000)
        libmaxminddb.so.0 => /usr/lib/libmaxminddb.so.0 (0xfff345a000)
        libmagic.so.1 => /usr/lib/libmagic.so.1 (0xfff3406000)
        libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0xfff33ef000)
        libnet.so.9 => /usr/lib/libnet.so.9 (0xfff33bb000)
        libjansson.so.4 => /usr/lib/libjansson.so.4 (0xfff3395000)
        libyaml-0.so.2 => /usr/lib/libyaml-0.so.2 (0xfff334e000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0xfff32cb000)
        libz.so.1 => /usr/lib/libz.so.1 (0xfff3296000)
        libpcap.so.1 => /usr/lib/libpcap.so.1 (0xfff3220000)
        libnss3.so => /usr/lib/libnss3.so (0xfff3066000)
        libnssutil3.so => /usr/lib/libnssutil3.so (0xfff3017000)
        libsmime3.so => /usr/lib/libsmime3.so (0xfff2fce000)
        libssl3.so => /usr/lib/libssl3.so (0xfff2f30000)
        libsoftokn3.so => /usr/lib/libsoftokn3.so (0xfff2eaf000)
        libplds4.so => /usr/lib/libplds4.so (0xfff2e9b000)
        libplc4.so => /usr/lib/libplc4.so (0xfff2e85000)
        libnspr4.so => /usr/lib/libnspr4.so (0xfff2e18000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xfff2dc7000)
        libc.so => /lib/ld-musl-mips64-sf.so.1 (0xfff357b000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0xfff2d82000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0xfff2d55000)
        libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xfff2b7b000)
root@OpenWrt:/#
27

Since it seems like the runtime library presumes the FP hardware is present, try strace -o /tmp/suricata.strace.out suricata <suricata-args>

suricata.strace.out will show where libc is loaded from.

28

Here is the output of the strace command.

suricata.strace.out.tgz (9.0 KB)

29

You had stated that objdump doesn’t show the instruction triggering the fault – sdc1. Did you observed this on the host where you cross-compiled the binary or on the target where the fault/illegal instruction occurred?

Are /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1 [cross-compilation host] and /lib/ld-musl-mips64-sf.so.1 [target] the same (perhaps check the sizes, if equal, then generate the md5)?

30

Because I’m so new, and still learning, I want to give an update and seek further assistance.

First, I finally realized Openwrt was using sstrip on the final binaries… I’ve turned that off.

Second, now that it says it’s reading the symbols ok, I tried again:

grommish@norwits:~/openwrt$ ./scripts/remote-gdb 192.168.1.1:9000 build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/ipkg-mips64_octeon3/suricata6/usr/bin/suricata
Using target mips64_octeon3_64 (musl, )
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=mips64-openwrt-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/ipkg-mips64_octeon3/suricata6/usr/bin/suricata...
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/grommish/openwrt/build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/ipkg-mips64_octeon3/suricata6/usr/bin/suricata.
Use `info auto-load python-scripts [REGEXP]' to list them.
0x000000fff7f43a00 in _dlstart ()
   from /home/grommish/openwrt/scripts/../staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1
(gdb) set remote exec-file /usr/bin/suricata
(gdb) set args -c /etc/suricata/suricata.yaml -i eth0
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/grommish/openwrt/build_dir/target-mips64_octeon3_64_musl/suricata-6.0.0-beta1/ipkg-mips64_octeon3/suricata6/usr/bin/suricata -c /etc/suricata/suricata.yaml -i eth0

Program received signal SIGILL, Illegal instruction.
`0x0000000120eab7fc` in decfloat (f=0xffffffd7c0, c=49, bits=53, emin=-1074, sign=1, pok=1) at src/internal/floatscan.c:67
67	src/internal/floatscan.c: No such file or directory.
(gdb) x/i
Argument required (starting display address).
(gdb) x/i 0x0000000120eab7fc
=> 0x120eab7fc <decfloat+60>:	sdc1	$f24,8376(sp)
(gdb)

The 0x0000000120eab7fc seems to be the space that it dies at, and when i do the x/i on it, it returns the sdc1

If i x/i on the FILE f* pointer (0xffffffd7c0), I get:

(gdb) x/i 0xffffffd7c0
   0xffffffd7c0:	dsra32	zero,zero,0x3
(gdb)

Which shows as:

DSRA32       Doubleword Shift Right Arithmetic Plus 32

Again, i apologize to all because I am seriously learning as I go and trying to get those with the knowledge information that can be useful.

31

x/i interprets the memory as an instruction but f is the address for a FILE.

I didn’t see an answer yet to my earlier question:

32 
grommish@norwits:~/openwrt$ lscp root@192.168.1.1:/lib/ld-musl-mips64-sf.so.1 .
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
ld-musl-mips64-sf.so.1                                                                            100% 5314KB   3.6MB/s   00:01    
grommish@norwits:~/openwrt$ cmp -l ld-musl-mips64-sf.so.1 ./staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1 | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
grommish@norwits:~/openwrt$

They are the same… lscp is just my lazy-scp I use because I consistently flash and change ssh keys on the target

alias lssh='ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'
alias lscp='scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'

I can manually put ./staging_dir/target-mips64_octeon3_64_musl/root-octeon/lib/ld-musl-mips64-sf.so.1 onto the device as /lib/ld-musl-mips64-sf.so.1, if you think that’ll help.

34

This appears to be a Rust issue. RustC builds with -mhard-float when I need -msoft-float Rust precompiles rustup as hardfloat and they don’t seem to want to support sf targets natively

/home/grommish/openwrt/staging_dir/toolchain-mips64_octeon3_64_gcc-10.2.0_musl/lib/gcc/mips64-openwrt-linux-musl/10.2.0/../../../../mips64-openwrt-linux-musl/bin/ld: warning: .libs/suricata uses -msoft-float (set by /home/grommish/openwrt/staging_dir/toolchain-mips64_octeon3_64_gcc-10.2.0_musl/lib/gcc/mips64-openwrt-linux-musl/10.2.0/../../../../mips64-openwrt-linux-musl/lib/crt1.o), ../rust/target/mips64-unknown-linux-muslabi64/debug/libsuricata.a(lexical_core-26e607784d7b6b19.lexical_core.d5exfxeu-cgu.0.rcgu.o) uses -mhard-float
35

Maybe this can be of help?

It suggests you can have kernel level FPU emulation?

Edit: link to the relevant comment https://github.com/rust-lang/rust/pull/50902#issuecomment-392379230

36

Even kernel emulation didn’t fix the issue. Their best suggestion is to create my own target with a +soft-float feature, which will require compiling from source.

I can verify that the issue is with rust’s inclusion of the -mhard-float flag in all of their pre-compiled rustup archives. This isn’t an issue with the Suricata code… Suricata respects the -msoft-float

/home/grommish/openwrt/staging_dir/toolchain-mips64_octeon3_64_gcc-10.2.0_musl/lib/gcc/mips64-openwrt-linux-musl/10.2.0/../../../../mips64-openwrt-linux-musl/bin/ld: warning: .libs/suricata uses -msoft-float (set by /home/grommish/openwrt/staging_dir/toolchain-mips64_octeon3_64_gcc-10.2.0_musl/lib/gcc/mips64-openwrt-linux-musl/10.2.0/../../../../mips64-openwrt-linux-musl/lib/crt1.o), ../rust/target/mips64-unknown-linux-muslabi64/debug/libsuricata.a(lexical_core-26e607784d7b6b19.lexical_core.d5exfxeu-cgu.0.rcgu.o) uses -mhard-float

I will mention that the above appeared only as a warning, and not an error.

37

Update:

I’m now compiling correctly to correct for the soft-float issue. No more SIGILL errors…

However… When building from master commit 95729e923f39b5adda31e4843a1b6ee06edbb0c8

I am now getting:
-- 06:23:21 - (app-layer-htp.c:2529) <Error> (HTPConfigParseParameters) -- [ERRCODE: SC_ERR_SIZE_PARSE(198)] - Error parsing request-body-limit from conf file - 100kb. Killing engine

in my suricata.yaml (I’m using the default, stock one)

      libhtp:                                      
         default-config:                             
           personality: IDS                          
                                                                     
           # Can be specified in kb, mb, gb.  Just a number indicates                    
           # it's in bytes.                                                              
           request-body-limit: 100kb                                                     
           response-body-limit: 100kb                                                    
                                                                                  
           # inspection limits                                                    
           request-body-minimal-inspect-size: 32kb                                
           request-body-inspect-window: 4kb                                       
           response-body-minimal-inspect-size: 40kb               
           response-body-inspect-window: 16kb                                   
                                                                         
           # response body decompression (0 disables)                    
           response-body-decompress-layer-limit: 2                       
                                                                                         
           # auto will use http-body-inline mode in IPS mode, yes or no set it statically
           http-body-inline: auto

Any suggestions?

38

These are the default values (as you indicated) and should be working.

Can you post (or dm) your actual file? I’d like to see if there are any unprintable chars that might be affecting things.

39

suricata.yaml (70.6 KB)

It’s the stock file, so I don’t have anything worth protecting in there. And, that is the file from the device (since I deal with cross-compile craziness) that it’s trying to run

I diff'ed the suricata.yaml that is created in the buildroot versus the one from the device and they are the same, but hopefully I’m just missing something simple for a change :smiley:

I appreciate all the help in getting Suricata to work… It’s a learning experience :smiley:

40

Hi,
I’m not able to reproduce your issue using your configuration file.

If you run suricata -c /path/to/suricata.yaml --disable-detection -T -vvv, this will “test” the configuration and emit more diagnostic information (but not likely to highlight the underlying issue).

41 
[16806] 17/10/2020 -- 13:56:07 - (suricata.c:1621) <Info> (ParseCommandLine) -- Running suricata under test mode
Error opening file /var/log/suricata//suricata.log
[16806] 17/10/2020 -- 13:56:07 - (suricata.c:1065) <Notice> (LogVersion) -- This is Suricata version 6.0.0-dev running in SYSTEM mode
[16806] 17/10/2020 -- 13:56:07 - (util-cpu.c:178) <Info> (UtilCpuPrintSummary) -- CPUs/cores online: 2
[16806] 17/10/2020 -- 13:56:07 - (app-layer-htp.c:2529) <Error> (HTPConfigParseParameters) -- [ERRCODE: SC_ERR_SIZE_PARSE(198)] - Error parsing request-body-limit from conf file - 100kb.  Killing engine