Buildbot caught an error:
"Berkeley DB file locking needs flock() for version 5.x (and greater?)"
It is caused by leakage of host-installed Berkley DB into the build.
Since libmilter is not using the DB and because of convoluted build
process of sendmail, we do the workaround - define a macro which
prevents the error without affecting libmilter binary.
Also change source URL from FTP to HTTPS.
Signed-off-by: Aleksey Vasilenko <aleksey.vasilenko@gmail.com>
This reverts commit 366629b117.
It has been determined that the URL currently in use points to v1. The
previously used URL remains valid and is correct. If someone requires the
v1 URL, a new provider must be created.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Calculating the next check time based on the last update time is not
very accurate if the next check is a large multiple forwards from the
last update time because the cumulative sleeps and wake times are not
exact but best effort of the OS. Other factors including clock-drift
give rise to a larger time discrepancy the further the next update is in
the future.
Stash the next check time which should be quite accurate since it's
only one sleep instance away. This is also for use in the GUI.
Tested on 24.10.2
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Using the broker_selection param makes it possible to decide by use (default),
always use the first available broker to connect or select a random broker
See also: 51a5e46ad1/client/l2tp_client.c (L1331-L1333)
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
* add adblock-fast to the Ad Blocking segment
* fix grammar (Its -> It's)
* modify last paragraph of the instructions as they are specific to adblock
Signed-off-by: Stan Grishin <stangri@melmac.ca>
When snort is run with the --version option, it advertises components'
versions in the output. Add a patch to modify the output to clearly
show vectorscan is in use.
Signed-off-by: John Audia <therealgraysky@proton.me>
* Replacement of hyperscan-runtime reference with vectorscan-runtime
* Added support for all aarch64 targets which I believe is exhaustive
For x86 and x86/64, I found that vectorscan is truly a drop-in
replacement for hyperscan as assessed by speedtests with snort3 running
on my Intel N150 PC. CPU load during the test with each condition was
nearly saturating on a single core for both cases on a symmetrical
Gbps line.
Using: https://www.waveform.com/tools/bufferbloat in IPS mode:
Download speed w/ hyperscan: 950-960 Mbit/s (n=2)
Download speed w/ vectorscan: 942-960 Mbit/s (n=2)
Using: https://www.speedtest.net in IPS mode:
Download speed w/ hyperscan: 996-1002 Mbit/s (n=2)
Download speed w/ vectorscan: 993-988 Mbit/s (n=2)
Build system: x86/64
Build-tested: x86/64-glibc
Run-tested: x86/64-glibc (Intel N150 based box running snort3)
Signed-off-by: John Audia <therealgraysky@proton.me>
Drop 100-remove-HAVE_HS_COMPILE_LIT-to-work-around-upstream-b.patch as
it was only needed to fix the build against hyperscan. Vectorscan
builds fine without it.
Signed-off-by: John Audia <therealgraysky@proton.me>
Vectorscan is fork of Hyperscan, a high-performance multiple regex
matching library. It follows the regular expression syntax of the
commonly-used libpcre library, but is a standalone library with
its own C API.
Currently ARM NEON/ASIMD and Power VSX are 100% functional. ARM
SVE2 support is in ongoing with access to hardware now. More
platforms will follow in the future.
The performance difference of snort3 compiled against this is
sizable for aarch64 confirmed on two different SoCs:
Test SoC #1 flogic/glinet_gl-mt6000
IDS mode:
Download speed wo/ vectorscan: 91.2 ±0.21 Mbit/s (n=3)
Download speed using vectorscan: 331.0 ±27.34 Mbit/s (n=3)
Gain of 3.6x
IPS mode:
Download speed wo/ vectorscan: 30.0 ±0.06 Mbit/s (n=3)
Download speed using vectorscan: 52.9 ±0.78 Mbit/s (n=3)
Gain of 1.8x
Notes:
* Data generated on snapshot build on 12-Apr-2024 using kernel
6.6.26, snort 3.1.84.0, vectorscan 5.4.11.
* Speedtest script hitting the same server.
* Snort rules file of was 37,917 lines/22 MB.
* In all cases, single core CPU saturation occurred which
speaks to the efficiency gains supplied by vectorscan.
Test Soc #2 bcm2712/RPi5B
IPS mode:
Download speed wo/ vectorscan: 164.3 ±0.64 Mbit/s (n=3)
Download speed using vectorscan: 232.8 ±0.26 Mbit/s (n=3)
Gain of 1.4x
Notes:
* Data generated on snapshot build on 13-Apr-2024 using kernel
6.1.86, snort 3.1.84.0, vectorscan 5.4.11.
* Google fiber speedtest (https://fiber.google.com/speedtest/)
hitting the same server.
* Snort rules contained 39,801 rules/22 MB.
* In all cases, single core CPU saturation occurred which
speaks to the efficiency gains supplied by vectorscan.
Build system: x86/64
Build-tested: flogic/glinet_gl-mt6000, bcm2712/RPi5B, x86/64-glibc
Run-tested: flogic/glinet_gl-mt6000, bcm2712/RPi5B, x86/64-glibc (Intel N150 based box)
Co-authored-by: Tianling Shen <cnsztl@gmail.com>
Co-authored-by: Jeffery To <jeffery.to@gmail.com>
Signed-off-by: John Audia <therealgraysky@proton.me>
What started in #20183 as a attempt to clean up noise in the logfiles,
turned out to be causing denial-of-service for dual-stack and especially
IPv6-only environments.
Breaking core network functionality cannot possibly be less important
than cosmetic issues, and those affected by log spam can avoid it via
other means (e.g. "query-source-v6 none;" in named.conf).
There's no reliable heuristic for determining whether there's IPv6
connectivity at the time bind is started which will catch any and all
corner cases, as discussed in #26327.
So, remove this logic for now. If a suitable heuristic can be devised,
it can always be added in a subsequent patch, but I have my doubts.
(Also, quote one variable to make shellcheck happy)
Closes: #26327Closes: #20468
Signed-off-by: David Härdeman <david@hardeman.nu>
