syspatch and kernels

[Jay Hart]

Hello all,

I am looking for some guidance or clarification on patching. If a patch, say 
008 in v6.2, were
installed manually, I would need to install the patch and complete the commands 
to build and load
a new kernel. For syspatch, how is the kernel piece handled?  Does syspatch 
also install new
kernels which are loaded next time box is rebooted?  I'm not sure of this piece 
of the updates.

All-in-all, I'm happy with syspatch, just looking to determine the kernel side 
of this utility.

Thanks for your help,

Jay

Re: gcc-4.9.4 package build signal 11 [Segmentation fault] on Ubiquiti Unifi Security Gateway

[Bryan Vyhmeister]

I have had a few discussions with visa@ about builds on OpenBSD/octeon.
For ports builds, 1GB of memory like in the EdgeRouter 4 and 6 is too
little to build big things like gcc which is required for quite a few
things. The EdgeRouter Lite, EdgeRouter PoE, and USG are even worse with
512MB of memory. Also, the EdgeRouter 4 and 6 have some issues with the
USB 3.0 controller that visa@ has not been able to work out yet. It's
pretty difficult to get any insight into what is happening with the USB
3.0 controller. The ER4 and ER6 work reasonably well with Samsung USB
Fit USB 3.0 flash drive but occasionally weird errors happen and the
system freezes up or panics. I was not able to get a Samsung T3 or T5
USB SSD to work with the ER4 or ER6.

The best route for a readily available machine for OpenBSD/octeon builds
is either the USG Pro 4 or the EdgeRouter Pro. They both come with 2GB
of memory but can be upgraded with up to 8GB of memory. Unlike the USB
flash drives in the USG and EdgeRouter Lite/PoE, the internal storage is
soldered on as was said in this thread already. The best route for
storage I have found thus far is a USB SSD like the Samsung T3 or T5. I
have not tested any others at this point but others probably work as
well.

For the EdgeRouter Pro, I have it running from a 250GB Samsung T3 USB
SSD and have upgraded it with an 8GB SODIMM of DDR3 1333MHz memory. The
part number that worked for the EdgeRouter Pro is Patriot PSD38G13332S.
I found this information from the UBNT forums.

For the USG Pro 4, I bought the same Patriot memory but had all sorts of
crashes and problems. I'm not sure if the memory chip is bad or if it is
just expecting different memory (have not had time to test) but I looked
at the factory memory in the USG Pro 4 and bought similar memory which
works fine. The factory chip is Kingston KVR16S11S6/2. I bought a set of
Kingston KVR16S11K2/16 which is two 8GB chips. They work perfectly and I
plan to get another USG Pro 4 for a second build machine to utilize the
second 8GB chip I have.

With 8GB of memory, most ports builds work fine including gcc but
occasionally I see some weird error that usually disappears with
restarting the dpb(1) build.

Bryan

Re: gcc-4.9.4 package build signal 11 [Segmentation fault] on Ubiquiti Unifi Security Gateway

[john slee]

I also had a similar experience trying to build gcc6 on my Edgerouter Lite
(same model
as linked on tedu's blog page, which is how I discovered this little
machine initially) on
a snapshot from ~2 weeks ago. MP kernel, with the ERL's /usr/ports on an
NFS volume
hosted by an amd64 OpenBSD system.

I had a 'vmstat 15' running in another terminal throughout and it did dip
down into low
double-digits a few minutes before the segfault

I realise this post is not terribly useful other than being a "me too". If
it's worth my trying
a non-MP kernel I'll do that and report back

John


On 1 January 2018 at 05:52, Janne Johansson  wrote:
>
> 2017-12-30 5:01 GMT+01:00 Diana Eichert :
>
> > Hi misc@ long time since I posted
> >
> > collect2: error: ld terminated with signal 11 [Segmentation fault]
> >
> > while building gcc-4.9.4 package on Ubiquiti Unifi Security Gateway
> >
> > I'm running 12/22/2017 octeon snapshot, bsd.mp GENERIC.MP kernel.
> >
> > System built 109 packages before Seg Fault when building gcc-4.9.4
> >
> >
> I think I got those on my Octeon also, but I thought gcc had figured out a
> way to drive my
> box into swap and die so I just stopped trying to build gcc from ports.
>
>
> --
> May the most significant bit of your life be positive.

Re: Setting up IKEv2 IPSec connection to Algo VPN

[Patrick Wildt]

On Mon, Feb 19, 2018 at 04:04:38PM -0700, Alec Newman wrote:
> Hello,
> 
> I was experimenting with setting up a VPN server on AWS using Algo (
> https://github.com/trailofbits/algo) that I'd like to connect to using an
> OpenBSD laptop.
> 
> They don't explicitly provide an OpenBSD client configuration but from what
> I can tell it should be doable with OpenBSD's built in tools.  It appears
> to be IKEv2 so from what I can tell I just need the correct /etc/iked.conf
> and copy the right keys/certificates into the right places in /etc/iked.
> 
> This is the StrongSwan config file provided for the client (VPN server's IP
> address replaced with $REMOTEGW and username replaced with $USER).
> 
> conn ikev2-$REMOTEGW
> fragmentation=yes
> rekey=no

Does this mean it does reauthentication instead of rekeying?  Could
become an issue at some point, especially if strongswan does make-
before-break and you have long running connections.

> dpdaction=clear
> keyexchange=ikev2
> compress=no
> dpddelay=35s
> 
> ike=aes128gcm16-prfsha512-ecp256!
> esp=aes128gcm16-ecp256!
> 
> right=$REMOTEGW
> rightid=$REMOTEGW
> rightsubnet=0.0.0.0/0
> rightauth=pubkey
> 
> leftsourceip=%config
> leftauth=pubkey
> leftcert=$USER.crt
> leftfirewall=yes
> left=%defaultroute
> 
> auto=add
> 
> I tried copying the certifcate produced by algo named $REMOTEGW.crt to
> /etc/iked/pubkeys/ipv4/$REMOTEGW but when I restart iked with rcctl restart
> iked I get "iked[37566]: set_policy: could not find pubkey for
> /etc/iked/pubkeys/ipv4/$REMOTEGW" in /var/log/messages.  The certificate is
> in the PEM format, which appears to be what is required, so I'm unsure what
> problem iked is having.

In a current iked(8) setup you have to store your own certificate (with
the private key in a different directory) and its full chain.  Also you
have to store the remote gateway's full chain (but not necessarily the
remote gateway's certificate).  In addition, you have to make sure the
certs use the X509v3 something something DNS extension.

openssl x509 -in fubar.crt -text should show this if you look for
X509v3.

> Any insight or help would be appreciated.  I'd be happy to provide more
> information if necessary.
> 
> Thanks,
> Alec

Re: Using OpenBSD on a thinkpad?

[Patrick Harper]

As long as your Libreboot firmware uses SeaBIOS and not something exotic, you 
shouldn't have any problems.

-- 
  Patrick Harper
  paia...@fastmail.com

On Mon, 19 Feb 2018, at 01:00, crimeangot...@nigge.rs wrote:
> 
> Hey everyone, I am pretty stupid when it comes to less user friendly 
> operating systems. I currently use slackware/windows and am thinking of 
> using OpenBSD on either my thinkpad e420 or my libreboot t400. Are 
> either supported(or at least possible to install on?) I’m sorry if this 
> question has already been asked but I can’t really find any answers and 
> the mailing list archive is barren as well. 
> Thanks!

Re: iked random tunnel drops

[Marc West]

On 2018-01-23 08:26:43, danial wrote:
> I had something similar happening. In my case I solved it by disabling NAT-T
> on one end.

Unfortunately disabling NAT-T did not have any effect, the issue has
occurred 2 additional times since restarting with -T. There is no NAT or
firewall between these machines aside from PF with everything permitted
to/from peer IPs (confirmed with pflog that nothing legit is getting
blocked). Thanks though.

I was able to get iked running in debug mode outputting with timestamps
to a file. I'll try to summarize and if anyone is willing to look at
the full debug logs I'm happy to send, but it is a lot.

There seems to be two slightly different symptoms, one where iked does
not gracefully restart and has to be kill -9'd, and another where
everything recovers on its own after an ikesa rekey. In both cases an 
ikev2_msg_retransmit_timeout is eventually logged for one msgid that is 
not received on the other side, even though the underlying connectivity
between the machines is OK. Sometimes tunnel traffic drops minutes
before that retransmit_timeout and flow removal, other times tunnel
traffic passes until the flows are freed.

Example 1 - "Site A" initiates a rekey to "Site B":

Feb 15 23:28:48 pfkey_process: SA 0xb241ab32 is expired, pending rekeying
Feb 15 23:28:48 ikev2_send_create_child_sa: rekeying ESP spi 0xb241ab32
Feb 15 23:28:48 ikev2_pld_parse: header ispi 0x922bc52299efed0e rspi 
0x81f6d03c457134b7 nextpayload SK version 0x20 exchange CREATE_CHILD_SA flags 
0x00 msgid 80 length 720 response 0
Feb 15 23:28:48 ikev2_msg_send: CREATE_CHILD_SA request from a.a.a.a:500 to 
b.b.b.b:500 msgid 80, 720 bytes
Feb 15 23:28:48 ikev2_recv: CREATE_CHILD_SA response from initiator b.b.b.b:500 
to a.a.a.a:500 policy 'siteb' id 80, 736 bytes
Feb 15 23:28:48 ikev2_recv: ispi 0x922bc52299efed0e rspi 0x81f6d03c457134b7
Feb 15 23:28:48 ikev2_recv: updated SA to peer b.b.b.b:500 local a.a.a.a:500
[...]
Feb 15 23:28:48 ikev2_msg_send: INFORMATIONAL request from a.a.a.a:500 to 
b.b.b.b:500 msgid 81, 80 bytes
[...]
Feb 15 23:30:55 ikev2_msg_retransmit_timeout: retransmit limit reached for 
msgid 81
Feb 15 23:30:55 sa_free: ispi 0x922bc52299efed0e rspi 0x81f6d03c457134b7
Feb 15 23:30:55 config_free_proposals: free 0x13b9a0591300
Feb 15 23:30:55 config_free_proposals: free 0x13b9950e9180
Feb 15 23:30:55 config_free_childsas: free 0x13b9a98b3e00
Feb 15 23:30:55 config_free_childsas: free 0x13b9798f7000
Feb 15 23:30:55 sa_free_flows: free 0x13b9afcdec00
[... all flows removed, traffic drops ...]

iked on the other side ("Site B") receives and responds to the
CREATE_CHILD_SA request (msgid 80) but the INFORMATIONAL request msgid
81 above is not seen on the other side. A ctrl-c of iked running in the
foreground stopped the control and ca processes, but parent and ikev2
processes hung and both needed a kill -9 like before. I attached ktrace
to the parent and ikev2 PIDs but no operations were logged on either. Is
there something else I should do in this scenario to debug the hung
processes?

--

Example 2 - This one eventually recovered on its own with a full ikesa
rekey. Does the "pfkey_process is busy" point to anything? This is only
a very small portion of the debug log, but tunnel traffic stopped
passing at at 05:44 which is minutes before the retransmit timeout and
the flows were actually removed.

Site A:
Feb 19 05:44:51 pfkey_process: SA 0x1f00e21b is expired, pending rekeying
Feb 19 05:45:19 pfkey_process: SA 0x3382f769 is expired, pending rekeying
Feb 19 05:45:35 pfkey_process: SA 0x7b59c4c8 is expired, pending rekeying
Feb 19 05:45:49 pfkey_process: SA 0x985fd6fa is expired, pending rekeying
Feb 19 05:46:03 pfkey_process: SA 0xbc92b3b5 is expired, pending rekeying
Feb 19 05:46:21 ikev2_msg_send: INFORMATIONAL request from a.a.a.a:500 to 
b.b.b.b:500 msgid 649, 80 bytes
[...]
Feb 19 05:47:49 ikev2_msg_send: INFORMATIONAL request from a.a.a.a:500 to 
b.b.b.b:500 msgid 650, 80 bytes
[...]
Feb 19 05:49:55 ikev2_msg_retransmit_timeout: retransmit limit reached for 
msgid 650

Site B:
Again, msgid 649 is received and responded to but not the very next
msgid 650:

Feb 19 05:46:21 ikev2_pld_parse: header ispi 0x43855e1590d3e29a rspi 
0x8a04b23198062451 nextpayload SK version 0x20 exchange INFORMATIONAL flags 
0x08 msgid 649 length 80 response 0
Feb 19 05:46:21 ikev2_pld_parse: header ispi 0x43855e1590d3e29a rspi 
0x8a04b23198062451 nextpayload SK version 0x20 exchange INFORMATIONAL flags 
0x20 msgid 649 length 80 response 1
Feb 19 05:46:21 ikev2_msg_send: INFORMATIONAL response from b.b.b.b:500 to 
a.a.a.a:500 msgid 649, 80 bytes

# grep "Feb 19" iked_debug.log | grep "msgid 650"
#
# grep "Feb 19" iked_debug.log | grep -B1 "is busy"
Feb 19 05:44:50 pfkey_process: SA 0x1f00e21b is expired, pending rekeying
Feb 19 05:44:50 pfkey_dispatch: pfkey_process is busy, retry later
--
Feb 19 05:45:19 pfkey_process: SA 0x3382f769 is expired, pending 

Re: SHA256.sig not contained in install62.iso

[Stefan Sperling]

On Tue, Feb 20, 2018 at 07:23:05PM +0200, mazocomp wrote:
> Isn't the same true when I download file sets from any mirror?

No.

> After all
> I download SHA256.sig abd file sets from mirror, how can I trust it?

You run a trusted signify binary, which was not obtained from the mirror
but is part of your existing install, to check the signature on SHA256.sig.

A signify binary inside installXX.iso can't be trusted to not lie about
the integrity of contents of installXX.iso.

Re: SHA256.sig not contained in install62.iso

[Kevin Chadwick]

On Tue, 20 Feb 2018 19:23:05 +0200


> Isn't the same true when I download file sets from any mirror? After
> all I download SHA256.sig abd file sets from mirror, how can I trust
> it?

I am not a developer but my take is that they do not want to tell you it
is verified if you have been given a CD etc.. Anything could have been
booted and tell you it is verified.

You can verify the .iso manually and you can use e.g. isomaster to add
sha256.sig to the CD in which case it will verify them. I have used
this in the past as a scratched rw seemingly fails sooner on verify than
reading and also won't try to upgrade.

If you have already manually verified bsd.rd and booted from that as I
and I guess most developers do most often when upgrading then you do
want it to tell you the http retrieval verified.

I guess it was the simplest way considering installer size
constraints/battles to avoid misinforming the user.

Re: SHA256.sig not contained in install62.iso

[mazocomp]

On Tue, Feb 20, 2018 at 12:59:08PM +0100, Theo Buehler wrote:
> On Tue, Feb 20, 2018 at 12:56:06PM +0100, Nicolas Schmidt wrote:
> > Hi,
> > 
> > I am finally getting around to upgrading 6.1->6.2. When I try to install 
> > from CD using the install62.iso image, the install script complains that it 
> > can't find SHA256.sig (indeed, it's on it).
> > 
> > Is that supposed to happen?
> 
> Yes. The last paragraph from
> https://www.openbsd.org/faq/faq4.html#Download says:
> 
> The installXX.iso and installXX.fs images do not contain an SHA256.sig
> file, and the installer will complain that it can't check the
> signatures. It is not possible for the installer to verify the sets with
> these images. After all, if someone were to make a rogue installXX.iso
> file, they could certainly change the installer to say the files were
> legitimate. Thus, you must verify those installer downloads separately.
> 

Isn't the same true when I download file sets from any mirror? After all
I download SHA256.sig abd file sets from mirror, how can I trust it?

Re: Upgrade 6.1->6.2 fails with "id 0 on/: file system full"

[trondd]

On Tue, February 20, 2018 8:34 am, Nicolas Schmidt wrote:
> Hey,
>
> it's me again, still trying to upgrade to 6.2.
>
> After choosing to skip verification and continue the upgrade process, I
> now immediately get the following error:
>
> Installing bsd0% |
> id 0 on /: file system full
>
> /: write failed, file system full
> ftp: Writing -: No space left on device
>
> Going to a shell, "df" reveals
>
> Filesystem512-blocks  UsedAvail   CapacityMounted 
> on
> /dev/rd0a   6143  6116   27   100%/
> /dev/sd2a2057756179068  1775804 9%/mnt
> .
> .
> .
>
> To me it seems, the install script is trying to install the kernel on the
> ram disk mounted on / instead of the actual root partition mounted on /mnt
> (sd2 is the volume I chose for installation; it's a RAID 1). Since the ram
> disk is full, this of course has to fail.
>
> Any suggestions?
>
> Best regards and thanks for your help,
> Nicolas
>

This just came up on Daemonforums.  The user had a symlink pointing to an
absolute path starting with /.  The installer follows that symlink to the
ramdisk / instead of /mnt.

http://daemonforums.org/showthread.php?p=63885

Tim.

Upgrade 6.1->6.2 fails with "id 0 on/: file system full"

[Nicolas Schmidt]

Hey,

it's me again, still trying to upgrade to 6.2.

After choosing to skip verification and continue the upgrade process, I now 
immediately get the following error:

Installing bsd  0% |
id 0 on /: file system full

/: write failed, file system full
ftp: Writing -: No space left on device

Going to a shell, "df" reveals

Filesystem  512-blocks  UsedAvail   CapacityMounted on
/dev/rd0a 6143  6116   27   100%/
/dev/sd2a  2057756179068  1775804 9%/mnt
.
.
.

To me it seems, the install script is trying to install the kernel on the ram 
disk mounted on / instead of the actual root partition mounted on /mnt (sd2 is 
the volume I chose for installation; it's a RAID 1). Since the ram disk is 
full, this of course has to fail.

Any suggestions?

Best regards and thanks for your help,
Nicolas

Re: SHA256.sig not contained in install62.iso

[Nicolas Schmidt]

Sorry, I of course meant to say it‘s *not* on it.

> Am 20.02.2018 um 12:56 schrieb Nicolas Schmidt :
> 
> Hi,
> 
> I am finally getting around to upgrading 6.1->6.2. When I try to install from 
> CD using the install62.iso image, the install script complains that it can't 
> find SHA256.sig (indeed, it's on it).
> 
> Is that supposed to happen?
> 
> Best,
> Nicolas A. Schmidt

Re: SHA256.sig not contained in install62.iso

[Theo Buehler]

On Tue, Feb 20, 2018 at 12:56:06PM +0100, Nicolas Schmidt wrote:
> Hi,
> 
> I am finally getting around to upgrading 6.1->6.2. When I try to install from 
> CD using the install62.iso image, the install script complains that it can't 
> find SHA256.sig (indeed, it's on it).
> 
> Is that supposed to happen?

Yes. The last paragraph from
https://www.openbsd.org/faq/faq4.html#Download says:

The installXX.iso and installXX.fs images do not contain an SHA256.sig
file, and the installer will complain that it can't check the
signatures. It is not possible for the installer to verify the sets with
these images. After all, if someone were to make a rogue installXX.iso
file, they could certainly change the installer to say the files were
legitimate. Thus, you must verify those installer downloads separately.

SHA256.sig not contained in install62.iso

[Nicolas Schmidt]

Hi,

I am finally getting around to upgrading 6.1->6.2. When I try to install from 
CD using the install62.iso image, the install script complains that it can't 
find SHA256.sig (indeed, it's on it).

Is that supposed to happen?

Best,
Nicolas A. Schmidt