Messages

Thanks for your help Darkopnsense.
Does Sensei require Suricata MiTM SSL decryption running along side it, or does it implement it's own solution?
I'm guessing there's some kind of SSL decryption implemented for Sensei to do it's thing?

the performance compared to what?

... Suricata running SSL MiTM decryption/inspection via Squid?

Hello,

Has anyone installed Sensei on a PC Engines APU?
How was the performance?

Thanks.

Can confirm.  Temps no longer reported on my apu2C4.
Just reported it to 3mdeb.

I'm just gonna delete that

...

Having applied the patch the GUI download never starts, but can still be transfered fine via scp.
Applied the patch again to remove it and the GUI download started working again.
Tested with a ~300MB capture.

Seams to have generated a bug report too:

Code Select Expand

[30-Sep-2019 21:58:07 Europe/London] PHP Fatal error:  Allowed memory size of 402653184 bytes exhausted (tried to allocate 344058472 bytes) in /usr/local/www/diag_packet_capture.php on line 165
[30-Sep-2019 21:58:07 Europe/London] PHP Fatal error:  Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0
[30-Sep-2019 21:58:40 Europe/London] PHP Fatal error:  Allowed memory size of 402653184 bytes exhausted (tried to allocate 344058472 bytes) in /usr/local/www/diag_packet_capture.php on line 165
[30-Sep-2019 21:58:40 Europe/London] PHP Fatal error:  Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0

dude, gaming!

point taken

It certainly looks like something's happening here.
No matter the size or duration of the capture, when transferred via SSH everything's fine; when downloaded via the GUI things end up broken.

Looks like C1 and C2 is supported, but I never see anything other than a 1Ghz frequency being reported.

EDIT:  Enabling PowerD sorted this out.  I've been reluctant to enable this for some time; last time I did OPNsense became very unstable.  Guess now CPB's incorporated into the BIOS it's working fine.

Usage on core 0 has dropped significantly, that seamed to be stuck at ~50% for hours despite not much of anything going on.

Don't understand why cores 1,2,3 all report constant 100% usage though; do they just not report in any meaningful way?

Code Select Expand

sysctl dev.cpu | grep cx
dev.cpu.3.cx_method: C1/hlt
dev.cpu.3.cx_usage_counters: 8676077
dev.cpu.3.cx_usage: 100.00% last 199us
dev.cpu.3.cx_lowest: C2
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.2.cx_method: C1/hlt
dev.cpu.2.cx_usage_counters: 8302605
dev.cpu.2.cx_usage: 100.00% last 143us
dev.cpu.2.cx_lowest: C2
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.1.cx_method: C1/hlt
dev.cpu.1.cx_usage_counters: 8291231
dev.cpu.1.cx_usage: 100.00% last 9426us
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.0.cx_method: C1/hlt C2/io
dev.cpu.0.cx_usage_counters: 2045044 9924622
dev.cpu.0.cx_usage: 17.08% 82.91% last 102us
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_supported: C1/1/0 C2/2/400

Code Select Expand

sysctl -a |grep -i cpu
kern.smp.cpus: 4
kern.smp.maxcpus: 256
kern.ccpu: 0
  <cpu count="4" mask="f,0,0,0">0, 1, 2, 3</cpu>
    <cpu count="4" mask="f,0,0,0">0, 1, 2, 3</cpu>
      <cpu count="1" mask="1,0,0,0">0</cpu>
      <cpu count="1" mask="2,0,0,0">1</cpu>
      <cpu count="1" mask="4,0,0,0">2</cpu>
      <cpu count="1" mask="8,0,0,0">3</cpu>
kern.sched.cpusetsize: 32
kern.pin_pcpu_swi: 0
kern.racct.pcpu_threshold: 1
cpu     HAMMER
device  cpufreq
kern.vt.splash_cpu_duration: 10
kern.vt.splash_cpu_style: 2
kern.vt.splash_ncpu: 0
kern.vt.splash_cpu: 0
vfs.ncpurgeminvnodes: 512
net.inet.tcp.per_cpu_timers: 0
debug.cpufreq.verbose: 0
debug.cpufreq.lowest: 0
debug.acpi.cpu_unordered: 0
kdb.enter.default=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset
hw.ncpu: 4
hw.acpi.cpu.cx_lowest: C2
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.0.%pnpinfo:
dev.cpufreq.0.%location:
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%desc:
dev.cpufreq.%parent:
dev.hwpstate.0.%parent: cpu0
dev.acpi_perf.3.%parent: cpu3
dev.acpi_perf.2.%parent: cpu2
dev.acpi_perf.1.%parent: cpu1
dev.acpi_perf.0.%parent: cpu0
dev.cpu.3.temperature: 49.2C
dev.cpu.3.cx_method: C1/hlt
dev.cpu.3.cx_usage_counters: 8677107
dev.cpu.3.cx_usage: 100.00% last 14312us
dev.cpu.3.cx_lowest: C2
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.3.%parent: acpi0
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%location: handle=\_PR_.P003
dev.cpu.3.%driver: cpu
dev.cpu.3.%desc: ACPI CPU
dev.cpu.2.temperature: 49.2C
dev.cpu.2.cx_method: C1/hlt
dev.cpu.2.cx_usage_counters: 8303616
dev.cpu.2.cx_usage: 100.00% last 51us
dev.cpu.2.cx_lowest: C2
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.2.%parent: acpi0
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%location: handle=\_PR_.P002
dev.cpu.2.%driver: cpu
dev.cpu.2.%desc: ACPI CPU
dev.cpu.1.temperature: 49.2C
dev.cpu.1.cx_method: C1/hlt
dev.cpu.1.cx_usage_counters: 8292305
dev.cpu.1.cx_usage: 100.00% last 210us
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%location: handle=\_PR_.P001
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.temperature: 49.2C
dev.cpu.0.cx_method: C1/hlt C2/io
dev.cpu.0.cx_usage_counters: 2045118 9925802
dev.cpu.0.cx_usage: 17.08% 82.91% last 38us
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_supported: C1/1/0 C2/2/400
dev.cpu.0.freq_levels: 1000/980 800/807 600/609
dev.cpu.0.freq: 1000
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%location: handle=\_PR_.P000
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.%parent:
security.jail.param.cpuset.id: 0

Says "command not found"...?

Just noticed this, wondered if anone could help explain it.

'sysctl dev.cpu.*' pretty much always displays the following values:

dev.cpu.0.cx_usage: 59.95% 40.04% last 20173us
dev.cpu.1.cx_usage: 100.00% last 26422us
dev.cpu.2.cx_usage: 100.00% last 44450us
dev.cpu.3.cx_usage: 100.00% last 18583us

Yet 'top' shows nowhere near this kind of usage:



And neither does the GUI:



I'm running OPNsense 19.7.3-amd64 on an APU2C4 with BIOS v4.10.0.0

Hi,

Whenever I leave an interface capture running for any amount of time, Wireshark reports the following when I open the file:

"The capture file appears to be damaged or corrupt.
(pcap: File has 992550946-byte packet, bigger than maximum of 262144)"

Is this because I'm leaving the capture running for a long time, or something else?
Looking around Google a lot of people mention it could be to do with the transfer method, but I just downloaded the file via the GUI.

Thanks.