Closed philrz closed 4 years ago
I tried running with the new brim13
artifact that has the benefit of the fix in the linked PR. I no longer see the symptom previously shown, but Suricata still seems to fail.
C:\Users\phil\Desktop\suricata-v5.0.3-brim13.windows-amd64\suricata>type \users\phil\Desktop\wrccdc.pcap | .\suricatarunner.exe
18/11/2020 -- 22:57:36 - <Info> - Running as service: no
18/11/2020 -- 22:57:36 - <Notice> - This is Suricata version 5.0.3 RELEASE running in USER mode
18/11/2020 -- 22:57:36 - <Info> - CPUs/cores online: 2
2020/11/18 22:57:36 launchSuricata failed exit status 3221225501
The process tried to write to a nonexistent pipe.
I'm not sure if this is the root cause, but if I try to run suricata.exe
by itself, I see a series of DLL error pop-ups one after the other.
Since the original top-level title of this issue still seems to apply, I'll just reopen this one rather than start yet another issue.
Hmm. The second failure (DLL errors when you run suricata.exe directly) is to be expected. One thing that suricatarunner.exe does is to set up the environment so that the DLLs that ship with the package are found.
The first failure however is surprising. I had checked that this worked when putting up the PR intended to close this issue, and I just checked again to make sure that I'm not mixing things up, and I can run suricatarunner.exe fine.
This is on a gcloud windows-server-2019-dc-v20201110
host. I've run suricatarunner.exe in cmd
, powershell
, git-bash
, and the google cloud sdk shell, and all worked.
Verified in artifact suricata-v5.0.3-brim14.windows-amd64
. As shown in the linked PR, the root cause of the problem was determined to be due to architecture-specific compilation. Now that we've disabled that, I've been able to successfully generate the eve.json
from a pcap using the suricata-v5.0.3-brim14.windows-amd64
arfifact.
C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata>type \users\phil\Desktop\wrccdc.pcap | .\suricatarunner.exe
20/11/2020 -- 21:08:45 - <Info> - Running as service: no
20/11/2020 -- 21:08:45 - <Notice> - This is Suricata version 5.0.3 RELEASE running in USER mode
20/11/2020 -- 21:08:45 - <Info> - CPUs/cores online: 2
20/11/2020 -- 21:08:45 - <Info> - Configuring core dump is not yet supported on Windows.
20/11/2020 -- 21:08:45 - <Info> - No 'host-mode': suricata is in IDS mode, using default setting 'sniffer-only'
20/11/2020 -- 21:08:45 - <Info> - eve-log output device (regular) initialized: eve.json
...
C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata>dir eve.json
Volume in drive C has no label.
Volume Serial Number is FA0C-5C0F
Directory of C:\Users\phil\Desktop\suricata-v5.0.3-brim14.windows-amd64\suricata
11/20/2020 09:10 PM 108,540,437 eve.json
1 File(s) 108,540,437 bytes
0 Dir(s) 32,966,414,336 bytes free
Thanks @henridf!
As shown in the linked PR, the root cause of the problem was determined to be due to architecture-specific compilation.
And for future reference, the platform that failed with ILLEGAL INSTRUCTION was Intel Broadwell, while on Skylake the binary ran ok.
I tried testing manually on a scratch Windows Server 2019 Datacenter VM on Google Cloud using the
brim12
artifact. This was the error I witnessed:These are the final lines of
brim-conf-run.yaml
, with the middle one being the line 158 (at least, that's what Notepad++ labels as line 158):