Re: OpenBSD UEFI on QEMU emulator
On Fri, 23 Oct 2020 09:59:24 +0800 Kevin Shell wrote: > I want to try out OpenBSD UEFI. > How to install OpenBSD with UEFI boot on qemu? > The install68.iso has no UEFI support. > My following command on Linux can't boot OpenBSD UEFI. > > qemu-system-x86_64 -enable-kvm \ >-machine q35 \ >-cpu host \ >-smp cores=4,threads=1 \ >-m 1G \ >-bios /usr/share/edk2/ovmf/OVMF_CODE.fd \ >-drive file=install68.img,format=raw Does the drive of "install68.img" appear on the boot menu on BIOS? At least on my linux machine, qemu-system-x86_64 -machine q35 -smp cores=4,threads=1 -m 1G -bios /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd -drive file=install68.img,format=raw doesn't boot as well. The drive doesn't appear on the boot menu. But by removing "-machine q35" from the line, it booted successfully.
Re: OpenBSD UEFI on QEMU emulator
On Thu, Oct 22, 2020 at 10:37:31PM -0400, Brad Smith wrote: > On 10/22/2020 9:59 PM, Kevin Shell wrote: > > Hello misc@. > > > > I want to try out OpenBSD UEFI. > > How to install OpenBSD with UEFI boot on qemu? > The installer does prompt you during disk setup. > > The install68.iso has no UEFI support. > > This is not true. It does not include a fat fs el torito image with efiboot only cdbr for mbr. > > > My following command on Linux can't boot OpenBSD UEFI. > > > > qemu-system-x86_64 -enable-kvm \ > > -machine q35 \ > > -cpu host \ > > -smp cores=4,threads=1 \ > > -m 1G \ > > -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \ > > -drive file=install68.img,format=raw > > > > > > -- > > kevin > > > >
Re: ssl/libssl certificate validation broken?
Daniel Jakots wrote: > On Thu, 22 Oct 2020 21:49:20 -0500, "Rafael Possamai" > wrote: > > > >Hi Bob, it was in the middle of the night and I got quite kinda > > >stressed because all services depending on our ldap proxy stopped > > >working after the upgrade and it took me a while to figure the > > >problem out. > > > > Perhaps this is unsolicited advice, but maybe you can setup a test > > system first, perform major upgrade on it to make sure everything > > works. If so, then do it in production. > > > > Even better, try -current a few weeks before release (a possible hint > is -beta). This way you can get any encountered bug fixed in time for > -release. Your prod but also every one else will benefit from it. It's very good advice. I can't speak for Bob, but I've been unable to sleep during this outage.
Re: ssl/libssl certificate validation broken?
On Thu, 22 Oct 2020 21:49:20 -0500, "Rafael Possamai" wrote: > >Hi Bob, it was in the middle of the night and I got quite kinda > >stressed because all services depending on our ldap proxy stopped > >working after the upgrade and it took me a while to figure the > >problem out. > > Perhaps this is unsolicited advice, but maybe you can setup a test > system first, perform major upgrade on it to make sure everything > works. If so, then do it in production. > Even better, try -current a few weeks before release (a possible hint is -beta). This way you can get any encountered bug fixed in time for -release. Your prod but also every one else will benefit from it. Cheers, Daniel
Re: ssl/libssl certificate validation broken?
>Hi Bob, it was in the middle of the night and I got quite kinda stressed >because all services depending on our ldap proxy stopped working after the >upgrade and it took me a while to figure the problem out. Perhaps this is unsolicited advice, but maybe you can setup a test system first, perform major upgrade on it to make sure everything works. If so, then do it in production.
OpenBSD UEFI on QEMU emulator
Hello misc@. I want to try out OpenBSD UEFI. How to install OpenBSD with UEFI boot on qemu? The install68.iso has no UEFI support. My following command on Linux can't boot OpenBSD UEFI. qemu-system-x86_64 -enable-kvm \ -machine q35 \ -cpu host \ -smp cores=4,threads=1 \ -m 1G \ -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \ -drive file=install68.img,format=raw -- kevin
OpenBSD Posters
Hey, Many of the recent OpenBSD posters have been really amazing, and I want to get some of them to hand on my wall. I have a couple from before they closed the OpenBSD store, but now that it's gone I can't seem to find anywhere to get them. Is there anyone I can contact to get high resolution versions of the artwork so I can bring it to my local print shop to get printed up? I'd be happy to pay for images or make a donation to the foundation in exchange. Thanks, Dante
Re: possible relayd.conf(5) documentation mistake regarding session tickets
On 20/10/21 09:26PM, Sebastian Benoit wrote:
> * i'm not sure we wanted session resumption to be enabled by default
> because of the security implications regarding perferct forward
> secrecy. Indeed the option is off by default at the moment.
Hey, thanks for explaining a bit. :) I read about session resumption
after your mail and can see why the default is off.
Originally I noticed the disparity between what the man page states and
what Qualys reports because I was comparing the results of default
ciphers and `tls { ciphers secure }`, as `openssl ciphers -v secure`
returns an error and SSL_CTX_set_cipher_list(3) doesn't list secure as
a control string.
--
https://amissing.link
Re: Issue updating spidermonkey
On 2020-10-22, Brennan Vincent wrote:
> On 10/22/20 4:31 AM, Antoine Jacoutot wrote:
>> On Wed, Oct 21, 2020 at 06:43:13PM -0400, Brennan Vincent wrote:
>>>
>>> On 10/21/20 4:40 AM, Stuart Henderson wrote:
On 2020-10-21, Chris Bennett wrote:
> On Tue, Oct 20, 2020 at 08:26:05PM -0400, Brennan Vincent wrote:
>> Updated yesterday from 6.7 to a snapshot, and now:
>>
>> $ doas pkg_add -u
> doas pkg_add -u -Dsnap
>
> You need to do some things different once you change to -current
> snapshots.
> Might also have to wait for -current packages to match the -current
> snapshot sometimes.
-Dsnap does nothing for most of the year. The only thing it's useful for is
pointing to the snapshots directory whdn you're running a kernel with no
-beta/-current suffix (i.e. a release, or snapshot in the short period in
the run-up to release).
>> quirks-3.458 signed on 2020-10-18T13:56:14Z
This shows that it is indeed looking at a snapshot directory not release.
>> Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update
>> found
>> for spidermonkey-60.9.0v1
>> Can't install polkit-0.116p1->0.118: can't resolve
>> spidermonkey78-78.3.1v1
>>
>> Is this expected soon after updating? Do I just need to wait for some
>> inconsistency in the pkg repo to be resolved?
This could either be:
- a bug in some port
- a package source that does not have a consistent set of files from one
build (can happen when a mirror is updating)
First thing to do if this happens is check file dates in the mirror's
directory listing and see if they're consistent (no big jump between the
a* and z* files).
>>>
>>> Will the URL to check look something like
>>> https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ?
>>>
>>> I checked there; all the files were touched within a 10 minute period.
>>>
>>> Issue is persisting.
>>
>> Should be fixed in a current.
>> Wait a few days for new packages.
>>
>
> Thanks.
>
> What was the issue? Can you link to the diff that fixed it? (Just
> curious for my own culture).
>
>
$ cd /usr/ports/devel/spidermonkey78
$ cvs log Makefile
RCS file: /cvs/ports/devel/spidermonkey78/Makefile,v
Working file: Makefile
head: 1.3
branch:
locks: strict
access list:
symbolic names:
jasper_20201610: 1.1.1.1
jasper: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
revision 1.3
date: 2020/10/22 08:30:39; author: ajacoutot; state: Exp; lines: +2 -1;
commitid: Rg9G9qi3oLdQwfzw;
Provide an upgrade path from spidermonkey (there is no spidermonkey60).
revision 1.2
date: 2020/10/18 18:03:48; author: ajacoutot; state: Exp; lines: +2 -3;
commitid: pssTfqvwb5L15vgl;
Tweak comment.
revision 1.1
date: 2020/10/16 19:39:41; author: jasper; state: Exp; commitid:
O9U4pqFDdhK1VJcO;
branches: 1.1.1;
Initial revision
revision 1.1.1.1
date: 2020/10/16 19:39:41; author: jasper; state: Exp; lines: +0 -0;
commitid: O9U4pqFDdhK1VJcO;
import spidermonkey 78.3.1
as discussed with aja i'm not hooking this up just yet
ok aja@
=
$ cvs di -D 2020/10/20 -D now
Index: Makefile
===
RCS file: /cvs/ports/devel/spidermonkey78/Makefile,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- Makefile18 Oct 2020 18:03:48 - 1.2
+++ Makefile22 Oct 2020 08:30:39 - 1.3
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.2 2020/10/18 18:03:48 ajacoutot Exp $
+# $OpenBSD: Makefile,v 1.3 2020/10/22 08:30:39 ajacoutot Exp $
# see patch-js_src_old-configure_in
USE_WXNEEDED = Yes
@@ -20,6 +20,7 @@ DISTNAME =firefox-${V}esr.source
EXTRACT_SUFX = .tar.bz2
PKGNAME = spidermonkey${MOZILLA_VERSION}-${V}
EPOCH =1
+REVISION = 0
SHARED_LIBS = mozjs-78 0.0
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/spidermonkey78/pkg/PLIST,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -p -r1.1.1.1 -r1.2
--- pkg/PLIST 16 Oct 2020 19:39:41 - 1.1.1.1
+++ pkg/PLIST 22 Oct 2020 08:30:39 - 1.2
@@ -1,5 +1,7 @@
-@comment $OpenBSD: PLIST,v 1.1.1.1 2020/10/16 19:39:41 jasper Exp $
-@conflict spidermonkey-<=68.11.0v1
+@comment $OpenBSD: PLIST,v 1.2 2020/10/22 08:30:39 ajacoutot Exp $
+@conflict spidermonkey-*
+@conflict spidermonkey68-*
+@pkgpath devel/spidermonkey60
@pkgpath devel/spidermonkey68
include/mozjs-${MOZILLA_VERSION}/
Re: Multiple USB NICs
On 2020-10-22, Lee Nelson wrote: > And Theo's hint was spot on. I'm experimenting with arm64 on an RPI 4. > Stability is not one of my expectations. I would actually expect pi4 and the onboard bse(4) to be fairly stable. Stability with USB is likely to be less good. (The onboard nic is also decently fast, I saw full gigabit near as dammit, much better than e.g. an APU, and also much better than the ure(4) which I tried on the pi, IIRC I was seeing a couple of hundred Mb tops from that).
Re: /dev/usb0 - NotImplementedError: Operation not supported or unimplemented on this platform
On 2020-10-22, Stuart Henderson wrote: > diff -u -p -r1.720 usbdevs > --- usbdevs 3 Aug 2020 14:25:44 - 1.720 > +++ usbdevs 22 Oct 2020 10:40:12 - > @@ -630,6 +630,7 @@ vendor ARDUINO0x2341 Arduino SA > vendor TPLINK0x2357 TP-Link > vendor WMR 0x2405 West Mountain Radio > vendor TRIPPLITE 0x2478 Tripp-Lite > +vendor CHANEY0x24co Chaney Instrument Oh typo. Should be 0x24c0, I won't send a new patch for that, just edit the file :)
Re: Issue updating spidermonkey
On 10/22/20 4:31 AM, Antoine Jacoutot wrote: On Wed, Oct 21, 2020 at 06:43:13PM -0400, Brennan Vincent wrote: On 10/21/20 4:40 AM, Stuart Henderson wrote: On 2020-10-21, Chris Bennett wrote: On Tue, Oct 20, 2020 at 08:26:05PM -0400, Brennan Vincent wrote: Updated yesterday from 6.7 to a snapshot, and now: $ doas pkg_add -u doas pkg_add -u -Dsnap You need to do some things different once you change to -current snapshots. Might also have to wait for -current packages to match the -current snapshot sometimes. -Dsnap does nothing for most of the year. The only thing it's useful for is pointing to the snapshots directory whdn you're running a kernel with no -beta/-current suffix (i.e. a release, or snapshot in the short period in the run-up to release). quirks-3.458 signed on 2020-10-18T13:56:14Z This shows that it is indeed looking at a snapshot directory not release. Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update found for spidermonkey-60.9.0v1 Can't install polkit-0.116p1->0.118: can't resolve spidermonkey78-78.3.1v1 Is this expected soon after updating? Do I just need to wait for some inconsistency in the pkg repo to be resolved? This could either be: - a bug in some port - a package source that does not have a consistent set of files from one build (can happen when a mirror is updating) First thing to do if this happens is check file dates in the mirror's directory listing and see if they're consistent (no big jump between the a* and z* files). Will the URL to check look something like https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ? I checked there; all the files were touched within a 10 minute period. Issue is persisting. Should be fixed in a current. Wait a few days for new packages. Thanks. What was the issue? Can you link to the diff that fixed it? (Just curious for my own culture).
Re: MBMS Support and port 8053 on tcpdump
On Thu, Oct 22, 2020 at 07:49:40PM +0200, Peter J. Philipp wrote: > Hi, > > Just got this message (seemed like a flood) from tcpdump: > > > [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [M > BMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] > [MBMS S > upport] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS > Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS > Support] [M > BMS Support] [MBMS Support] [MBMS Support] [MBMS^C > > 3407731 packets received by filter > > 2169 packets dropped by kernel > > you have mail in /var/mail/pjp > > eta# tcpdump -v -n -i pppoe0 -s 1500 -X port 8053 > > tcpdump: listening on pppoe0, link-type PPP_ETHER > > > The tcpdump command was executed as is. System is OpenBSD 6.8. What I find > weird here is that there is no configured 8053 port for GTP is there? > > Best Regards, > -peter > Hi again, so I've found out that in print-gtp.c there might be the possibility for an endless loop. In function gtp_v1_print(): 928 /* Header length is a 4 octet multiplier. */ 929 hlen = (int)p[0] * 4; 930 TCHECK2(p[0], hlen); if hlen == 0 here it would pass (as in not goto trunc) TCHECK2 right? 958 p += hlen - 1; 959 nexthdr = (int)p[0]; 960 p++; Here it would go backwards by one which nexthdr would become (if it's 0 coincidentally?) and then it increments by one to start anew. Can anyone confirm my suspicions? Best Regards, -peter
MBMS Support and port 8053 on tcpdump
Hi, Just got this message (seemed like a flood) from tcpdump: [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [M BMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS S upport] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [M BMS Support] [MBMS Support] [MBMS Support] [MBMS^C 3407731 packets received by filter 2169 packets dropped by kernel you have mail in /var/mail/pjp eta# tcpdump -v -n -i pppoe0 -s 1500 -X port 8053 tcpdump: listening on pppoe0, link-type PPP_ETHER The tcpdump command was executed as is. System is OpenBSD 6.8. What I find weird here is that there is no configured 8053 port for GTP is there? Best Regards, -peter
Re: crosscompiling binutils
On Thu, Oct 22, 2020 at 06:34:27PM +0200, Peter J. Philipp wrote: > On Thu, Oct 22, 2020 at 08:52:48AM -0700, Mike Larkin wrote: > > On Thu, Oct 22, 2020 at 04:26:37PM +0200, Peter J. Philipp wrote: > > > Hi, > > > > > > I was wondering if binutils-2.17 will be that version for the next > > > foreseeable > > > future? Reason being is that there is backports to RISCV's binutils but > > > they > > > don't go that low to 2.17. Since I'm lazy, I don't really want to port > > > binutils to 2.17 for any architecture if it's not already done so. > > > Unfortunately I only invested a handful of days looking into the problem > > > and > > > just as many procrastinating around this. > > > > > > I lost contact to the riscv group, but if I rejoin them I'd like to give > > > them > > > something and not just look happy. :-) > > > > > > Peace. > > > -peter > > > > Any idea why you feel this is needed? After all, the tree in that repo > > already > > builds cleanly without needing to do this. > > > > Ps that workspace is still open, just a bit idle the last few months. > > > > -ml > > Hi Mike, > > How do you build the userland tree? Do you hash out the binutils part? I > know there is the binutils that I think Mars put together, but it's not 2.17, > (working off memory here). > > I'll have to look for my credentials for the riscv groups chat. I must have > lost the cookie and url completion from my browser. When I find that I'll be > back. > > Best Regards, > -peter I believe they were using the llvm ld and such. I'll ask. -ml
Re: mailing list management software
Hi, On Thu, Oct 22, 2020 at 05:12:42PM +0300, Gregory Edigarov wrote: > Hello everybody, > > is there any mailing list software which naturally supports virtual domains? > by 'naturally' i mean not require to install a copy of itself for every > domain. > now i have a copy of mailman for every domain i need to serve. I do not feel > it > is a right way, and therefore want to change. > > -- > With best regards, > Gregory Edigarov > I am using mailman3. It works fine, just if you need its web interface then it require some gymnastic with proper uwsgi configuration - it need to be run via 'doas' or 'su' and user should not be specified in its ini file configuration, otherwise will sigsegv. https://github.com/unbit/uwsgi/issues/1901 -- Aleksander
Re: crosscompiling binutils
On Thu, Oct 22, 2020 at 08:52:48AM -0700, Mike Larkin wrote: > On Thu, Oct 22, 2020 at 04:26:37PM +0200, Peter J. Philipp wrote: > > Hi, > > > > I was wondering if binutils-2.17 will be that version for the next > > foreseeable > > future? Reason being is that there is backports to RISCV's binutils but > > they > > don't go that low to 2.17. Since I'm lazy, I don't really want to port > > binutils to 2.17 for any architecture if it's not already done so. > > Unfortunately I only invested a handful of days looking into the problem and > > just as many procrastinating around this. > > > > I lost contact to the riscv group, but if I rejoin them I'd like to give > > them > > something and not just look happy. :-) > > > > Peace. > > -peter > > Any idea why you feel this is needed? After all, the tree in that repo already > builds cleanly without needing to do this. > > Ps that workspace is still open, just a bit idle the last few months. > > -ml Hi Mike, How do you build the userland tree? Do you hash out the binutils part? I know there is the binutils that I think Mars put together, but it's not 2.17, (working off memory here). I'll have to look for my credentials for the riscv groups chat. I must have lost the cookie and url completion from my browser. When I find that I'll be back. Best Regards, -peter
Re: AMDGPU(4) - Question about man page
Below are various xorg.conf configurations. The only configuration that errors is when using section "Device." If I do not have an xorg.conf file or use section "OutputClass" X works fine. I hope this clarifies my initial question? xorg.conf: Section "Device" Identifier "AMDgpu" Driver "amdgpu" Option "DRI" "3" Option "TearFree" "true" EndSection ... Xorg log file: [ 85187.126] X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 [ 85187.126] Build Operating System: OpenBSD 6.8 amd64 [ 85187.126] Current Operating System: OpenBSD hellfire.markjolesen.com 6.8 GENERIC.MP#98 amd64 [ 85187.126] Build Date: 04 October 2020 06:41:21PM [ 85187.126] [ 85187.126] Current version of pixman: 0.38.4 [ 85187.126] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 85187.126] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 85187.127] (==) Log file: "/home/markjolesen/.local/share/xorg/Xorg.0.log", Time: Thu Oct 22 10:25:09 2020 [ 85187.127] (==) Using config file: "/etc/X11/xorg.conf" [ 85187.127] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 85187.127] (==) No Layout section. Using the first Screen section. [ 85187.127] (==) No screen section available. Using defaults. [ 85187.127] (**) |-->Screen "Default Screen Section" (0) [ 85187.127] (**) | |-->Monitor "" [ 85187.128] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 85187.128] (**) | |-->Device "AMDgpu" [ 85187.128] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 85187.128] (==) Automatically adding devices [ 85187.128] (==) Automatically enabling devices [ 85187.128] (==) Not automatically adding GPU devices [ 85187.128] (==) Max clients allowed: 256, resource mask: 0x1f [ 85187.128] (**) FontPath set to: /usr/local/share/fonts/spleen/, /usr/local/share/fonts/ghostscript, /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 85187.128] (==) ModulePath set to "/usr/X11R6/lib/modules" [ 85187.128] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [ 85187.128] (II) Loader magic: 0xf2709dde460 [ 85187.128] (II) Module ABI versions: [ 85187.128] X.Org ANSI C Emulation: 0.4 [ 85187.128] X.Org Video Driver: 24.1 [ 85187.128] X.Org XInput driver : 24.1 [ 85187.128] X.Org Server Extension : 10.0 [ 85187.128] (--) Using wscons driver on /dev/ttyC4 [ 85187.133] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Permission denied) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details [ 85187.133] linear framebuffer access unavailable [ 85187.133] (II) LoadModule: "glx" [ 85187.134] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [ 85187.136] (II) Module glx: vendor="X.Org Foundation" [ 85187.136] compiled for 1.20.8, module version = 1.0.0 [ 85187.136] ABI class: X.Org Server Extension, version 10.0 [ 85187.136] (II) LoadModule: "amdgpu" [ 85187.137] (II) Loading /usr/X11R6/lib/modules/drivers/amdgpu_drv.so [ 85187.138] (II) Module amdgpu: vendor="X.Org Foundation" [ 85187.138] compiled for 1.20.8, module version = 19.1.0 [ 85187.138] Module class: X.Org Video Driver [ 85187.138] ABI class: X.Org Video Driver, version 24.1 [ 85187.138] (II) AMDGPU: Driver for AMD Radeon: All GPUs supported by the amdgpu kernel driver [ 85187.138] (EE) No devices detected. [ 85187.138] (EE) Fatal server error: [ 85187.138] (EE) no screens found(EE) [ 85187.138] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 85187.138] (EE) Please also check the log file at "/home/markjolesen/.local/share/xorg/Xorg.0.log" for additional information. [ 85187.138] (EE) [ 85187.138] (EE) Server terminated with error (1). Closing log file. __ xorg.conf: Section "OutputClass" Identifier "AMDgpu" MatchDriver "amdgpu" Driver "amdgpu" Option "DRI" "3" Option "TearFree" "true" EndSection ... Xorg log file [ 950.342] X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 [ 950.343] Build Operating System: OpenBSD 6.8 amd64 [ 950.343] Current Operating System: OpenBSD hellfire.markjolesen.com 6.8 GENERIC.MP#98 amd64 [ 950.343] Build Date: 04 October 2020 06:41:21PM [ 950.344] [ 950.344] Current version of pixman: 0.38.4 [ 950.344] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 950.344] Markers: (--) probed, (**) from config
Re: crosscompiling binutils
On Thu, Oct 22, 2020 at 04:26:37PM +0200, Peter J. Philipp wrote: > Hi, > > I was wondering if binutils-2.17 will be that version for the next foreseeable > future? Reason being is that there is backports to RISCV's binutils but they > don't go that low to 2.17. Since I'm lazy, I don't really want to port > binutils to 2.17 for any architecture if it's not already done so. > Unfortunately I only invested a handful of days looking into the problem and > just as many procrastinating around this. > > I lost contact to the riscv group, but if I rejoin them I'd like to give them > something and not just look happy. :-) > > Peace. > -peter Any idea why you feel this is needed? After all, the tree in that repo already builds cleanly without needing to do this. Ps that workspace is still open, just a bit idle the last few months. -ml
Re: getaddrinfo(3) in CGI program
>My guess would be your chroot does not contain a etc/resolv.conf >and/ro etc/hosts file and you do not have a resolver running on >127.0.0.1 Thank you, Otto! Upon moving /etc/resolv.conf file to the chrooted directory I was able to call getaddrinfo and receive the associated IP from the domain.
Re: getaddrinfo(3) in CGI program
On Thu, Oct 22, 2020 at 10:16:28AM -0400, ben wrote: > Hello, Misc; > > I'm attempting to write a CGI progam in C which uses getaddrinfo(3), however > upon running the script getaddrinfo doesn't seem to run. I have a feeling this > is due to linking issues as other have experienced a similar issue with glibc. > > Here is the ldd output of the binary: > > StartEnd Type Open Ref GrpRef Name > 0d8efcc5 0d8efcc55000 exe 10 0 test > 0d910d122000 0d910d216000 rlib 01 0 /usr/lib/libc.so.96.0 > 0d91079b6000 0d91079b6000 ld.so 01 0 /usr/libexec/ld.so > > I've moved the libraries listed in the ldd command output to the /var/www > directory for proper chrooting, and still getaddrinfo doesn't work. > > Has anyone experienced this before and is there a possible solution? Thank you > in advance. > > > Ben Raskin. > In these cases ktrace is your friend. My guess would be your chroot does not contain a etc/resolv.conf and/ro etc/hosts file and you do not have a resolver running on 127.0.0.1 -Otto
crosscompiling binutils
Hi, I was wondering if binutils-2.17 will be that version for the next foreseeable future? Reason being is that there is backports to RISCV's binutils but they don't go that low to 2.17. Since I'm lazy, I don't really want to port binutils to 2.17 for any architecture if it's not already done so. Unfortunately I only invested a handful of days looking into the problem and just as many procrastinating around this. I lost contact to the riscv group, but if I rejoin them I'd like to give them something and not just look happy. :-) Peace. -peter
getaddrinfo(3) in CGI program
Hello, Misc; I'm attempting to write a CGI progam in C which uses getaddrinfo(3), however upon running the script getaddrinfo doesn't seem to run. I have a feeling this is due to linking issues as other have experienced a similar issue with glibc. Here is the ldd output of the binary: StartEnd Type Open Ref GrpRef Name 0d8efcc5 0d8efcc55000 exe 10 0 test 0d910d122000 0d910d216000 rlib 01 0 /usr/lib/libc.so.96.0 0d91079b6000 0d91079b6000 ld.so 01 0 /usr/libexec/ld.so I've moved the libraries listed in the ldd command output to the /var/www directory for proper chrooting, and still getaddrinfo doesn't work. Has anyone experienced this before and is there a possible solution? Thank you in advance. Ben Raskin.
Re: Inphi CS4223 for 4x 10GbE SFP+
Hello, re bypass mechanisms on on other platforms they can be just purely passive relays, that when power is attached to the system and the bios /EFI firmware confirms load (after the beep) an 8pole relay (that is normally closed electrically linking two RJ45 ports together, it can be useful in scenarios if you have only 1 interface from an uplink provider and only have routers with a single power supply each and you want to create a failsafe failover... I tend to use a scenario where the OS replicates the connectivity when the OS loads, i.e. place the 2 interfaces that are in the same bypass group into a bridge... one has to be careful not to create loops with that type of config... as far as im aware there is usually dip switches or jumper pins on the mainboard to facilitate it... sorry for going off on a tangent here.. but when I heard bypass I thought I would share some of my humble experience here... All the Best Tom On Tue, 20 Oct 2020 at 13:39, Stuart Henderson wrote: > On 2020-10-20, Harald Dunkel wrote: > > On 10/19/20 9:46 PM, Stuart Henderson wrote: > >> On 2020-10-19, Harald Dunkel wrote: > >>> > >>> What would these bypass problems look like? Hopefully the bypass > feature > >>> can be turned off/ignored. > >> > >> If there are problems then possibly 2 of the ports either won't work > >> or will be connected directly to 2 of the other ports until a magic > >> command is sent somehow (either gpio or via some memory mapped io > >> port I guess, I don't know the hardware). > >> > > > > You mean the bypass might be active, even though its not configured and > > power is on? That sounds like a fatal problem to me. Is this restricted > > to OpenBSD or are other operating systems affected as well? > > I don't know how it works on this hardware. The general idea of bypass > NICs is so that they connect ports straight-through if the OS is not > running correctly, so it depends how they detect whether the OS is running > as to whether that will work. > > One would hope that it can be disabled if necessary, but one would also > hope that BIOS/firmware vendors don't make silly mistakes and experience > has shown that this is not always the case ;) > > It will probably be OK. But with new hardware, who knows! > > -- Kindest regards, Tom Smyth.
Re: /dev/usb0 - NotImplementedError: Operation not supported or unimplemented on this platform
On 2020-10-22, Mario St-Gelais wrote:
> I am attempting to get data from USB or an Accurite Weather Sensor,
> model 06006 through python program called weewx. I wrote the weewx dist
> list but got no answer so far. I am in foact not sure it's related to
> weewx itself as I can not connect to the device even through ipython.
> Throuh ipython I get this output:
>===
> /usr/local/lib/python3.8/site-packages/usb/backend/libusb1.py in _check(ret)
> 583 if ret < 0:
> 584 if ret == LIBUSB_ERROR_NOT_SUPPORTED:
> --> 585 raise NotImplementedError(_strerror(ret))
> 586 elif ret == LIBUSB_ERROR_TIMEOUT:
> 587 raise USBTimeoutError(_strerror(ret), ret,
> _libusb_errno[ret])
>
> NotImplementedError: Operation not supported or unimplemented on this
> platform
>
> I of course get similar output if I try the acurite.py drive used by weewx:
>===
> PYTHONPATH=bin doas python3.8 bin/weewx/drivers/acurite.py
>
>
> Traceback (most recent call last):
> File "bin/weewx/drivers/acurite.py", line 982, in
> with Station() as s:
> File "bin/weewx/drivers/acurite.py", line 587, in __enter__
> self.open()
> File "bin/weewx/drivers/acurite.py", line 612, in open
> self.handle.detachKernelDriver(interface)
> File "/usr/local/lib/python3.8/site-packages/usb/legacy.py", line
> 294, in detachKernelDriver
> self.dev.detach_kernel_driver(interface)
> File "/usr/local/lib/python3.8/site-packages/usb/core.py", line 1094,
> in detach_kernel_driver
> self._ctx.backend.detach_kernel_driver(
> File "/usr/local/lib/python3.8/site-packages/usb/backend/libusb1.py",
> line 905, in detach_kernel_driver
> _check(self.lib.libusb_detach_kernel_driver(dev_handle.handle, intf))
> File "/usr/local/lib/python3.8/site-packages/usb/backend/libusb1.py",
> line 585, in _check
> raise NotImplementedError(_strerror(ret))
>
> NotImplementedError: Operation not supported or unimplemented on this
> platform
>
> usbdevs output:
>=
> YTHONPATH=bin doas python3.8 bin/weewx/drivers/acurite.py
>
>
> Traceback (most recent call last):
> File "bin/weewx/drivers/acurite.py", line 982, in
> with Station() as s:
> File "bin/weewx/drivers/acurite.py", line 587, in __enter__
> self.open()
> File "bin/weewx/drivers/acurite.py", line 612, in open
> self.handle.detachKernelDriver(interface)
> File "/usr/local/lib/python3.8/site-packages/usb/legacy.py", line
> 294, in detachKernelDriver
> self.dev.detach_kernel_driver(interface)
> File "/usr/local/lib/python3.8/site-packages/usb/core.py", line 1094,
> in detach_kernel_driver
> self._ctx.backend.detach_kernel_driver(
> File "/usr/local/lib/python3.8/site-packages/usb/backend/libusb1.py",
> line 905, in detach_kernel_driver
> _check(self.lib.libusb_detach_kernel_driver(dev_handle.handle, intf))
> File "/usr/local/lib/python3.8/site-packages/usb/backend/
>
> Could someone shed some light on this. I will provide more info if
> required. Any other alternative to access this device?
>
> usbdevs output:
>
> doas usbdevs -v -d /dev/usb0
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
> super speed, self powered, config 1, rev 1.00
> driver: uhub0
> addr 02: 24c0:0003 vendor 0x24c0, Chaney Instrument
> low speed, power 100 mA, config 1, rev 0.20
> driver: uhidev0
>
Try removing the call to detachKernelDriver,
https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/acurite.py#L610
You can also try building a kernel with the device blacklisted from the
uhid driver, it should then attach to ugen(4) which will allow libusb to do
more things with it. Diff below; after applying run "make" in sys/dev/usb
before building/installing a new kernel.
Index: usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.76
diff -u -p -r1.76 usb_quirks.c
--- usb_quirks.c5 Jan 2020 00:54:13 - 1.76
+++ usb_quirks.c22 Oct 2020 10:40:11 -
@@ -123,6 +123,7 @@ const struct usbd_quirk_entry {
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD2, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_SPEAKERS, ANY,{ UQ_BAD_HID }},
+ { USB_VENDOR_CHANEY, USB_PRODUCT_CHANEY_ACURITE, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM_OLD, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_SISPM_FLASH,ANY,{
UQ_BAD_HID }},
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.720
diff -u -p -r1.720 usbdevs
--- usbdevs 3
Re: Inphi CS4223 for 4x 10GbE SFP+
On 2020-10-21, Harald Dunkel wrote: >> dmesg would be of interest :) > > See attachment. Product web site: > > https://www.ibase.com.tw/english/ProductDetail/NetworkAppliance/FWA8506 > > OpenBSD 6.8 booted from USB cdrom and installed fine. I didn't try > the USB installer image. > > The host was preconfigured with serial console enabled. 115200 8N1. > There was no VGA adapter included. There is no bezel for a VGA socket, > either. There is however a bezel for a PCI card included. > > Hope this helps Nice, thanks. That looks like it should make a pretty decent router/firewall.
Re: Issue updating spidermonkey
On 2020-10-21, Brennan Vincent wrote: > Will the URL to check look something like > https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ? > > I checked there; all the files were touched within a 10 minute period. See Antoine's answer about spidermonkey, but note that "cdn.openbsd.org" is basically a fancy web cache setup. You cannot trust the directory listing to reflect the files that you fetch from inside that directory. The listing is just "an object", i.e. the html page with the index, which can be cached in whole - and is more likely to be cached by the CDN than some random package because it's frequently accessed and reasonably small (good hit rate, low resource use). Personally I recommend *not* using the CDN for snapshots. For releases it varies; you won't suffer from this same problem because the files (mostly) don't change - but if your nearest CDN node is far away from the origin server that it fetches/caches from, and you have a decent local mirror, you're likely to see better speeds from the local mirror.
Re: Multiple USB NICs
2020-10-22 07:35, Stuart Longland wrote: PCIe devices _can_ be connected to a Raspberry Pi 4, but it's a rather hap-hazard process that's not recommended unless you _really_ like re-working high-speed data links on printed circuit boards. Closest you get on a 'Pi is maybe some of the SPI Ethernet ICs that you might be able to hook to the GPIO header, but then you'd have to hack the OpenBSD kernel to support it, and it won't support gigabit speeds. That's not entirely true anymore. Just the other day the RPi Compute Module 4 was released. It exposes the PCI interface. From the Datasheet [1] 2.3. PCIe (Gen2 x1) The CM4 has an internal PCIe 2.0 x1 host controller. While on the Raspberry Pi 4, Model B this has been connected to a USB 3 host controller (using the Via Labs VLI805), on the CM4 the product designer is free to choose how the interface is used. A standard x86 machine and a multi-port network card is looking pretty good at this point. Yes, this still holds true. If low power consumption is not crucial, I too would rather go for a decent amd64 plattform. [1]: https://datasheets.raspberrypi.org/cm4/cm4-datasheet.pdf
Re: possible relayd.conf(5) documentation mistake regarding session tickets
Sebastian Benoit(benoit-li...@fb12.de) on 2020.10.21 21:26:00 +0200:
> Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> > In relayd.conf(5), the tls section under PROTOCOLS states the following:
> >
> > no session tickets
> > Disable TLS session tickets. relayd(8) supports stateless TLS
> > session tickets (RFC 5077) to implement TLS session resumption.
> > The default is to enable session tickets.
> >
> > However, an SSL Labs test[1] without `tls { session tickets }` specified
> > shows no session tickets.
>
> There are two things i believe happening:
>
> * i'm not sure we wanted session resumption to be enabled by default because
> of the security implications regarding perferct forward secrecy. Indeed the
> option is off by default at the moment.
It's disabled by default on purpose.
Manpage is updated.
>
> * With TLS 1.3, session resumption is called pre-shared key) resumption.
> I have to check what the issue here is, that is if qualys does not show this
> right or if relayd has to do something different.
Indeed, our TLS 1.3 does not yet support session resumption.:
> For now, with the following options you should see session resumption:
>
> tls { session tickets, tlsv1.2, no tlsv1.3 }
Of course if you just do
tls { session tickets }
clients that support 1.3 wont get it, but ones that do not support 1.3 will.
Best,
Benno
Re: Issue updating spidermonkey
On Wed, Oct 21, 2020 at 06:43:13PM -0400, Brennan Vincent wrote: > > On 10/21/20 4:40 AM, Stuart Henderson wrote: > > On 2020-10-21, Chris Bennett wrote: > > > On Tue, Oct 20, 2020 at 08:26:05PM -0400, Brennan Vincent wrote: > > > > Updated yesterday from 6.7 to a snapshot, and now: > > > > > > > > $ doas pkg_add -u > > > doas pkg_add -u -Dsnap > > > > > > You need to do some things different once you change to -current > > > snapshots. > > > Might also have to wait for -current packages to match the -current > > > snapshot sometimes. > > -Dsnap does nothing for most of the year. The only thing it's useful for is > > pointing to the snapshots directory whdn you're running a kernel with no > > -beta/-current suffix (i.e. a release, or snapshot in the short period in > > the run-up to release). > > > > > > quirks-3.458 signed on 2020-10-18T13:56:14Z > > This shows that it is indeed looking at a snapshot directory not release. > > > > > > Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update > > > > found > > > > for spidermonkey-60.9.0v1 > > > > Can't install polkit-0.116p1->0.118: can't resolve > > > > spidermonkey78-78.3.1v1 > > > > > > > > Is this expected soon after updating? Do I just need to wait for some > > > > inconsistency in the pkg repo to be resolved? > > This could either be: > > > > - a bug in some port > > > > - a package source that does not have a consistent set of files from one > > build (can happen when a mirror is updating) > > > > First thing to do if this happens is check file dates in the mirror's > > directory listing and see if they're consistent (no big jump between the > > a* and z* files). > > Will the URL to check look something like > https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ? > > I checked there; all the files were touched within a 10 minute period. > > Issue is persisting. Should be fixed in a current. Wait a few days for new packages. -- Antoine
