syspatch and kernels
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
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
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
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?
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
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 reke
Re: SHA256.sig not contained in install62.iso
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
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
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"
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"
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
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
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
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