Re: Installation Media Self Integrity Check

[Theo de Raadt]

Dan Peretz  wrote:

> Hello, the FAQ states this:
> "The installXX.iso and installXX.fs images do not contain an
> SHA256.sig file, so the installer will complain that it can't check
> the signature of the included sets [...] This is because it would make
> no sense for the installer to verify them. If someone were to make a
> rogue installation image, they could certainly change the installer to
> say the files were legitimate."

the FAQ is wrong.

Those images don't contain signatures because my build & sign
procedure does not have a way to sign something, then continue
building, then sign the result.

> Although that's true for intentional modifications, it would still be
> useful to have the installation medium perform a self integrity check
> against accidental or natural data corruption. For example, Ubuntu
> recently enabled a by-default integrity check, starting with release
> 20.04:
> "Ubuntu now defaults to checking the integrity of the medium in use
> when booting into live sessions. This can be skipped by hitting
> Ctrl-C. We’ve enabled this because failed installs due to corrupt
> downloads of installation media is one of the most common error
> conditions that users encounter." (Source:
> )

> I would like to have OpenBSD include at least an unsigned SHA256 file
> in the discs.

If you looked, you would see there is an unsigned SHA256 file.

> The installer would then detect that the checksums are
> unsigned and warn about the security implications, but it would let
> the user run the check.

It already uses the SHA256 file to determine which files to install,
this is done, but a hash is not a cryptographic signature, so the warning
issued is accurate.

> I think it would be wise to make it check the
> bsd.rd image that's actually booted when booting from the disc, and
> not just the bsd.rd file set. (I get that the OpenBSD installer is
> just a multipurpose "bsd.rd" RAM disk that can be found not just in
> the installation discs, right?)

Huh.  What you are asking for cannot be done.  And obviously a bogus
image would declare that it isn't bogus.

Installation Media Self Integrity Check

[Dan Peretz]

Hello, the FAQ states this:
"The installXX.iso and installXX.fs images do not contain an
SHA256.sig file, so the installer will complain that it can't check
the signature of the included sets [...] This is because it would make
no sense for the installer to verify them. If someone were to make a
rogue installation image, they could certainly change the installer to
say the files were legitimate."
Although that's true for intentional modifications, it would still be
useful to have the installation medium perform a self integrity check
against accidental or natural data corruption. For example, Ubuntu
recently enabled a by-default integrity check, starting with release
20.04:
"Ubuntu now defaults to checking the integrity of the medium in use
when booting into live sessions. This can be skipped by hitting
Ctrl-C. We’ve enabled this because failed installs due to corrupt
downloads of installation media is one of the most common error
conditions that users encounter." (Source:
)
I would like to have OpenBSD include at least an unsigned SHA256 file
in the discs. The installer would then detect that the checksums are
unsigned and warn about the security implications, but it would let
the user run the check. I think it would be wise to make it check the
bsd.rd image that's actually booted when booting from the disc, and
not just the bsd.rd file set. (I get that the OpenBSD installer is
just a multipurpose "bsd.rd" RAM disk that can be found not just in
the installation discs, right?)

Thank you!

Re: 019_libssl.patch regression

[Predrag Punosevac]

Theo Buehler  wrote:

> On Tue, Aug 11, 2020 at 05:26:22PM -0400, Predrag Punosevac wrote:
> > This is a regression report for 019_libssl.patch
> > After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
> > longer close STARTTLS IPMI session with Gmail server. I recompiled
> > s-nail and rebooted the machine. After reverting the patch s-nail works
> > as expected. Interestingly enough I can only see this with Gmail
> > servers.  019_libssl.patch doesn't break Hotmail IPMI connection. Patch
> > does break SMTP session with Gmail server in the same fashion as IPMI.
> > It just doesn't terminate cleanly. I don't know enough about the subject
> > to look further into the problem but I am 100% sure this is LibreSSL
> > bug.
> 
> Thanks for the report. Could you give this patch a spin on a -stable
> system, that is, on top of the 019_libssl patch?
> 
> Index: lib/libssl/tls13_legacy.c
> ===
> RCS file: /var/cvs/src/lib/libssl/tls13_legacy.c,v
> retrieving revision 1.3.4.2
> diff -u -p -r1.3.4.2 tls13_legacy.c
> --- lib/libssl/tls13_legacy.c 10 Aug 2020 18:59:47 -  1.3.4.2
> +++ lib/libssl/tls13_legacy.c 12 Aug 2020 18:46:12 -
> @@ -497,6 +497,7 @@ tls13_legacy_shutdown(SSL *ssl)
>   if ((ret = tls13_record_layer_send_pending(ctx->rl)) !=
>   TLS13_IO_SUCCESS)
>   return tls13_legacy_return_code(ssl, ret);
> + ctx->close_notify_sent = 1;
 ^
Right on the money! That did the trick. The patch works for me. Theo
thank you so much for patching this so quickly. Thank you Steffen for
figuring out the problem from my initial report. 

Cheers,
Predrag




>   } else if (!ctx->close_notify_recv) {
>   /*
>* If there is no application data pending, attempt to read more

Re: How many IPs can I block before taking a performance hit?

[Walt]

‐‐ Original Message ‐‐‐
On Wednesday, August 12, 2020 7:11 AM, Alan McKay  wrote:

> Hey folks,
>
> This is one that is difficult to test in a test environment.
>
> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
>
> With some scripting I'm looking at feeding block IPs to the firewalls
> to block bad-guys in near real time, but in theory if we got attacked
> by a bot net or something like that, it could result in a few thousand
> IPs being blocked. Possibly even 10s of thousands.
>
> Are there any real-world data out there on how big of a block list we
> can handle without impacting performance?
>
> We're doing the standard /etc/blacklist to load a table and then have
> a block on the table right at the top of the ruleset.
>
> thanks,
> -Alan
>

On our network, we maintain a running block of scanners but IP addresses
are removed from the list after several hours of no scanning.

One thing that has been useful for us is to create three sets of IP
addresses from our allocation of IP addresses.

One set ( currently with 9 IP addresses) allows incoming access from
anywhere in the world.  Another set (currently 18 IP addresses) allows
incoming access from the US only.  The third set (the remainder of our
/24) allows no incoming access.  Of course, each host may have its own
rules to limit access to the services actually needed.

Note that this applies to normal traffic.  Regardless of where it
originates, things like chargen are blocked for both incoming and
outgoing traffic.

Every afternoon, we download the current IPv4 and IPv6 address
blocks for the US from

http://www.ipdeny.com/ipblocks/data/aggregated/us-aggregated.zone

for IPv4 and

http://www.ipdeny.com/ipv6/ipaddresses/blocks/us.zone

for IPv6.  Thus, we use these lists to permit access to our
"US only" hosts.

The IP source of attempts to scan our IP addresses in the third set above
are automatically added to the block of scanners to be blocked.  These
blocks are then applied to all incoming traffic.  Thus, if someone tries
to scan IP addresses of hosts that provide no services on the Internet,
they are also blocked from connecting to any of our hosts for several
hours.

So if 192.0.2.20, for example, is seen as trying to scan our network,
they will be blocked from accessing any of our network for a little
while.  During that time, connections to a service at 192.0.2.20 from
our network are still permitted since it isn't entirely impossible that
the interpretation of it being a network scan is an error.

Walt

Browser (Gtk?) issue after sysupgrade to latest snapshot

[Why 42? The lists account.]

Hi All,

I just used sysupgrade (followed by pkg_add -u) to update my desktop
system to:
OpenBSD 6.7-current (GENERIC.MP) #22: Tue Aug 11 21:29:51 MDT 2020

All is working quite well but I noticed some issue with the iridium
browser. When I tried to export my bookmarks, iridium crashed.

As an experiment I then tried the same thing with chrome and then
firefox, they also both crash.

The iridium crash results in this on stdout/stderr:
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed 
> (error == NULL): Failed to load 
> /usr/local/share/icons/Faba/16x16/status/image-missing.svg: Unable to load 
> image-loading module: 
> /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: Cannot 
> load specified object (gdk-pixbuf-error-quark, 5)
> Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion 
> failed (error == NULL): Failed to load 
> /usr/local/share/icons/Faba/16x16/status/image-missing.svg: Unable to load 
> image-loading module: 
> /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: Cannot 
> load specified object (gdk-pixbuf-error-quark, 5)
> zsh: abort (core dumped)  iridium

There are a lot of what look like related warnings in .xsession-errors
e.g.
> (xfce4-appearance-settings:35516): Gtk-WARNING **: 21:27:57.917: Could
> not load a pixbuf from icon theme.  This may indicate that pixbuf
> loaders or the mime database could not be found.

All these errors seem to be Gtk and/or file-chooser related.

After a bit of research, I thought running "update-mime-database" might
help, but it returns this cryptic error(?):
> update-mime-database -V /usr/share  
> Updating MIME database in /usr/share...
> Directory '/usr/share/packages' does not exist!

That's correct, there is no such directory.

(Changing to using a different set/theme of icons (in Xfce) didn't help
either.)

Maybe I missed some vital post "pkg_add -u" action? A couple of days ago
I switched my video output from HDMI to DisplayPort. For X(fce) this
seems to work perfectly. However the Console screen (outside X11 e.g. at
boot time) now uses a much lower resolution, which results a lot of stuff
scrolling off the screen, including much of the package update advice.

(I ran my update without X(fce), guess I should have used
script/screen/tmux to capture the session :)).

FYI, here is the debugger output from the iridium crash:

mjoelnir:~ 12.08 22:05:24 % egdb /usr/local/iridium/iridium iridium.core
GNU gdb (GDB) 7.12.1
...
Core was generated by `iridium'.
Program terminated with signal SIGABRT, Aborted.
#0  thrkill () at /tmp/-:3
3   /tmp/-: No such file or directory.
[Current thread is 1 (process 430637)]

(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x0b16e6d7a15e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x0b1700a3f1c3 in g_assertion_message () from 
/usr/local/lib/libglib-2.0.so.4201.4
#3  0x0b1700a3f604 in g_assertion_message_error () from 
/usr/local/lib/libglib-2.0.so.4201.4
#4  0x0b1705899267 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#5  0x0b17058994d8 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#6  0x0b17058b5635 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#7  0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#8  0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#9  0x0b17058b5347 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#10 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#11 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#12 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#13 0x0b1705789562 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#14 0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#15 0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#16 0x0b1705788a77 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#17 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#18 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#19 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#20 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#21 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#22 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0b1705782b46 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#24 0x0b170596f59f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#25 0x0b1705997c95 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#26 0x0b1705996cd7 in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#27 0x0b1705996c13 in gtk_widget_get_preferred_width () from 
/usr/local/lib/libgtk-3.so.2201.0
#28 0x0b17057e93de in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#29 0x0b17057eea5f in ?? () from /usr/local/lib/libgtk-3.so.2201.0
#30 0x0b17058d8c9b in ?? () 

Re: 019_libssl.patch regression

[Theo Buehler]

On Tue, Aug 11, 2020 at 05:26:22PM -0400, Predrag Punosevac wrote:
> This is a regression report for 019_libssl.patch
> After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
> longer close STARTTLS IPMI session with Gmail server. I recompiled
> s-nail and rebooted the machine. After reverting the patch s-nail works
> as expected. Interestingly enough I can only see this with Gmail
> servers.  019_libssl.patch doesn't break Hotmail IPMI connection. Patch
> does break SMTP session with Gmail server in the same fashion as IPMI.
> It just doesn't terminate cleanly. I don't know enough about the subject
> to look further into the problem but I am 100% sure this is LibreSSL
> bug.

Thanks for the report. Could you give this patch a spin on a -stable
system, that is, on top of the 019_libssl patch?

Index: lib/libssl/tls13_legacy.c
===
RCS file: /var/cvs/src/lib/libssl/tls13_legacy.c,v
retrieving revision 1.3.4.2
diff -u -p -r1.3.4.2 tls13_legacy.c
--- lib/libssl/tls13_legacy.c   10 Aug 2020 18:59:47 -  1.3.4.2
+++ lib/libssl/tls13_legacy.c   12 Aug 2020 18:46:12 -
@@ -497,6 +497,7 @@ tls13_legacy_shutdown(SSL *ssl)
if ((ret = tls13_record_layer_send_pending(ctx->rl)) !=
TLS13_IO_SUCCESS)
return tls13_legacy_return_code(ssl, ret);
+   ctx->close_notify_sent = 1;
} else if (!ctx->close_notify_recv) {
/*
 * If there is no application data pending, attempt to read more

Re: How many IPs can I block before taking a performance hit?

[Steve Williams]

Hi,

I have a script that downloads "badhosts" from a site that continuously 
updates through a distrubed network.


I currently limit my blocklist to 450,000 ip addresses.

real mem = 4261072896 (4063MB)
avail mem = 4119322624 (3928MB)
bios0: PC Engines apu2



-pa-r-- blocklist
    Addresses:   45
    Cleared: Tue May 26 18:45:08 2020
    References:  [ Anchors: 0  Rules: 
1  ]
    Evaluations: [ NoMatch: 3794791    Match: 
1172204    ]
    In/Block:    [ Packets: 1172204    Bytes: 
61337613   ]
    In/Match:    [ Packets: 0  Bytes: 
0  ]
    In/Pass: [ Packets: 0  Bytes: 
0  ]
    In/XPass:    [ Packets: 0  Bytes: 
0  ]
    Out/Block:   [ Packets: 0  Bytes: 
0  ]
    Out/Match:   [ Packets: 0  Bytes: 
0  ]
    Out/Pass:    [ Packets: 0  Bytes: 
0  ]
    Out/XPass:   [ Packets: 0  Bytes: 
0  ]



Cheers,
Steve W.

On 12/08/2020 6:11 a.m., Alan McKay wrote:

Hey folks,

This is one that is difficult to test in a test environment.

I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.

With some scripting I'm looking at feeding block IPs to the firewalls
to block bad-guys in near real time, but in theory if we got attacked
by a bot net or something like that, it could result in a few thousand
IPs being blocked.  Possibly even 10s of thousands.

Are there any real-world data out there on how big of a block list we
can handle without impacting performance?

We're doing the standard /etc/blacklist to load a table and then have
a block on the table right at the top of the ruleset.

thanks,
-Alan

Re: How many IPs can I block before taking a performance hit?

[Martin Sukany]

Hi,

as the tables are stored in RAM anyway during thee processing it’s moreless 
matter of how fast are your DIMMs / CPU. I’m usually work with several tables 
with cca 30 K records - no impact on the performance so far. 


S pozdravem / Kind regards

Martin Sukaný
UNIX Engineer, Developer, DevOps specialist
xmpp: mar...@sukany.cz
phone: +420 776 275 713
email: mar...@sukany.cz
l: https://www.linkedin.com/in/martins6



> 12. 8. 2020 v 14:22, Stuart Harland :
> 
> This is one of those “How long is a piece of string” examples.
> 
> You don’t give a lot in the way of specifications so as to come up with a 
> reasonble guess. But the guesses are meaningless anyway, as the packet 
> filtering subsystems are pretty efficient and very rapid.
> 
> In reality with sufficient CPU clock speed and memory for the state tables, 
> you should be able to simultaneously block thousands and thousands, if not 
> more.
> 
> Not particularly scientific, but there we are.
> 
> Stuart
> 
>> On 12 Aug 2020, at 13:11, Alan McKay  wrote:
>> 
>> Hey folks,
>> 
>> This is one that is difficult to test in a test environment.
>> 
>> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
>> 
>> With some scripting I'm looking at feeding block IPs to the firewalls
>> to block bad-guys in near real time, but in theory if we got attacked
>> by a bot net or something like that, it could result in a few thousand
>> IPs being blocked.  Possibly even 10s of thousands.
>> 
>> Are there any real-world data out there on how big of a block list we
>> can handle without impacting performance?
>> 
>> We're doing the standard /etc/blacklist to load a table and then have
>> a block on the table right at the top of the ruleset.
>> 
>> thanks,
>> -Alan
>> 
>> -- 
>> "You should sit in nature for 20 minutes a day.
>> Unless you are busy, then you should sit for an hour"
>>- Zen Proverb
>> 
> 

Re: Adding more syspatch platform.

[Jordan Geoghegan]

On 2020-08-12 02:08, Stuart Henderson wrote:

The only proxy we have for "what is really used" is dmesg submissions.
Since 6.7 release:

amd64   62
i3865
arm64   3
macppc  2
octeon  1

Based on this there isn't a great case for adding any more.



I didn't realize you guys used dmesg@ as a popularity gauge, I thought 
it was just for sending dmesgs for interesting/new hardware. I figured 
with something like Edgerouters with their standardized hardware that 
repeat dmesgs would just serve to irritate the devs. I personally 
administer more OpenBSD 6.x machines than are on that list you sent. I 
can start hammering dmesg@, but then I'm gonna skew your stats and 
you're gonna think that your userbase consists of a bunch of autists 
that unironically run macppc, sparc64 and octeon in production 
everywhere. In the small Canadian town I live in, I've got a big chunk 
of it running on OpenBSD. I've got a bunch of old 90's / 2000's i386 
stuff too, so I can send dmesgs in for that too, the reason I didn't is 
I figured the hardware was already 'been there, done that'.


As I mentioned earlier in the thread, I can afford to donate 2 octeon 
machines to any devs that are interested (including shipping world wide; 
any devs reading: please contact me if you're interested), and am also 
happy to help out with octeon stuff in any way I can. Obviously you guys 
aren't going to trust me to do anything syspatch related as I'm not a 
dev, but I'd at least like it to be known that there are people who care 
about the octeon port and who are willing make an effort for it.


Regards,

Jordan

Re: How many IPs can I block before taking a performance hit?

[Stuart Henderson]

On 2020-08-12, Tomasz Rola  wrote:
> Is there a way to have listing of offending IPs and perhaps grouping
> them into /nn subnets - other than writing oneself the script?

aggregate6, in packages. It will be slow on a large list, of course.

> Something as easy as awk might suffice, I guess - and then instead of
> five rules, just one rule for a subnet. If IPs are close enough to
> form a subnet (now, what is "close enough", there might be interesting
> problem). Of course, this way, some IPs will be excluded even if
> they did nothing wrong (yet).

it doesn't do this "fuzzy matching" though, it purely converts a
fully filled subnet to the relevant prefix. 
e.g.

$ printf '1.0.0.0\n1.0.0.1\n1.0.0.2\n' | aggregate6
1.0.0.0/31
1.0.0.2/32

Re: How many IPs can I block before taking a performance hit?

[Jordan Geoghegan]

On 2020-08-12 05:11, Alan McKay wrote:

Hey folks,

This is one that is difficult to test in a test environment.

I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.

With some scripting I'm looking at feeding block IPs to the firewalls
to block bad-guys in near real time, but in theory if we got attacked
by a bot net or something like that, it could result in a few thousand
IPs being blocked.  Possibly even 10s of thousands.

Are there any real-world data out there on how big of a block list we
can handle without impacting performance?

We're doing the standard /etc/blacklist to load a table and then have
a block on the table right at the top of the ruleset.

thanks,
-Alan




At Otto said, if you're using tables, then you should be fine. I'm doing 
geoip blocking and all sorts of filtering using a pf table that contains 
over 200 undecillion addresses (that obviously includes CIDR block 
expansion):


# Entries (+-)
9482 addresses added.
10859 addresses deleted.

# Entries (expanded CIDR blocks)
IPv4 addresses in table:  966545967
IPv6 addresses in table:  298179424470603435988810818668701155328

fw$ wc -l < /etc/pf-badhost.txt
  146541

Re: How many IPs can I block before taking a performance hit?

[Tomasz Rola]

On Wed, Aug 12, 2020 at 03:00:03PM +0200, Martin Sukany wrote:
> Hi,
> 
> as the tables are stored in RAM anyway during thee processing it’s
> moreless matter of how fast are your DIMMs / CPU. I’m usually work
> with several tables with cca 30 K records - no impact on the
> performance so far.

So, for as long as the table(s) do not spill out of cpu's cache, it is
going to be a not so huge problem. If you run memtest, the difference
between various caches is big, but cache vs ram is huge.

Is there a way to have listing of offending IPs and perhaps grouping
them into /nn subnets - other than writing oneself the script?
Something as easy as awk might suffice, I guess - and then instead of
five rules, just one rule for a subnet. If IPs are close enough to
form a subnet (now, what is "close enough", there might be interesting
problem). Of course, this way, some IPs will be excluded even if
they did nothing wrong (yet).

Another nice thing to have might be a utility which looks for rules
and disables those which did not fired up during last x seconds (by
looking up through firewall logs, perhaps). I have no idea if there is
such utility and am not sure how to look it up.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **

Re: How many IPs can I block before taking a performance hit?

[Alan McKay]

Wow over 160 MILLION (yes I screamed that) IPs!

How much RAM is in your system?

On Wed, Aug 12, 2020 at 10:26 AM infoomatic  wrote:
>
> We have ~30,000 entries in our table  blocking networks and
> single ip addresses, all in all at the moment exactly 169,471,974 hosts
> being blocked. No idea what your criteria is for "performance impact",
> but we have no issues.
>
>
> On 12.08.20 14:11, Alan McKay wrote:
> > Hey folks,
> >
> > This is one that is difficult to test in a test environment.
> >
> > I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
> >
> > With some scripting I'm looking at feeding block IPs to the firewalls
> > to block bad-guys in near real time, but in theory if we got attacked
> > by a bot net or something like that, it could result in a few thousand
> > IPs being blocked.  Possibly even 10s of thousands.
> >
> > Are there any real-world data out there on how big of a block list we
> > can handle without impacting performance?
> >
> > We're doing the standard /etc/blacklist to load a table and then have
> > a block on the table right at the top of the ruleset.
> >
> > thanks,
> > -Alan
> >
>


-- 
"You should sit in nature for 20 minutes a day.
 Unless you are busy, then you should sit for an hour"
 - Zen Proverb

Re: 019_libssl.patch regression

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20200812132648.kaxsj%stef...@sdaoden.eu>:
 |Steffen Nurpmeso wrote in
 | <20200812130039.lto3i%stef...@sdaoden.eu>:
 ||Predrag Punosevac wrote in
 || <20200811212622.ugmda%punoseva...@gmail.com>:
 |||This is a regression report for 019_libssl.patch
 | ...
 |||After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
 |||longer close STARTTLS IPMI session with Gmail server. I recompiled
 | ...
 ||Hmm.  I can reproduce this here indeed.
 | ...
 ||  nail: >>> QUIT
 ||  nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 \
 ||  - gsmtp
 ||
 ||And here it hangs endlessly.  For now i presume it hangs at
 ||
 || while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */
 ||;
 |
 |I can confirm we have an endless loop in SSL_shutdown() here.

P.S.: this is ugly code.
P.P.S.: new OpenSSL documents that SSL_read() should be used
instead of a second SSL_shutdown().  I will ask about that on
a openssl-user list when i find some head.  But .. will this work
with libressl too??
Thanks.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: How many IPs can I block before taking a performance hit?

[infoomatic]

We have ~30,000 entries in our table  blocking networks and
single ip addresses, all in all at the moment exactly 169,471,974 hosts
being blocked. No idea what your criteria is for "performance impact",
but we have no issues.


On 12.08.20 14:11, Alan McKay wrote:
> Hey folks,
>
> This is one that is difficult to test in a test environment.
>
> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
>
> With some scripting I'm looking at feeding block IPs to the firewalls
> to block bad-guys in near real time, but in theory if we got attacked
> by a bot net or something like that, it could result in a few thousand
> IPs being blocked.  Possibly even 10s of thousands.
>
> Are there any real-world data out there on how big of a block list we
> can handle without impacting performance?
>
> We're doing the standard /etc/blacklist to load a table and then have
> a block on the table right at the top of the ruleset.
>
> thanks,
> -Alan
>

Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)

[Tom Smyth]

What is the Switch telling you about the LACP ?

can you do a

show port-channel

show port-channel detailed

sho port-channel summary

on the switch you are lagging with ?

can you also do a
sho  run int port-channel ?

sho run int ethernet  x,y

where x and y are the interfaces on the switch are in the LACP Port Channel
?

Thanks



On Wed, 12 Aug 2020 at 14:40, Winfred Harrelson 
wrote:

> On Tue, Aug 11, 2020 at 10:13:41PM +0200, Remi Locherer wrote:
> > On Tue, Aug 11, 2020 at 02:07:32PM -0400, Winfred Harrelson wrote:
> > > I know others are using the new aggr(4) interface but I am having a
> > > problem with trying to use it on some new servers I have recently
> > > gotten.  Hoping I could get some help from someone here since my
> > > searches have not been very fruitful.
> > >
> > > First off this is on a Supermicro X11DPi-N(T) and it is running a 6.7
> > > snapshot from today because the 6.7 release hangs on trying to install.
> > >
> > > I have two Intel duel port XXV710 cards with SPF28 and trying to
> > > create an LACP bond.  Works fine using the trunk(4) interface but
> > > not the aggr(4) interface.  This is what I get:
> > >
> > > styx# ifconfig ixl0
> > > ixl0: flags=8843 mtu 1500
> > > lladdr fe:e1:ba:d0:cc:aa
> > > index 1 priority 0 llprio 3
> > > trunk: trunkdev aggr1
> >   ^
> > ixl0 is already member of aggr1
> >
> > > media: Ethernet autoselect (25GbaseSR full-duplex)
> > > status: active
> > > styx# ifconfig ixl2
> > > ixl2: flags=8843 mtu 1500
> > > lladdr fe:e1:ba:d0:cc:aa
> > > index 3 priority 0 llprio 3
> > > trunk: trunkdev aggr1
> >   ^
> > same here
>
> Thanks for the quick reply.
>
> Unfortunately this is not the issue.  I had tried several attempts
> before sending the email and had forgotten to clean up first before
> sending the examples.  If the interface is already part of another
> trunk group you will get an error attempting to add a different one.
>
> I did a sysupgrade this morning in case something had changed and
> also updated the XXV710 cards to the newest firmware but with no luck.
>
>
>
> wharrels@styx2:/home/wharrels# dmesg | grep ^ixl
> ixl0 at pci5 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:28
> ixl1 at pci5 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:29
> ixl2 at pci8 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b0
> ixl3 at pci8 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b1
> ixl4 at pci12 dev 0 function 0 "Intel X722 10GBASE-T" rev 0x09: port 0, FW
> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f2
> ixl5 at pci12 dev 0 function 1 "Intel X722 10GBASE-T" rev 0x09: port 1, FW
> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f3
>
> Yup, latest firmware.
>
>
> wharrels@styx2:/etc# ifconfig ixl0
> ixl0: flags=8843 mtu 1500
> lladdr 3c:fd:fe:ed:b7:28
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (25GbaseSR full-duplex)
> status: active
> wharrels@styx2:/etc# ifconfig ixl2
> ixl2: flags=8843 mtu 1500
> lladdr 3c:fd:fe:eb:19:b0
> index 3 priority 0 llprio 3
> media: Ethernet autoselect (25GbaseSR full-duplex)
> status: active
> wharrels@styx2:/etc# ifconfig aggr1 create
> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl0
> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl2
> wharrels@styx2:/etc# ifconfig aggr1 up
> wharrels@styx2:/etc# ifconfig aggr1
> aggr1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d0:7c:e9
> index 11 priority 0 llprio 7
> trunk: trunkproto lacp
> trunk id: [(8000,fe:e1:ba:d0:7c:e9,000B,,),
>  (,00:00:00:00:00:00,,,)]
> ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9,
> key 0xb, port pri 0x8000 number 0x1
> ixl0 lacp actor state activity,aggregation,defaulted
> ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00,
> key 0x0, port pri 0x0 number 0x0
> ixl0 lacp partner state activity,aggregation,sync
> ixl0 port
> ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9,
> key 0xb, port pri 0x8000 number 0x3
> ixl2 lacp actor state activity,aggregation,defaulted
> ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00,
> key 0x0, port pri 0x0 number 0x0
> ixl2 lacp partner state activity,aggregation,sync
> ixl2 port
> groups: aggr
> media: Ethernet autoselect
> status: no carrier
>
>
> Same issue.  Anything else to try?
>
> This does work fine using trunk(4).
>
> Winfre

Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)

[Winfred Harrelson]

On Tue, Aug 11, 2020 at 10:13:41PM +0200, Remi Locherer wrote:
> On Tue, Aug 11, 2020 at 02:07:32PM -0400, Winfred Harrelson wrote:
> > I know others are using the new aggr(4) interface but I am having a
> > problem with trying to use it on some new servers I have recently
> > gotten.  Hoping I could get some help from someone here since my
> > searches have not been very fruitful.
> > 
> > First off this is on a Supermicro X11DPi-N(T) and it is running a 6.7
> > snapshot from today because the 6.7 release hangs on trying to install.
> > 
> > I have two Intel duel port XXV710 cards with SPF28 and trying to
> > create an LACP bond.  Works fine using the trunk(4) interface but
> > not the aggr(4) interface.  This is what I get:
> > 
> > styx# ifconfig ixl0
> > ixl0: flags=8843 mtu 1500
> > lladdr fe:e1:ba:d0:cc:aa
> > index 1 priority 0 llprio 3
> > trunk: trunkdev aggr1
>   ^
> ixl0 is already member of aggr1
> 
> > media: Ethernet autoselect (25GbaseSR full-duplex)
> > status: active
> > styx# ifconfig ixl2 
> > ixl2: flags=8843 mtu 1500
> > lladdr fe:e1:ba:d0:cc:aa
> > index 3 priority 0 llprio 3
> > trunk: trunkdev aggr1
>   ^
> same here

Thanks for the quick reply.

Unfortunately this is not the issue.  I had tried several attempts
before sending the email and had forgotten to clean up first before
sending the examples.  If the interface is already part of another
trunk group you will get an error attempting to add a different one.

I did a sysupgrade this morning in case something had changed and
also updated the XXV710 cards to the newest firmware but with no luck.



wharrels@styx2:/home/wharrels# dmesg | grep ^ixl
ixl0 at pci5 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:28
ixl1 at pci5 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:29
ixl2 at pci8 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b0
ixl3 at pci8 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b1
ixl4 at pci12 dev 0 function 0 "Intel X722 10GBASE-T" rev 0x09: port 0, FW 
3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f2
ixl5 at pci12 dev 0 function 1 "Intel X722 10GBASE-T" rev 0x09: port 1, FW 
3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f3

Yup, latest firmware.


wharrels@styx2:/etc# ifconfig ixl0
ixl0: flags=8843 mtu 1500
lladdr 3c:fd:fe:ed:b7:28
index 1 priority 0 llprio 3
media: Ethernet autoselect (25GbaseSR full-duplex)
status: active
wharrels@styx2:/etc# ifconfig ixl2 
ixl2: flags=8843 mtu 1500
lladdr 3c:fd:fe:eb:19:b0
index 3 priority 0 llprio 3
media: Ethernet autoselect (25GbaseSR full-duplex)
status: active
wharrels@styx2:/etc# ifconfig aggr1 create
wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl0
wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl2
wharrels@styx2:/etc# ifconfig aggr1 up
wharrels@styx2:/etc# ifconfig aggr1
aggr1: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:7c:e9
index 11 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,fe:e1:ba:d0:7c:e9,000B,,),
 (,00:00:00:00:00:00,,,)]
ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
0xb, port pri 0x8000 number 0x1
ixl0 lacp actor state activity,aggregation,defaulted
ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0
ixl0 lacp partner state activity,aggregation,sync
ixl0 port 
ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
0xb, port pri 0x8000 number 0x3
ixl2 lacp actor state activity,aggregation,defaulted
ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0
ixl2 lacp partner state activity,aggregation,sync
ixl2 port 
groups: aggr
media: Ethernet autoselect
status: no carrier


Same issue.  Anything else to try?

This does work fine using trunk(4).

Winfred

Re: 019_libssl.patch regression

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20200812130039.lto3i%stef...@sdaoden.eu>:
 |Predrag Punosevac wrote in
 | <20200811212622.ugmda%punoseva...@gmail.com>:
 ||This is a regression report for 019_libssl.patch
 ...
 ||After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
 ||longer close STARTTLS IPMI session with Gmail server. I recompiled
 ...
 |Hmm.  I can reproduce this here indeed.
 ...
 |  nail: >>> QUIT
 |  nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 - gsmtp
 |
 |And here it hangs endlessly.  For now i presume it hangs at
 |
 | while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */
 |;

I can confirm we have an endless loop in SSL_shutdown() here.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: How many IPs can I block before taking a performance hit?

[Otto Moerbeek]

On Wed, Aug 12, 2020 at 08:11:14AM -0400, Alan McKay wrote:

> Hey folks,
> 
> This is one that is difficult to test in a test environment.
> 
> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
> 
> With some scripting I'm looking at feeding block IPs to the firewalls
> to block bad-guys in near real time, but in theory if we got attacked
> by a bot net or something like that, it could result in a few thousand
> IPs being blocked.  Possibly even 10s of thousands.
> 
> Are there any real-world data out there on how big of a block list we
> can handle without impacting performance?
> 
> We're doing the standard /etc/blacklist to load a table and then have
> a block on the table right at the top of the ruleset.
> 
> thanks,
> -Alan
> 
> -- 
> "You should sit in nature for 20 minutes a day.
>  Unless you are busy, then you should sit for an hour"
>  - Zen Proverb
> 

Typical answer: "it depends".  Having in the order of 10k of rules
might not be a smart idea.  But if you are using tables you should do
fine for many, many IPs.

-Otto

Re: 019_libssl.patch regression

[Steffen Nurpmeso]

Hello Predrag, all.

Predrag Punosevac wrote in
 <20200811212622.ugmda%punoseva...@gmail.com>:
 |This is a regression report for 019_libssl.patch
 |
 |predrag@oko$ uname -a
 |OpenBSD oko.int.bagdala2.net 6.7 GENERIC.MP#5 amd64
 |predrag@oko$ syspatch -l
 |001_wscons
 |002_rpki
 |003_ssh
 |004_libssl
 |005_unbound
 |006_smtpd_sockaddr
 |007_perl
 |008_hid
 |009_asr
 |010_x509
 |011_shmget
 |012_tty
 |013_tty
 |014_iked
 |015_rpki
 |016_ximcp
 |017_dix
 |018_ximcp
 |019_libssl
 |
 |After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no
 |longer close STARTTLS IPMI session with Gmail server. I recompiled
 |s-nail and rebooted the machine. After reverting the patch s-nail works
 |as expected. Interestingly enough I can only see this with Gmail
 |servers.  019_libssl.patch doesn't break Hotmail IPMI connection. Patch
 |does break SMTP session with Gmail server in the same fashion as IPMI.
 |It just doesn't terminate cleanly. I don't know enough about the subject
 |to look further into the problem but I am 100% sure this is LibreSSL
 |bug.

Hmm.  I can reproduce this here indeed.

  nail: Resolving host smtp.gmail.com:587 ... done
  nail: Connecting to 108.177.126.109:587 ... connected.
  nail: >>> SERVER: 220 smtp.gmail.com ESMTP g9sm1477447ejf.101 - gsmtp
  nail: >>> EHLO gmail.com
  nail: >>> SERVER: 250-smtp.gmail.com at your service, [109.40.130.60]
  ...
  nail: >>> STARTTLS
  nail: >>> SERVER: 220 2.0.0 Ready to start TLS
  nail: TLS: applying config: CipherString = TLSv1.2:!aNULL:!eNULL
  nail: TLS: applying config: MinProtocol = TLSv1.2
  nail:  Certificate depth 2
  nail:   subject = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
  nail:   notBefore = Dec 15 08:00:00 2006 GMT
  nail:   notAfter = Dec 15 08:00:00 2021 GMT
  nail:   issuer = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
  nail:  Certificate depth 1
  nail:   subject = /C=US/O=Google Trust Services/CN=GTS CA 1O1
  nail:   notBefore = Jun 15 00:00:42 2017 GMT
  nail:   notAfter = Dec 15 00:00:42 2021 GMT
  nail:   issuer = /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
  nail:  Certificate depth 0
  nail:   subject = /C=US/ST=California/L=Mountain View/O=Google 
LLC/CN=smtp.gmail.com
  nail:   notBefore = Jul 15 08:33:08 2020 GMT
  nail:   notAfter = Oct  7 08:33:08 2020 GMT
  nail:   issuer = /C=US/O=Google Trust Services/CN=GTS CA 1O1
  nail: Comparing subject_alt_name: need is
  nail: TLS certificate ok
  nail: TLS SHA256 fingerprint: 
7B:2D:63:EC:E2:4C:D5:BB:33:00:A5:65:A0:67:DA:1B:C6:B8:1F:88:6E:6B:67:78:D7:6A:AC:93:94:6E:9F:9F
  nail: TLS connection using ? / AEAD-AES256-GCM-SHA384

This ? is, interesting, the "None" of

  static struct a_xtls_protocol const a_xtls_protocols[] = {
 {"ALL", SSL_OP_NO_SSL_MASK, 0, FAL0, TRU1, FAL0, TRU1, {0}},
 {"TLSv1.3\0", SSL_OP_NO_TLSv1_3, TLS1_3_VERSION, TRU1,TRU1,FAL0,FAL0,{0}},
 {"TLSv1.2", SSL_OP_NO_TLSv1_2, TLS1_2_VERSION, TRU1, TRU1, FAL0, FAL0, 
{0}},
 {"TLSv1.1", SSL_OP_NO_TLSv1_1, TLS1_1_VERSION, TRU1, TRU1, FAL0, FAL0, 
{0}},
 {"TLSv1", SSL_OP_NO_TLSv1, TLS1_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
 {"SSLv3", SSL_OP_NO_SSLv3, SSL3_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
 {"SSLv2", SSL_OP_NO_SSLv2, SSL2_VERSION, TRU1, TRU1, FAL0, FAL0, {0}},
 {"None", SSL_OP_NO_SSL_MASK, 0, TRU1, FAL0, TRU1, FAL0, {0}}
  };

after

  ver = SSL_version(sop->s_tls);
  for(xpp = &a_xtls_protocols[1] /* [0] == ALL */;; ++xpp)
 if(xpp->xp_version == ver || xpp->xp_last){
n_err(_("TLS connection using %s / %s\n"),
   (xpp->xp_last ? n_qm : xpp->xp_name),
   SSL_get_cipher(sop->s_tls));
break;
 }
   }

I have to look there when i have time, maybe!?!

  nail: >>> EHLO gmail.com
  nail: >>> SERVER: 250-smtp.gmail.com at your service, [109.40.130.60]
  ...
  nail: >>> AUTH PLAIN
  nail: >>> SERVER: 334
  ...
  nail: >>> SERVER: 354  Go ahead g9sm1477447ejf.101 - gsmtp
  ...
  nail: >>> .
  nail: >>> SERVER: 250 2.0.0 OK  1597236652 g9sm1477447ejf.101 - gsmtp
  nail: >>> QUIT
  nail: >>> SERVER: 221 2.0.0 closing connection g9sm1477447ejf.101 - gsmtp

And here it hangs endlessly.  For now i presume it hangs at

 while (!SSL_shutdown(s_tls)) /* XXX proper error handling;signals! */
;

Because the final SMTP answer has been successfully received.  But
i am a bit out of ideas at the moment since i need to -KILL it, no
other signal gets through, and our socket_close() does not catch
signals.  I will look a bit.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)

[Winfred Harrelson]

On Tue, Aug 11, 2020 at 07:52:10PM +0100, Tom Smyth wrote:
> Hi Winfred,
> the intel 710 is a complex card,  I would suggest that you try updating the
> firmware on the card, available from intel.com or your card vendor,
> you may have to boot to a live linux cd to apply the firmware update,
> 
> but I had some issues with the Intel XL710 cards and I had to update the
> firmware to get it working stable,
> 
> I hope this helps
> Tom Smyth

Adding misc@openbsd.org back to the CC for the record.

Thanks for the quick reply.  I didn't reply back yesterday because I
was having trouble getting the firmware updated from a Linux boot disk.
I ended up having to try from a Windows boot disk.  Unfortunately, I
am getting the same thing again:


wharrels@styx2:/home/wharrels# dmesg | grep ^ixl
ixl0 at pci5 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:28
ixl1 at pci5 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:29
ixl2 at pci8 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b0
ixl3 at pci8 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b1
ixl4 at pci12 dev 0 function 0 "Intel X722 10GBASE-T" rev 0x09: port 0, FW 
3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f2
ixl5 at pci12 dev 0 function 1 "Intel X722 10GBASE-T" rev 0x09: port 1, FW 
3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f3

Yup, all the XXV710 cards have been updated to newest firmware.

Now for the (failed) attempt:

wharrels@styx2:/etc# ifconfig ixl0
ixl0: flags=8843 mtu 1500
lladdr 3c:fd:fe:ed:b7:28
index 1 priority 0 llprio 3
media: Ethernet autoselect (25GbaseSR full-duplex)
status: active
wharrels@styx2:/etc# ifconfig ixl2 
ixl2: flags=8843 mtu 1500
lladdr 3c:fd:fe:eb:19:b0
index 3 priority 0 llprio 3
media: Ethernet autoselect (25GbaseSR full-duplex)
status: active
wharrels@styx2:/etc# ifconfig aggr1 create
wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl0
wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl2
wharrels@styx2:/etc# ifconfig aggr1 up
wharrels@styx2:/etc# ifconfig aggr1
aggr1: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:7c:e9
index 11 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,fe:e1:ba:d0:7c:e9,000B,,),
 (,00:00:00:00:00:00,,,)]
ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
0xb, port pri 0x8000 number 0x1
ixl0 lacp actor state activity,aggregation,defaulted
ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0
ixl0 lacp partner state activity,aggregation,sync
ixl0 port 
ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
0xb, port pri 0x8000 number 0x3
ixl2 lacp actor state activity,aggregation,defaulted
ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0
ixl2 lacp partner state activity,aggregation,sync
ixl2 port 
groups: aggr
media: Ethernet autoselect
status: no carrier



I tried doing another sysupgrade this morning just in case something
had changed overnight but no luck.  Any other ideas?

Winfred

Re: How many IPs can I block before taking a performance hit?

[Stuart Harland]

This is one of those “How long is a piece of string” examples.

You don’t give a lot in the way of specifications so as to come up with a 
reasonble guess. But the guesses are meaningless anyway, as the packet 
filtering subsystems are pretty efficient and very rapid.

In reality with sufficient CPU clock speed and memory for the state tables, you 
should be able to simultaneously block thousands and thousands, if not more.

Not particularly scientific, but there we are.

Stuart

> On 12 Aug 2020, at 13:11, Alan McKay  wrote:
> 
> Hey folks,
> 
> This is one that is difficult to test in a test environment.
> 
> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.
> 
> With some scripting I'm looking at feeding block IPs to the firewalls
> to block bad-guys in near real time, but in theory if we got attacked
> by a bot net or something like that, it could result in a few thousand
> IPs being blocked.  Possibly even 10s of thousands.
> 
> Are there any real-world data out there on how big of a block list we
> can handle without impacting performance?
> 
> We're doing the standard /etc/blacklist to load a table and then have
> a block on the table right at the top of the ruleset.
> 
> thanks,
> -Alan
> 
> -- 
> "You should sit in nature for 20 minutes a day.
> Unless you are busy, then you should sit for an hour"
> - Zen Proverb
> 

How many IPs can I block before taking a performance hit?

[Alan McKay]

Hey folks,

This is one that is difficult to test in a test environment.

I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM.

With some scripting I'm looking at feeding block IPs to the firewalls
to block bad-guys in near real time, but in theory if we got attacked
by a bot net or something like that, it could result in a few thousand
IPs being blocked.  Possibly even 10s of thousands.

Are there any real-world data out there on how big of a block list we
can handle without impacting performance?

We're doing the standard /etc/blacklist to load a table and then have
a block on the table right at the top of the ruleset.

thanks,
-Alan

-- 
"You should sit in nature for 20 minutes a day.
 Unless you are busy, then you should sit for an hour"
 - Zen Proverb

Re: can't install some packages on -current

[Stefan Hagen]

Sonic wrote:
> Fresh install of -current and I'm getting these errors when running pkg_add:
> 
> library pcap.8.4 not found
>  /usr/lib/libpcap.so.9.0 (system): bad major
> library c++.4.0 not found
>  /usr/lib/libc++.so.5.0 (system): bad major
> library c++abi.2.1 not found
>  /usr/lib/libc++abi.so.3.0 (system): bad major
>
> Ideas?

What server are you using? cdn.openbsd.org?
Try to use one of the mirrors directly.

If you use a CDN, then sysupgrade might get connected to one mirror
and pkg_add might be served by another. You might end up with a snapshot
mix as the mirrors are not synchronized at exactly the same time.

Best Regards,
Stefan

Re: Adding more syspatch platform.

[Stuart Henderson]

The only proxy we have for "what is really used" is dmesg submissions.
Since 6.7 release:

amd64   62
i3865
arm64   3
macppc  2
octeon  1

Based on this there isn't a great case for adding any more.