"Dump device" is only partition never swap file right? Deliberate or onl f historic reasons?

[Tinker]

Hi,

I normally won't use any swap, and if it gets utilized then low
performance would be fine, so normally using a swap file would be
satisfactory for all my swap needs.

That is, if it was not for OS crash dumps. I like to catch those (to
encrypted media) as they can provide insight into the reasons for
system crash e.g. resolve hardware instability or kernel bug.

Dumps are stored to the "dump device", which is the swap partition on
the system disk - and that has the consequence that dumps never are
stored to swap files, right?

Is there a deliberate thought here that a crash could happen in the
filesystem logics so therefore better write dumps only directly to
partitions, or is this for historic reasons only e.g. noone bothered
consider giving "dump device" a wider definition?

http://man.openbsd.org/OpenBSD-6.2/crash
http://man.openbsd.org/OpenBSD-6.2/savecore
http://man.openbsd.org/OpenBSD-6.2/swapon

Thanks,
Tinker

Re: [Patch] remove xdm reference from X(7)

[Anthony J. Bentley]

Solene Rapenne writes:
> Hello
>
> I don't know if it's the right place to submit a diff.
>
> The man page X(7) refers to xdm(1) in "SEE ALSO".

Thanks, but X(7) comes from upstream. Typically we don't modify upstream
manuals in Xenocara, as doing so would add more work to X updates.
Improvements to OpenBSD-maintained docs like cwm(1) and xenodm(1) are
welcome though.

> I also found that the first line of the file is a comment with a
> character 't' alone.

Manpages often do that as a marker to run the tbl preprocessor
(similarly with 'e' for eqn, and so on).

-- 
Anthony J. Bentley

Re: How recursive copy to clone OS installation (devices, links, owners, privileges etc.)?

[Nick Holland]

On 03/14/18 21:08, Tinker wrote:
> Say you have an OpenBSD installation (with /dev and all) mounted on
> /mnt , and you'd like to clone it to /mnt2 , which is a partition
> of different size, so dd is not an option.

Not necessarily true.
If the source is smaller than the destination, you can still image it
with "dd", rsdXc partition to rsdXc partition.  You can then use
"growfs" to expand the last partition -- if you planned it right, your
last partition is the one that needs the most space.

You can also dd over individual partitions.  Create a new 'a' partition,
copy over the 'a' partition (/dev/rsdXa) first, now make a /new/ disk
label (that's stored in the 'a' partition, so copying over 'a' blew your
old one away -- order here is kinda important), make all the new
partitions the size you want them to be, then dd them over from the
source to the dest, then growfs each of them to fluff them out to the
size you got.

Not saying it's the best way to do things, but it's educational. :)

Nick.

Re: 6.2 song?

[jungle Boogie]

On Mar 14, 2018 6:41 PM, "Stuart Henderson"  wrote:
>
> On 2018-03-15, jungle boogie  wrote:
> > Thus said Jungle Boogie on Sun, 31 Dec 2017 14:07:31 -0800
> >> Hi All,
> >>
> >> There's only a few more hours remaining in 2017, at least in my time
> >> zone, are we going to get the 6.2 song before then?
> >>
> >> https://www.openbsd.org/62.html
> >>
> >> Thanks and happy new year!
> >>
> >
> > Hi again.
> >
> > Here we are on pi day and unfortunately, I can't celebrate it - there's
> > still no 6.2 song.
> >
> > As openBSD is very good with documentation, can the reference to the
> > song be removed?
> > https://www.openbsd.org/62.html
> >
> >
> >
> >
> >
>
> it doesn't say which December.

Yes, good point!

>
> (and I don't really see why 14/3/2018 would be "pi day"...)
>
>
Also true. But if we both use iso8601, it's a little more obvious. ;)
Except we would need to drop the first five digits.

Re: 6.2 song?

[Stuart Henderson]

On 2018-03-15, jungle boogie  wrote:
> Thus said Jungle Boogie on Sun, 31 Dec 2017 14:07:31 -0800
>> Hi All,
>> 
>> There's only a few more hours remaining in 2017, at least in my time
>> zone, are we going to get the 6.2 song before then?
>> 
>> https://www.openbsd.org/62.html
>> 
>> Thanks and happy new year!
>> 
>
> Hi again.
>
> Here we are on pi day and unfortunately, I can't celebrate it - there's 
> still no 6.2 song.
>
> As openBSD is very good with documentation, can the reference to the 
> song be removed?
> https://www.openbsd.org/62.html
>
>
>
>
>

it doesn't say which December.

(and I don't really see why 14/3/2018 would be "pi day"...)

Re: 6.2 song?

[jungle boogie]

Thus said Jungle Boogie on Sun, 31 Dec 2017 14:07:31 -0800

Hi All,

There's only a few more hours remaining in 2017, at least in my time
zone, are we going to get the 6.2 song before then?

https://www.openbsd.org/62.html

Thanks and happy new year!



Hi again.

Here we are on pi day and unfortunately, I can't celebrate it - there's 
still no 6.2 song.


As openBSD is very good with documentation, can the reference to the 
song be removed?

https://www.openbsd.org/62.html

Re: How recursive copy to clone OS installation (devices, links, owners, privileges etc.)?

[Philip Guenther]

On Wed, Mar 14, 2018 at 6:08 PM, Tinker  wrote:

> Say you have an OpenBSD installation (with /dev and all) mounted on
> /mnt , and you'd like to clone it to /mnt2 , which is a partition
> of different size, so dd is not an option.
>
> For simplicity of the example both the source and destination OS
> installations are on single ffs partitions, e.g. /mnt hosts /dev/sd1a
> which is sd1's only partition, and /mnt2 hosts /dev/sd2a which is sd2's
> only partition.
>
> Can you make cp or some other recursive copying tool properly replicate
> device files, links, file privileges and attributes, user and group
> ownership, and maybe even creation and modification times, so the
> copying together will make /mnt2 a complete and bootable replica of
> /mnt ?
>

Ignoring the "bootable" qualifier which is more about disklabel and
installboot:

cd /mnt && pax -rwpe . /mnt2


Philip Guenther

(Replies that are mangled by protonmail will be ignored.)

PF redirect traffic to TUN/VPN

[Martin Hanson]

Hi,� I have an OpenBSD box setup as a firewall and gateway with DHCP.� I
was thinking about adding VPN to the box.� Is it possible to install
OpenVPN, establish a tunnel via a third partyVPN provider (like PIA), and
then have PF redirect some traffic throughthat tunnel based upon IP
addresses, but not all traffic?� So traffic coming from 192.168.1.2 goes
through the VPN tunnelinterface on the OpenBSD gateway, but traffic from
192.168.1.3 does not?� I am asking because normally all traffic is forced
through the VPNtunnel.� Maybe this isn't related to PF at all?� Kind
regards� Martin

How recursive copy to clone OS installation (devices, links, owners, privileges etc.)?

[Tinker]

Say you have an OpenBSD installation (with /dev and all) mounted on
/mnt , and you'd like to clone it to /mnt2 , which is a partition
of different size, so dd is not an option.

For simplicity of the example both the source and destination OS
installations are on single ffs partitions, e.g. /mnt hosts /dev/sd1a
which is sd1's only partition, and /mnt2 hosts /dev/sd2a which is sd2's
only partition.

Can you make cp or some other recursive copying tool properly replicate
device files, links, file privileges and attributes, user and group
ownership, and maybe even creation and modification times, so the
copying together will make /mnt2 a complete and bootable replica of
/mnt ?

(Of course /mnt2 also needs proper treatment with fdisk, disklabel,
newfs, installboot.)

At the end of the day is copying a good idea at all or are there
notorious failure points in the process such that OS reinstall or disk
image cloning are prefered?

Thanks,
Tinker

Re: Flow Tools

[Diana Eichert]

I 2nd nfdump, then again I like tcpdump too ;-)

On Wed, 14 Mar 2018, Daniel Melameth wrote:


On Wed, Mar 14, 2018 at 3:06 AM, Gregory Edigarov  wrote:

Sorry, if I hijack the thread, but what do you guys use for netflow
analysis?
Only know nfsen in ports, but sometimes I need more versatile tool.


nfdump is rather powerful if you don't need a pretty GUI; it's like
tcpdump, but for NetFlow/IPFIX data.  I have it scripted to produce
regular reports, but also run it ad hoc.

Re: scsi_xfer pool exhausted

[Tor Houghton]

On Wed, Mar 14, 2018 at 05:56:19PM +0100, Tor Houghton wrote:
> On Tue, Mar 13, 2018 at 11:23:12PM -0700, Peter van Oord v/d Vlies wrote:
> > Hello Martijn,
> > 
> > Did you ever found an solution ?
> > I have the same at a customer system.
> > 
> 
> I'd like to chip in with a "me too" here. It's "suddenly" started happening
> to my apu2c2 device.
> 
> I say "suddenly" because it started happening after I did syspatch on a
> default 6.2 amd64 install.
> 

I finally had time to babysit the host, and it appears that the root cause
for my issue was a cron job (ftp client) that didn't gracefully handle error
situations (remote host not responding properly to https://, resulting in
far too many ftp processes..). Assumptions lead to poor error handling and ..
causation, correlation - yeah. 

(I am sure someone will know why this would trigger a scsi message.)

Sorry for the noise,

Tor

Re: OSPF over gif on top of IPsec transport -current

[Claudio Jeker]

On Wed, Mar 14, 2018 at 07:07:36PM +, csszep wrote:
> Hi!
> 
> Will this fix be commit before 6.3 release?
> 

Yes something like this will need to be put into 6.3 since this is
currently a regression from 6.2.

> David Gwynne  ezt írta (id??pont: 2018. márc. 13., K 23:41):
> 
> >
> > > On 10 Mar 2018, at 08:01, Remi Locherer  wrote:
> > >
> > >
> > > With below diff the setup works as expected: tcpdump shows OSPF hellos
> > > on gif0 and ospfd sees the neighbour.
> > >
> > > I don't think it's the correct fix though.
> >
> > functionally it is the correct fix.
> >
> > when i reworked gif(4) in src/sys/net/if_gif.c r1.108, i merged the ipv4
> > and ipv6 input paths. the ipv6 input code had this check, but ipv4 did not.
> > now it is applied to ipv4, but it is obviously wrong for both address
> > families.
> >
> > please commit the removal of this check, ok by me.
> >
> > thank you to everyone for the but report and debugging. i'm sorry for
> > taking so long to figure this out.
> >
> > dlg
> >
> > >
> > >
> > > Index: if_gif.c
> > > ===
> > > RCS file: /cvs/src/sys/net/if_gif.c,v
> > > retrieving revision 1.112
> > > diff -u -p -r1.112 if_gif.c
> > > --- if_gif.c  28 Feb 2018 23:28:05 -  1.112
> > > +++ if_gif.c  9 Mar 2018 20:52:46 -
> > > @@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct
> > >   }
> > >
> > >   /* XXX What if we run transport-mode IPsec to protect gif tunnel ?
> > */
> > > - if (m->m_flags & (M_AUTH | M_CONF))
> > > - return (-1);
> > > + //if (m->m_flags & (M_AUTH | M_CONF))
> > > + //  return (-1);
> > >
> > >   key->t_rtableid = m->m_pkthdr.ph_rtableid;
> >
> >

-- 
:wq Claudio

Re: Meltdown workaround enabled?

[Stuart Henderson]

On 2018-03-13, Brian Camp  wrote:
> Thats actually the latest version. Even though this board is made by
> Intel itself, they have yet to release a BIOS update with the patched
> microcode that other OEMs are shipping.

BTW, they're actually ECS boards.

> re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H
> (0x5400), msi, address 94:c6:91:19:ab:cb

The clue is here ^^

Re: OSPF over gif on top of IPsec transport -current

[csszep]

Hi!

Will this fix be commit before 6.3 release?

Thx
csszep

David Gwynne  ezt írta (időpont: 2018. márc. 13., K 23:41):

>
> > On 10 Mar 2018, at 08:01, Remi Locherer  wrote:
> >
> >
> > With below diff the setup works as expected: tcpdump shows OSPF hellos
> > on gif0 and ospfd sees the neighbour.
> >
> > I don't think it's the correct fix though.
>
> functionally it is the correct fix.
>
> when i reworked gif(4) in src/sys/net/if_gif.c r1.108, i merged the ipv4
> and ipv6 input paths. the ipv6 input code had this check, but ipv4 did not.
> now it is applied to ipv4, but it is obviously wrong for both address
> families.
>
> please commit the removal of this check, ok by me.
>
> thank you to everyone for the but report and debugging. i'm sorry for
> taking so long to figure this out.
>
> dlg
>
> >
> >
> > Index: if_gif.c
> > ===
> > RCS file: /cvs/src/sys/net/if_gif.c,v
> > retrieving revision 1.112
> > diff -u -p -r1.112 if_gif.c
> > --- if_gif.c  28 Feb 2018 23:28:05 -  1.112
> > +++ if_gif.c  9 Mar 2018 20:52:46 -
> > @@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct
> >   }
> >
> >   /* XXX What if we run transport-mode IPsec to protect gif tunnel ?
> */
> > - if (m->m_flags & (M_AUTH | M_CONF))
> > - return (-1);
> > + //if (m->m_flags & (M_AUTH | M_CONF))
> > + //  return (-1);
> >
> >   key->t_rtableid = m->m_pkthdr.ph_rtableid;
>
>

Re: relayd stops processing traffic intermittently

[Claudio Jeker]

On Wed, Mar 14, 2018 at 04:27:58PM +0100, Mischa wrote:
> Hi Claudio,
> 
> > On 25 Dec 2017, at 15:54, Mischa  wrote:
> > 
> >> On 24 Dec 2017, at 19:07, Claudio Jeker  wrote:
> >> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
>  On 23 Dec 2017, at 13:08, Claudio Jeker  wrote:
> > On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
> > Hi All,
> > 
> > Since OpenBSD 6.2, just confirmed this in the latest snapshot 
> > (GENERIC.MP#305) as well, for some reason relayd stops processing 
> > traffic and starts flooding the log file with the following message:
> > 
> > Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > [snip]
> > Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> > Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > ...etc...
> > 
> > Restarting the daemon "fixes" the problem.
> > Not sure how to trouble shoot this but I am able to reproduce this 
> > consistently by pointing SSLLabs towards relayd.
> > Would be great to get some pointers.
> > 
>  
>  I have seen this as well on our production systems. This is a problem in
>  the privsep part of the TLS code. I could not do more testing yet but my
>  assumption is that a new option / feature is freaking this code out.
> >>> 
> >>> Anything I can do or collect to give you more information? 
> >> 
> >> So, I think I found the problem. The ca process did not handle errors from
> >> RSA_private_encrypt correctly. So once you got a bad signature in the
> >> system chocked and stopped. This diff seems to work for me (against
> >> SSLlabs).
> > 
> > Awesome! Can confirm that it continues processing traffic when hitting it 
> > with sslabs.
> > Will also move it to a more bussier machine to see how that handles.
> > 
> > I am seeing the following messages now:
> > Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa 
> > routines:CRYPTO_internal:block type is not 02
> > Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa 
> > routines:CRYPTO_internal:null before block missing
> > Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa 
> > routines:CRYPTO_internal:padding check failed
> > Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa 
> > routines:CRYPTO_internal:null before block missing
> 
> Not sure if this is supposed to be taken care of, but I am still seeing the 
> following messages in 6.3-beta.
> $ uname -a
> OpenBSD lb2l 6.3 GENERIC.MP#58 amd64
> 
> Mar 13 23:43:38 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF06B:rsa 
> routines:CRYPTO_internal:block type is not 02
> Mar 13 23:43:39 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF072:rsa 
> routines:CRYPTO_internal:padding check failed
> Mar 13 23:43:48 lb2 relayd[14775]: ca_dispatch_relay: error:04FFF06B:rsa 
> routines:CRYPTO_internal:block type is not 02
> Mar 13 23:44:03 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF071:rsa 
> routines:CRYPTO_internal:null before block missing
> 
> Any knobs that need to be turned?

Unsure. The errors are from OpenSSL and explain why the key exchange blew
up. Currently this resets the connection.
I wanted to log them so they are more visible. Somebody with deep
knowledge of TLS and libcrypto may be able to answer if those are harmless
or if somebody is probing.

-- 
:wq Claudio

Re: Flow Tools

[Daniel Melameth]

On Wed, Mar 14, 2018 at 3:06 AM, Gregory Edigarov  wrote:
> Sorry, if I hijack the thread, but what do you guys use for netflow
> analysis?
> Only know nfsen in ports, but sometimes I need more versatile tool.

nfdump is rather powerful if you don't need a pretty GUI; it's like
tcpdump, but for NetFlow/IPFIX data.  I have it scripted to produce
regular reports, but also run it ad hoc.

[Patch] remove xdm reference from X(7)

[Solene Rapenne]

Hello

I don't know if it's the right place to submit a diff.

The man page X(7) refers to xdm(1) in "SEE ALSO".

I also found that the first line of the file is a comment with a
character 't' alone.


Index: X.man
===
RCS file: /cvs/xenocara/doc/xorg-docs/man/X.man,v
retrieving revision 1.4
diff -u -p -r1.4 X.man
--- X.man   30 Aug 2015 13:32:02 -  1.4
+++ X.man   14 Mar 2018 17:43:15 -
@@ -1,4 +1,3 @@
-.\" t
 .\"
 .\" Copyright (c) 1994, 2004  The Open Group
 .\" Copyright \(co 2000  The XFree86 Project, Inc.
@@ -1217,7 +1216,6 @@ the appropriate instance name can be pla
 .BR xclock (__appmansuffix__),
 .BR xcmsdb (__appmansuffix__),
 .BR xconsole (__appmansuffix__),
-.BR xdm (__appmansuffix__),
 .BR xdpyinfo (__appmansuffix__),
 .BR xfd (__appmansuffix__),
 .BR xfs (__appmansuffix__),

Re: scsi_xfer pool exhausted

[Tor Houghton]

On Tue, Mar 13, 2018 at 11:23:12PM -0700, Peter van Oord v/d Vlies wrote:
> Hello Martijn,
> 
> Did you ever found an solution ?
> I have the same at a customer system.
> 

I'd like to chip in with a "me too" here. It's "suddenly" started happening
to my apu2c2 device.

I say "suddenly" because it started happening after I did syspatch on a
default 6.2 amd64 install.

I reverted all the patches (syspatch -r a few times), but it seems it has
not helped. Usually ends up dumping "scsi_xfer pool exhausted!" repeatedly
on the console after some time (seems like about an hour or two).

dmesg attached (unsure why pid 1 got the signal it got..)

Tor

$ ls -lart /var/syspatch/  
total 8
drwxr-xr-x  24 root  wheel  512 Oct  4 05:13 ..
drwxr-xr-x   2 root  wheel  512 Mar 14 08:26 .

$ cat /var/run/dmesg.boot  
OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct  3 21:22:29 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1996152832 (1903MB)
avail mem = 1928699904 (1839MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x77fb7020 (7 entries)
bios0: vendor coreboot version "4.0.7" date 02/28/2017
bios0: PC Engines APU2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) 
UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.28 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: TSC frequency 998275150 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.20 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.15 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.36 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins
, remapped to apid 5
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PBR4)
acpiprt2 at acpi0: bus 1 (PBR5)
acpiprt3 at acpi0: bus 2 (PBR6)
acpiprt4 at acpi0: bus 3 (PBR7)
acpiprt5 at acpi0: bus -1 (PBR8)
acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS
acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS

notes from before and after a BIOS upgrade

[Andrew]

First, and as always, I want to express my appreciation to Theo and to 
all the past and present devs. The world is not full of bunny rabbits 
and wildflowers ...


---

I have a refurb Lenovo T420 off ebay with a very old BIOS from 2011.
Nice refurb, eh ?? Here are some before and after notes based on the
previous "meltdown" thread. Thanks also to Chris for sharing that github
link. I present this for the benefit of others. Good luck out there ;-)

---

$> uname -vprs
OpenBSD 6.3 GENERIC.MP#48 amd64

$> dmesg | grep -i bios0 | sort -u
acpi0 at bios0: rev 2
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries)
bios0: LENOVO 41786UU
bios0: vendor LENOVO version "83ET63WW (1.33 )" date 07/29/2011

$> doas ./meltdown -v
CPU has RDTSCP
CPU has no TSX support!
Access time: memory 300, cache 107 -> threshold 203
Using addr 0x81864f90 for symbol '_version'.
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0010?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0020?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0030?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0040?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0050?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0060?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0070?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??   
0080?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
matched 0% (0 of 138 bytes)
System is not vulnerable to meltdown
53 70 65 63 69 61 6c 20 45 78 65 63 75 74 69 76   Special Executiv
001065 20 66 6f 72 20 43 6f 75 6e 74 65 72 69 6e 74   e for Counterint
002065 6c 6c 69 67 65 6e 63 65 2c 20 54 65 72 72 6f   elligence, Terro
003072 69 73 6d 2c 20 52 65 76 65 6e 67 65 20 61 6e   rism, Revenge an
004064 20 45 78 74 6f 72 74 69 6f 6e 2e   d Extortion.
matched 100% (76 of 76 bytes)
System is vulnerable to spectre

$> cpuid 0x0  
eax = 0x000d13""

ebx = 0x756e65471970169159"Genu"
ecx = 0x6c65746e1818588270"ntel"
edx = 0x49656e691231384169"ineI"

$> cpuid 0x7
eax = 0x 0""
ebx = 0x 0""
ecx = 0x 0""
edx = 0x 0""

$> dmesg | grep -i ^cpu[0-3] | sort -u
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600, 
1400, 1200, 1000, 800 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.23 MHz
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.26 MHz
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.30 MHz
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.31 MHz
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu0: smt 0, core 0, package 0
cpu1 at mainbus0: apid 1 (application processor)
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz
cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu3: smt 1, core 1, package 0


# NEW 

Re: relayd stops processing traffic intermittently

[Mischa]

Hi Tom!

Before, relayd would just "crash" and a reload was "solving" the problem.
In this instance it's luckily just extra logging. ;)

Mischa

> On 14 Mar 2018, at 16:47, Tom Smyth  wrote:
> 
> Hi all
> I have had that issue  in 6.0,6.1 and 6.2 I haven't tried current yet..
> I haven't had enough time to diagnose it to provide an adequate
> bug report myself.
> just restarting relayd seems to resolve it
> Im just confiming that I have seen this issue also ...
> 
> On 14 March 2018 at 15:27, Mischa  wrote:
>> Hi Claudio,
>> 
>>> On 25 Dec 2017, at 15:54, Mischa  wrote:
>>> 
 On 24 Dec 2017, at 19:07, Claudio Jeker  wrote:
 On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
>> On 23 Dec 2017, at 13:08, Claudio Jeker  wrote:
>>> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
>>> Hi All,
>>> 
>>> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
>>> (GENERIC.MP#305) as well, for some reason relayd stops processing 
>>> traffic and starts flooding the log file with the following message:
>>> 
>>> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>>> [snip]
>>> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>>> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>>> ...etc...
>>> 
>>> Restarting the daemon "fixes" the problem.
>>> Not sure how to trouble shoot this but I am able to reproduce this 
>>> consistently by pointing SSLLabs towards relayd.
>>> Would be great to get some pointers.
>>> 
>> 
>> I have seen this as well on our production systems. This is a problem in
>> the privsep part of the TLS code. I could not do more testing yet but my
>> assumption is that a new option / feature is freaking this code out.
> 
> Anything I can do or collect to give you more information?
 
 So, I think I found the problem. The ca process did not handle errors from
 RSA_private_encrypt correctly. So once you got a bad signature in the
 system chocked and stopped. This diff seems to work for me (against
 SSLlabs).
>>> 
>>> Awesome! Can confirm that it continues processing traffic when hitting it 
>>> with sslabs.
>>> Will also move it to a more bussier machine to see how that handles.
>>> 
>>> I am seeing the following messages now:
>>> Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa 
>>> routines:CRYPTO_internal:block type is not 02
>>> Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa 
>>> routines:CRYPTO_internal:null before block missing
>>> Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa 
>>> routines:CRYPTO_internal:padding check failed
>>> Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa 
>>> routines:CRYPTO_internal:null before block missing
>> 
>> Not sure if this is supposed to be taken care of, but I am still seeing the 
>> following messages in 6.3-beta.
>> $ uname -a
>> OpenBSD lb2l 6.3 GENERIC.MP#58 amd64
>> 
>> Mar 13 23:43:38 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF06B:rsa 
>> routines:CRYPTO_internal:block type is not 02
>> Mar 13 23:43:39 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF072:rsa 
>> routines:CRYPTO_internal:padding check failed
>> Mar 13 23:43:48 lb2 relayd[14775]: ca_dispatch_relay: error:04FFF06B:rsa 
>> routines:CRYPTO_internal:block type is not 02
>> Mar 13 23:44:03 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF071:rsa 
>> routines:CRYPTO_internal:null before block missing
>> 
>> Any knobs that need to be turned?
>> 
>> Mischa
>> 
> 
> 
> 
> -- 
> Kindest regards,
> Tom Smyth
> 
> Mobile: +353 87 6193172
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.

Re: relayd stops processing traffic intermittently

[Tom Smyth]

Hi all
I have had that issue  in 6.0,6.1 and 6.2 I haven't tried current yet..
I haven't had enough time to diagnose it to provide an adequate
bug report myself.
just restarting relayd seems to resolve it
Im just confiming that I have seen this issue also ...

On 14 March 2018 at 15:27, Mischa  wrote:
> Hi Claudio,
>
>> On 25 Dec 2017, at 15:54, Mischa  wrote:
>>
>>> On 24 Dec 2017, at 19:07, Claudio Jeker  wrote:
>>> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
> On 23 Dec 2017, at 13:08, Claudio Jeker  wrote:
>> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
>> Hi All,
>>
>> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
>> (GENERIC.MP#305) as well, for some reason relayd stops processing 
>> traffic and starts flooding the log file with the following message:
>>
>> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> [snip]
>> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> ...etc...
>>
>> Restarting the daemon "fixes" the problem.
>> Not sure how to trouble shoot this but I am able to reproduce this 
>> consistently by pointing SSLLabs towards relayd.
>> Would be great to get some pointers.
>>
>
> I have seen this as well on our production systems. This is a problem in
> the privsep part of the TLS code. I could not do more testing yet but my
> assumption is that a new option / feature is freaking this code out.

 Anything I can do or collect to give you more information?
>>>
>>> So, I think I found the problem. The ca process did not handle errors from
>>> RSA_private_encrypt correctly. So once you got a bad signature in the
>>> system chocked and stopped. This diff seems to work for me (against
>>> SSLlabs).
>>
>> Awesome! Can confirm that it continues processing traffic when hitting it 
>> with sslabs.
>> Will also move it to a more bussier machine to see how that handles.
>>
>> I am seeing the following messages now:
>> Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa 
>> routines:CRYPTO_internal:block type is not 02
>> Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa 
>> routines:CRYPTO_internal:null before block missing
>> Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa 
>> routines:CRYPTO_internal:padding check failed
>> Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa 
>> routines:CRYPTO_internal:null before block missing
>
> Not sure if this is supposed to be taken care of, but I am still seeing the 
> following messages in 6.3-beta.
> $ uname -a
> OpenBSD lb2l 6.3 GENERIC.MP#58 amd64
>
> Mar 13 23:43:38 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF06B:rsa 
> routines:CRYPTO_internal:block type is not 02
> Mar 13 23:43:39 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF072:rsa 
> routines:CRYPTO_internal:padding check failed
> Mar 13 23:43:48 lb2 relayd[14775]: ca_dispatch_relay: error:04FFF06B:rsa 
> routines:CRYPTO_internal:block type is not 02
> Mar 13 23:44:03 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF071:rsa 
> routines:CRYPTO_internal:null before block missing
>
> Any knobs that need to be turned?
>
> Mischa
>



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: relayd stops processing traffic intermittently

[Mischa]

Hi Claudio,

> On 25 Dec 2017, at 15:54, Mischa  wrote:
> 
>> On 24 Dec 2017, at 19:07, Claudio Jeker  wrote:
>> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
 On 23 Dec 2017, at 13:08, Claudio Jeker  wrote:
> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
> Hi All,
> 
> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
> (GENERIC.MP#305) as well, for some reason relayd stops processing traffic 
> and starts flooding the log file with the following message:
> 
> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> [snip]
> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> ...etc...
> 
> Restarting the daemon "fixes" the problem.
> Not sure how to trouble shoot this but I am able to reproduce this 
> consistently by pointing SSLLabs towards relayd.
> Would be great to get some pointers.
> 
 
 I have seen this as well on our production systems. This is a problem in
 the privsep part of the TLS code. I could not do more testing yet but my
 assumption is that a new option / feature is freaking this code out.
>>> 
>>> Anything I can do or collect to give you more information? 
>> 
>> So, I think I found the problem. The ca process did not handle errors from
>> RSA_private_encrypt correctly. So once you got a bad signature in the
>> system chocked and stopped. This diff seems to work for me (against
>> SSLlabs).
> 
> Awesome! Can confirm that it continues processing traffic when hitting it 
> with sslabs.
> Will also move it to a more bussier machine to see how that handles.
> 
> I am seeing the following messages now:
> Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa 
> routines:CRYPTO_internal:block type is not 02
> Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa 
> routines:CRYPTO_internal:null before block missing
> Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa 
> routines:CRYPTO_internal:padding check failed
> Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa 
> routines:CRYPTO_internal:null before block missing

Not sure if this is supposed to be taken care of, but I am still seeing the 
following messages in 6.3-beta.
$ uname -a
OpenBSD lb2l 6.3 GENERIC.MP#58 amd64

Mar 13 23:43:38 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF06B:rsa 
routines:CRYPTO_internal:block type is not 02
Mar 13 23:43:39 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF072:rsa 
routines:CRYPTO_internal:padding check failed
Mar 13 23:43:48 lb2 relayd[14775]: ca_dispatch_relay: error:04FFF06B:rsa 
routines:CRYPTO_internal:block type is not 02
Mar 13 23:44:03 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF071:rsa 
routines:CRYPTO_internal:null before block missing

Any knobs that need to be turned?

Mischa

Re: Flow Tools

[Tommy Nevtelen]

On 03/14/2018 10:06 AM, Gregory Edigarov wrote:
> Sorry, if I hijack the thread, but what do you guys use for netflow
> analysis?

This looks quite interesting https://github.com/robcowart/elastiflow
I have not tried it but would like to when time allows.

-- 
Tommy Nevtelen

Re: Meltdown workaround enabled?

[Christian Weisgerber]

On 2018-03-14, "Robert Paschedag"  wrote:

> Errdo I get it right, that a possibly vulnerable CPU
> (from 2016) is still vulnerable to MELTDOWN but a newer
> BIOS *fakes* the CPU flags so the MELTDOWN "detection code"
> says, "this CPU is NOT vulnerable"
>
> Is that right?

The newer BIOS includes new microcode.  As reported by the cpuid 7
edx return, this microcode adds:

- IBRS/IBPB speculation control
- STIBP speculation control
  These can be used by the operating system to mitigate Spectre
  V2 vulnerabilities.

- IA32_ARCH_CAPABILITIES model-specific register
  - RDCL_NO indicator
  This indicates that the CPU is not vulnerable to Meltdown (V3).

The gracious assumption is that the CPU (Apollo Lake/Goldmont)
either wasn't vulnerable to Meltdown in the first place or that it
could be fixed by the new microcode.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Meltdown workaround enabled?

[Bob Beck]

On Wed, Mar 14, 2018 at 05:38 Robert Paschedag 
wrote:

>
> > Gesendet: Mittwoch, 14. März 2018 um 06:13 Uhr
> > Von: "Bob Beck" 
> > An: "Brian Camp" 
> > Cc: "Theo de Raadt" , misc@openbsd.org
> > Betreff: Re: Meltdown workaround enabled?
> >
> > Intel make kitty scared...  What a fuckmess.
>
> Errdo I get it right, that a possibly vulnerable CPU
> (from 2016) is still vulnerable to MELTDOWN but a newer
> BIOS *fakes* the CPU flags so the MELTDOWN "detection code"
> says, "this CPU is NOT vulnerable"
>
> Is that right?
>
> Robert
>


Just consume the broken crap like a good citizen.  Intel is too big to fail
so thinking about these things is bad for society. Right?



> >
> > On Tue, Mar 13, 2018 at 22:57 Brian Camp  wrote:
> >
> > > On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt 
> > > wrote:
> > > >> According to some sources, Intel and a handful of others have known
> > > about the
> > > >> issue since February 2017(!), so perhaps it has already been
> patched in
> > > the
> > > >> 08Jan2018 BIOS. I too have doubts that to date any processor has
> been
> > > >> redesigned to avoid the flaws entirely, but then again...
> > > >
> > > > Sure.  A BIOS can change the flag bits.
> > > >
> > > > Be nice to know.  Did a BIOS change them?
> > >
> > > I downgraded the bios to try and figure this out. Going back just one
> > > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and
> > > -current's MELTDOWN workaround to activate.
> > >
> > > Previous BIOS revision (12/18/2017):
> > > bcamp@nuc6cayh:~ (OpenBSD 6.3)
> > > $ cpuid 0x7
> > > eax = 0x 0""
> > > ebx = 0x2294e283 580182659"???""
> > > ecx = 0x 0""
> > > edx = 0x 0""
> > >
> > > Newest BIOS revision (1/8/2018):
> > > bcamp@nuc6cayh:~ (OpenBSD 6.3)
> > > $  cpuid 0x7
> > > eax = 0x 0""
> > > ebx = 0x2294e283 580182659"???""
> > > ecx = 0x 0""
> > > edx = 0x2c00 738197504"???,"
> > >
> > >
> >
>
>

Re: scsi_xfer pool exhausted

[Peter van Oord v/d Vlies]

Hello Martijn,

Did you ever found an solution ?
I have the same at a customer system.



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: Meltdown workaround enabled?

[Robert Paschedag]

> Gesendet: Mittwoch, 14. März 2018 um 06:13 Uhr
> Von: "Bob Beck" 
> An: "Brian Camp" 
> Cc: "Theo de Raadt" , misc@openbsd.org
> Betreff: Re: Meltdown workaround enabled?
>
> Intel make kitty scared...  What a fuckmess.

Errdo I get it right, that a possibly vulnerable CPU
(from 2016) is still vulnerable to MELTDOWN but a newer
BIOS *fakes* the CPU flags so the MELTDOWN "detection code"
says, "this CPU is NOT vulnerable"

Is that right?

Robert

> 
> On Tue, Mar 13, 2018 at 22:57 Brian Camp  wrote:
> 
> > On Tue, Mar 13, 2018 at 10:39 PM, Theo de Raadt 
> > wrote:
> > >> According to some sources, Intel and a handful of others have known
> > about the
> > >> issue since February 2017(!), so perhaps it has already been patched in
> > the
> > >> 08Jan2018 BIOS. I too have doubts that to date any processor has been
> > >> redesigned to avoid the flaws entirely, but then again...
> > >
> > > Sure.  A BIOS can change the flag bits.
> > >
> > > Be nice to know.  Did a BIOS change them?
> >
> > I downgraded the bios to try and figure this out. Going back just one
> > revision (1/8/2018 to 12/18/2017) causes it to lose the flag and
> > -current's MELTDOWN workaround to activate.
> >
> > Previous BIOS revision (12/18/2017):
> > bcamp@nuc6cayh:~ (OpenBSD 6.3)
> > $ cpuid 0x7
> > eax = 0x 0""
> > ebx = 0x2294e283 580182659"???""
> > ecx = 0x 0""
> > edx = 0x 0""
> >
> > Newest BIOS revision (1/8/2018):
> > bcamp@nuc6cayh:~ (OpenBSD 6.3)
> > $  cpuid 0x7
> > eax = 0x 0""
> > ebx = 0x2294e283 580182659"???""
> > ecx = 0x 0""
> > edx = 0x2c00 738197504"???,"
> >
> >
>

Re: Flow Tools

[Steve Pointer]

On Wed, 14 Mar 2018, at 9:06 AM, Gregory Edigarov wrote:
> Sorry, if I hijack the thread, but what do you guys use for netflow 
> analysis?
> Only know nfsen in ports, but sometimes I need more versatile tool.
> 

R  works for me.

https://www.r-project.org/

--
Steve P

Re: Flow Tools

[Gregory Edigarov]

Sorry, if I hijack the thread, but what do you guys use for netflow 
analysis?

Only know nfsen in ports, but sometimes I need more versatile tool.

On 13.03.18 20:35, Diana Eichert wrote:

I've been using samplicator to fanout UDP flow data for years.

https://github.com/sleinen/samplicator

diana


On Tue, 13 Mar 2018, Paul Ammann wrote:


Hi

I've got a problem and I'm hoping OBSD may be able to solve my problem.

We bought new firewalls in 2017, but they can only send flow traffic 
to a single destination. We need to send flow traffic to 3 destinations.


I have a copy of Michael Lucas' book Network Flow Analysis, and I've 
been reading about flow-tools and flowd. Unfortunately there doesn't 
seem to have been a lot of development on these tools since 2010.


Are there any other tools that I may have missed that would help me 
solve my problem?


Thank you in advanced.

Paul

Re: The vim display issue on OpenBSD

[Nan Xiao]

Hi all,

I guess this issue (https://github.com/vim/vim/issues/2008) may be the cause.

My vim version is 8.0.987.
Best Regards
Nan Xiao


On Wed, Mar 14, 2018 at 9:24 AM, Nan Xiao  wrote:
> Hi Stuart,
>
> Thanks for your reply!
>
> When I don't use SSH client, the vim display correct result.
>
> My OS is Windows, and my SSH client is Cygwin, it display 0.
>
> I try putty and MobaXterm, both display:
>
> 1q q
>
>
> Except vim, vi display correct for all the SSH clients. So it seems
> interesting.
> Best Regards
> Nan Xiao
>
>
> On Tue, Mar 13, 2018 at 10:24 PM, Stuart Henderson  
> wrote:
>> On 2018/03/13 21:59, Nan Xiao wrote:
>>> Hi Stuart,
>>>
>>> No! It doesn't happen when run "env -i vim $filename".
>>>
>>> But check my environment:
>>>
>>> # env
>>> _=/usr/bin/env
>>> LOGNAME=root
>>> HOME=/root
>>> SSH_TTY=/dev/ttyp0
>>> LSCOLORS=fxexcxdxbxegedabagacad
>>> SHELL=/bin/ksh
>>> PS1=$USER:$PWD#
>>> TERM=xterm
>>> SSH_CONNECTION=10.217.243.14 63260 10.217.242.61 22
>>> LD_LIBRARY_PATH=/usr/local/lib
>>> MAIL=/var/mail/root
>>> SSH_CLIENT=10.217.243.14 63260 22
>>> PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/local/jre-1.8.0/bin
>>> USER=root
>>>
>>> Don't know what causes the problem.
>>> Best Regards
>>> Nan Xiao
>>>
>>>
>>> On Tue, Mar 13, 2018 at 6:39 PM, Stuart Henderson  
>>> wrote:
>>> > On 2018-03-13, Nan Xiao  wrote:
>>> >> Hi Ville,
>>> >>
>>> >> I don't have ~/.vimrc, only a ~/.viminfo, thanks!
>>> >
>>> > Perhaps something in your environment is causing a problem.
>>> >
>>> > Does it also happen if you run "env -i vim $filename"?
>>> >
>>> >
>>
>> The only thing that looks odd in there is the LD_LIBRARY_PATH setting
>> though I don't see how that would be triggering this..
>>
>> Other thing I'm wondering is what terminal it is.
>>
>> Perhaps running it under script(1) and examining ./typescript would
>> give another clue.
>>
>>