Re: Ping blocked by firewall
On Tue, Apr 09, 2024 at 08:39:08AM +0200, Karel Lucas wrote: > Hi all, > > For the first time I tested my new firewall with ping, and it is blocked. I > don't know what the reason is, you can find the information below. I have a > network with only regular clients, so no servers. I'm still using OpenBSD > V7.4, and will upgrade once the firewall is up and running so I can test the > upgrade process. Upgrading to 7.5 will not affect this particular problem I think. Still low on caffeine I spot two likely factors - your $localnet range overlaps with one of the ranges in $martians (which I anyway would recommend converting into a table), and your block referencing $martians comes after the pass rules that would have let icmp through. With no previous matching quick, last match applies. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Ping blocked by firewall
Hi all,
For the first time I tested my new firewall with ping, and it is
blocked. I don't know what the reason is, you can find the information
below. I have a network with only regular clients, so no servers. I'm
still using OpenBSD V7.4, and will upgrade once the firewall is up and
running so I can test the upgrade process.
/etc/pf.conf:
ext_if = igc0 # Extern interface
int_if = "{ igc1, igc2 }" # Intern interfaces
localnet = "192.168.2.0/24"
tcp_services = "{ smtp, domain, www, auth, http, https, pop3, pop3s }"
udp_services = "{ domain, ntp }"
email = "{ smtp, imap, imaps, imap3, pop3, pop3s }"
icmp_types = "{ echoreq, unreach }"
icmp6_types = "{ echoreq, unreach }"
nameservers = "{ 195.121.1.34, 195.121.1.66 }"
client_out = "{ ssh, domain, pop3, auth, nportntp, http, https, \
446, cvspserver, 2628, 5999, 8000, 8080 }"
Martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
10.0.0.0/8, 169.254, 0.0/16, 192.0.2.0/24, \
0.0.0.0/8, 240.0.0.0/4 }"
set skip on lo
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
block log all # block stateless traffic
# Letting ping through:
pass log on inet proto icmp icmp-type $icmp_types
pass log on inet6 proto icmp6 icmp6-type $icmp6_types
# Allow out the default range for traceroute(*):
# "base+nhops*nqueries-1" (3434+64*3-1)
pass log out on ext_if inet proto udp to port 33433:33626 # for IPv4
pass log out on ext_if inet6 proto udp to port 33433:33626 # for IPv6
pass log quick on $ext_if inet proto {tcp, udp} from $localnet \
to port $udp_services
pass log on $ext_if inet proto icmp all icmp-type $icmp_types
pass log on $ext_if inet proto tcp from $localnet to port $client_out
block log in quick on $ext_if from $martians to any
block log out quick on $ext_if from any to $martians
pass log out proto tcp to port $tcp_services # establish keep-stat
pass log log proto udp to port $udp_services # Establish keep-state
/var/log/pflog:
tcpdump: WARNING: snaplen raised from 116 to 160
Apr 09 08:16:45.009497 :: > ff02::16: HBH multicast listener report v2,
2 group record(S) [hlim 1]
apr 09 08:16:45.009500 :: > ff02::16: HBH multicast listener report v2,
2 group record(S) [hlim 1]
Re: Libressl verify failure with 3.9.0
On Mon, Apr 08, 2024 at 05:53:47PM -0500, Ted Wynnychenko wrote: > Thanks for the suggestion. > The workaround does work, and creates (essentially) the same certificate, > but one that does not fail verification with the new libressl. > I did notice the option of not have the leading "20" for dates before 2050, > but I did not know enough to try doing that. Great. openssl ca should be smart enough to do that for you. It tried to, but failed due to a bug. This will be fixed in the next release: https://github.com/openbsd/src/commit/72c7c57a68e32c57ac752161b5a93464ad11e7e1 The incomprehensible verification error is another bug and that will also be fixed.
Re: OpenBSD 7.5 bsd.upgrade hangs after sysupgrade
On 4/7/24 10:42, Страхиња Радић wrote: Дана 24/04/07 12:46PM, Страхиња Радић написа: Ok. The alternative would be to find a way to make 7.5 efifb work on my laptop. The version of efifb from 7.4 works (that is how I installed 7.4 in the first place), unlike 7.5 efifb. I'd just like to add that it efifb might not even be the reason for system hang. I noticed these lines in the output from 7.5 bsd.upgrade I got when I entered `verbose` at the UKC prompt and exited UKC: uhub0: device problem, disabling port 2 uhub0: device problem, disabling port 3 uhub0: device problem, disabling port 5 uhub0: device problem, disabling port 6 on my working 7.4 system, I have uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev \ 3.00/1.00 addr 1 and later urtwn0 at uhub0 port 2 configuration 1 interface 0 "Realtek 802.11n \ NIC" rev 2.00/0.00 addr 2 urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address uhidev0 at uhub0 port 3 configuration 1 interface 0 "SiGmaMicro USB \ Optical Mouse" rev 1.10/1.10 addr 3 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse2 at ums0 mux 0 uvideo0 at uhub0 port 5 configuration 1 interface 0 "Sonix Technology \ Co., Ltd. Integrated Camera" rev 2.00/0.28 addr 4 video0 at uvideo0 ugen0 at uhub0 port 6 "Atheros Communications product 0xe300" rev \ 2.01/0.01 addr 5 so the devices which have a "problem" are all devices connected to USB ports; or rather, the USB hub itself? Are there any regressions in the AMD xHCI hub code? My 100% guess is that you have a machine that's very dependent upon ACPI, and the install kernel's ACPI support is very minimal, or has a funny UEFI system. Or a funny BIOS. Some machines work better as UEFI, some work better running BIOS. A firmware upgrade may change that (which could suck). There are other ways, though... First, I would verify that the 7.5 kernel boots -- copy it to /bsd75, for example, then "boot bsd75 -s" (the -s is so it doesn't try to go multi-user with a mixed new kernel/old userland/packages). If that seems happy, just do a "remote upgrade", using the "Manual Upgrade (without the install kernel)" process in https://www.openbsd.org/faq/upgrade75.html. Nick.
Wireless network with bfwm sometimes works and sometimes doesn't
Hi all, I'm not sure how to debug this systematically. I have OpenBSD 7.5 on Raspberry Pi 4 (but I had the same problem with 7.4 as well). Sometimes the computer connects to the wireless network at boot, and sometimes it doesn't, without any obvious pattern. Whenever it connects, it works fine and doesn't seem to be flaky or unusually slow, though I didn't measure. If it doesn't connect, despairingly calling `doas sh /etc/netstart bwfm0` or `doas ifconfig bwfm0 inet autoconf` sometimes helps, but more often doesn't. Other computers connected to the same network don't seem to be affected. This is what the output of ping looks like when it doesn't connect: PING 192.168.0.1 (192.168.0.1): 56 data bytes ping: sendmsg: Can't assign requested address (these two lines repeat until I ^C) --- 192.168.0.1 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss This is what the output of `ifconfig bwfm0` looks like when it doesn't connect: bwfm0: flags=a48843 mtu 1500 lladdr e4:5f:01:4d:c2:2c index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (OFDM6 mode 11a) status: no network ieee80211: join NETWORK_IN_QUESTION_5G chan 112 bssid f0:af:85:9a:e4:23 -69dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet6 fe80::e65f:1ff:fe4d:c22c%bwfm0 prefixlen 64 scopeid 0x4 This is my /etc/hostname.bwfm0: join NETWORK_IN_QUESTION_5G wpakey PASSWORD inet6 autoconf inet autoconf I would appreciate any suggestions. Regards Stanislav Syekirin
some weird problem with em network interface
Hello I've been using a pcengines apu4 board for about 3 years now. I noticed a problem that I can't precisely undestand with the em network interfaces (Intel I211). I'm using 2 interfaces in gigabit mode, one in 100 Mbps and another in 10 Mbps. Intefaces in gigabit mode work very well. The other ones are intermitent. Sometimes works and suddenly stop working. For instance, when I ping the interfaces (100 and 10 Mbps) from another computer connected to the network sometimes works and sometimes don't. When the problem occurs, the packets don't show up in tcpdump. I connected another interface (axe0: AX88772) in USB port and configured it exactly the same as a 10 or 100 Mbps interface and it works perfectly, with no errors at all. My question is: is there any known problem with the em driver ? Thanks, Paulo.
7.5 problems with browser video and audio
Hello, after upgrade to 7.5 (from 7.4) I have problems with all type of videos on all chromium flavor (ungoogled-chromium and iridium). Going in details the problem doesn't concern only youtube but all the videos in all websites. But some videos work. For example youtube shorts. But on all videos does not work. I tried to uninstall and reinstall two or three dozen of packages linked to the browser but I haven't solved the problem. I have the same problem with firefox. But if I play a video with "mpv video.mp4" it works very well, also the audio works. So it seems something linked to the browsers. The following is the log if I run a chromium session and I play a random video on yt: [80102:471841344:0408/172622.858323:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858491:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858540:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172622.858617:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172622.913110:ERROR:policy_logger.cc(157)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(161) Cloud management controller initialization aborted as CBCM is not enabled. Please use the `--enable-chrome-browser-cloud-management` command line flag to enable it if you are not using the official Google Chrome build. [80102:471841344:0408/172623.027251:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.027532:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:-403990976:0408/172623.202595:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.290231:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471841344:0408/172623.290334:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [53057:-337215584:0408/172623.654661:ERROR:viz_main_impl.cc(196)] Exiting GPU process due to errors during initialization [80102:1069694880:0408/172624.173294:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:1569613376:0408/172624.173820:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:471835200:0408/172624.519144:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:471835200:0408/172624.520532:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:471835200:0408/172624.522130:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [80102:1069694880:0408/172624.570929:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:-403991488:0408/172624.571398:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172624.638201:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: [80102:-403991488:0408/172624.638367:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [80102:1069694880:0408/172624.665200:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.Name
Re: 7.5: Fatal errors from eigrpd
(Gah! Here's the post again in plaintext. Apologies.)
Hello all,
I'm running eigrpd in a VMWare environment and after upgrading to 7.5 from
7.4 I'm noticing eigrpd is failing with a couple different errors. In 7.4
and prior I never had any problems.
I tried to include everything that I thought might be relevant but if
there's any other information I can provide please let me know.
Has anyone else come across anything similar?
Thanks,
Mark
examples:
test1# eigrpd -dv
startup
eigrp_if_start: lo1 as 1 family ipv4
eigrp_if_start: em0 as 1 family ipv4
if_join_ipv4_group: interface em0 addr 224.0.0.10
rt_new: prefix aa.bb.cc.1/32
route_new: prefix aa.bb.cc.1/32 via connected distance (28160/0)
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
fatal in eigrpe: send_packet: get hdr failed
rt_del: prefix aa.bb.cc.1/32
route_del: prefix aa.bb.cc.1/32 via connected
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
terminating
and
RouterTest# eigrpd -dv
startup
eigrp_if_start: em1 as 1 family ipv4
if_join_ipv4_group: interface em1 addr 224.0.0.10
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
eigrp engine terminated; signal 11
terminating
This is happening on two of two upgraded VMs.
SHA256 (/usr/sbin/eigrpd) =
3b85d7ac155afe4edd355f8b1d8c81f77c6254d96410af8b22f4018b756282a6
(just in case)
I've tried with net.inet.tcp.tso=0 and net.inet.tcp.tso=1. Same result.
test1# uname -a
OpenBSD test1.local 7.5 GENERIC.MP#82 amd64
The configs I'm running are pretty basic:
RouterTest# eigrpd -n
configuration OK
RouterTest# eigrpd -nv
router-id 198.18.101.1
fib-update yes
rdomain 0
fib-priority-internal 28
fib-priority-external 28
fib-priority-summary 28
address-family ipv4 {
autonomous-system 1 {
k-values 1 0 1 0 0 0
active-timeout 3
maximum-hops 100
maximum-paths 4
variance 8
default-metric 10 10 255 1 1500
interface em1 {
hello-interval 5
holdtime 15
delay 10
bandwidth 10
split-horizon yes
}
}
}
address-family ipv6 {
}
7.5: Fatal errors from eigrpd
Hello all,
I'm running eigrpd in a VMWare environment and after upgrading to 7.5 from
7.4 I'm noticing eigrpd is failing with a couple different errors. In 7.4
and prior I never had any problems.
I tried to include everything that I thought might be relevant but if
there's any other information I can provide please let me know.
Has anyone else come across anything similar?
Thanks,
Mark
examples:
test1# eigrpd -dv
startup
eigrp_if_start: lo1 as 1 family ipv4
eigrp_if_start: em0 as 1 family ipv4
if_join_ipv4_group: interface em0 addr 224.0.0.10
rt_new: prefix aa.bb.cc.1/32
route_new: prefix aa.bb.cc.1/32 via connected distance (28160/0)
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
fatal in eigrpe: send_packet: get hdr failed
rt_del: prefix aa.bb.cc.1/32
route_del: prefix aa.bb.cc.1/32 via connected
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
terminating
and
RouterTest# eigrpd -dv
startup
eigrp_if_start: em1 as 1 family ipv4
if_join_ipv4_group: interface em1 addr 224.0.0.10
rt_new: prefix 198.18.101.0/24
route_new: prefix 198.18.101.0/24 via connected distance (28160/0)
rt_del: prefix 198.18.101.0/24
route_del: prefix 198.18.101.0/24 via connected
route decision engine exiting
kernel routing table decoupled
waiting for children to terminate
eigrp engine terminated; signal 11
terminating
This is happening on two of two upgraded VMs.
SHA256 (/usr/sbin/eigrpd) =
3b85d7ac155afe4edd355f8b1d8c81f77c6254d96410af8b22f4018b756282a6
(just in case)
I've tried with net.inet.tcp.tso=0 and net.inet.tcp.tso=1. Same result.
test1# uname -a
OpenBSD test1.local 7.5 GENERIC.MP#82 amd64
The configs I'm running are pretty basic:
RouterTest# eigrpd -n
configuration OK
RouterTest# eigrpd -nv
router-id 198.18.101.1
fib-update yes
rdomain 0
fib-priority-internal 28
fib-priority-external 28
fib-priority-summary 28
address-family ipv4 {
autonomous-system 1 {
k-values 1 0 1 0 0 0
active-timeout 3
maximum-hops 100
maximum-paths 4
variance 8
default-metric 10 10 255 1 1500
interface em1 {
hello-interval 5
holdtime 15
delay 10
bandwidth 10
split-horizon yes
}
}
}
address-family ipv6 {
}
Re: OpenBSD 7.5 - relayd -> vaultwarden - websockets payload not working
It's certainly possible that some of the relayd hardening changes are to blame. Would you be able to rebuild relayd with some of those commits reverted to see if one of them is to blame? - todd
Re: 7.5 NO hard drive?
On 4/7/24 03:03, lati...@vcn.bc.ca wrote: Hello i have 1 DELL Latitude E4300 that had OBSD 7.3 working correctly, but i decided to do a clean installation of 7.5 deleting everything on it with a live cd linux; then tested 7.5 and it says NO disk. After that i tested Linux, NetBSD, FreeBSD all them where installed without a problem; But, OBSD 7.3 7.4 7.5 said NO disk! It is something related to OBSD? What could happened? How to install OBSD 7.5 PS: Thanks for the new version 7.5 i run 2 laptops and 1 server with it! Thanks So OpenBSD has been correctly installed, thanks so much to maintain it nice! The problem was with the BIOS, it needs IHCH or something like that to be recognized! But it is working now as a xfce Desktop! probably AHCI and not the so-called RAID mode that many Dells default to, but definitely not Dell only "feature". This is our 25+ year "friend", BIOS assisted software RAID. The idea is the BIOS will handle initial tagging and replication of the drive until the OS is booted, then the OS takes over as it takes over the low-level disk support. This handles the "boot off any surviving disk" issue, but it creates a huge potential issue where a drive might end up being duplicated by the BIOS to a second disk...unintended! This would be bad. Not only could you clobber data on a second drive, but in the modern world of UUIDs for disks, you just put two disks on the same system with the same "uniq" identifiers, and one of those disks is very incomplete. This is also bad. OpenBSD disabled this "RAID" mode support over ten years ago (from memory), FreeBSD did around the same time, and a number of Linux distros took their time, but eventually did the same thing. Now...this was true on OpenBSD 7.3 as well, so something changed on your computer, I'm suspicious your CMOS battery has died, and the system came back up in the defaults, which include this RAID "feature". Nick.
Re: Libressl verify failure with 3.9.0
> On Apr 8, 2024, at 5:44 AM, Theo Buehler wrote: > > On Sun, Apr 07, 2024 at 04:57:24PM -0500, Ted Wynnychenko wrote: >> Hello, >> >> I recently updated to -current (about a week ago). >> >> I see that Libressl is at 3.9.1 just now, but I hope that won't be an issue >> (I did not see anything in the release notes that would impact my question). >> --- >> $ openssl version >> LibreSSL 3.9.0 >> --- >> >> Over the years, I have made certificates for personal servers/resources on >> my home network. This is just for me, so I do some things that would be >> frowned on (although, technically, there is nothing "wrong" with them). >> >> In this case, since I have Apple iOS devices that I want to connect to >> https, I backdate any certificates I create to 1/2/2019. Apple has imposed >> a 300 or 800 day time limit on the validity for certificates created after >> (about) 7/1/2019. Since I don't want to constantly make new certificates >> for my personal/home network, I have just been setting the certificates' >> "not before" date to early 2019. >> >> Anyway, this had worked fine. >> In fact, earlier this year (Jan 2024), I created a new certificate, and all >> is good. >> >> A few weeks ago, I added a new thing to the network - a raspberry pi (I got >> as a gift about 2013 and installed a linux image from 2019 on it) that is >> connected to the home alarm system. >> >> Since I was annoyed that my browser was constantly giving me self-signed >> certificate warnings, I decided to make a certificate for the nginx running >> on this appliance. >> >> I created a key, made a csr, and then signed it with: >> openssl ca -startdate 2019010200Z -in pi.csr -out pi.pem -config >> /etc/ssl/openssl.cnf Did you create this certificate on OpenBSD with Libressl openssl? Or on linux or something else with an OpenSSL openssl? > > As a workaround, try using '-startdate 19010200Z' instead. I think > this is fallout from this commit: > > https://github.com/openbsd/src/commit/3feee4c53fbd67a4a480080d8ef5ae835d3fbf82 > > ASN1_TIME_set_string_X509() is documented as > > In LibreSSL, ASN1_TIME_set_string() and ASN1_TIME_set_string_X509() > behave identically and always set the time object to a valid value to use > in an X.509 certificate. > > It seems to me that this is just wrong (it is true that both behave > identically because RFC5280 is defined to 0), but they do not set the > time object to "a valid value to use in an X.509 certificate". > > Confusingly, ASN1_TIME_adj_internal() actually honours its RFC5280 > parameter by behaving the expected way whereas its meaning in > ASN1_TIME_set_string_internal() is different. > > I am unsure if the bug is in my commit above or in our version of > ASN1_TIME_set_string_X509() (or both). > >> >> This all works fine, and a certificate is created >> >> When I check with: >> openssl x509 -text -noout -in pi.pem >> >> everything seems as expected, including the not before/after dates: >> >>Validity >>Not Before: Jan 2 00:00:00 2019 GMT >>Not After : Apr 7 15:39:59 2054 GMT >> >> (yes, it is valid for 35 years - as I said before, if someone breaks into my >> house to secretly do things, I have way bigger problems) >> >> But, if I try to verify this on the openbsd system, I get: >> >> # openssl verify pi.pem >> C = US, ST = Illinois, L = ***, O = ***, OU = ***, CN = *** >> error 20 at 0 depth lookup:unable to get local issuer certificate >> pi.pem: verification failed: 20 (unable to get local issuer certificate) >> --- >> >> But, if I install this on the raspberry pi, which has a much older version >> of openssl on it: >> $ openssl version >> OpenSSL 1.1.1c 28 May 2019 >> >> The certificate verifies without an issue: >> $ openssl verify pi.pem >> pi.pem: OK >> >> The last time I created a certificate was in January of this year >> (1/22/2024). >> I am thinking the openbsd system was using Libressl 3.8.2 at that point. >> >> I created that certificate in the exact same way, backdating the start date: >> openssl ca -startdate 2019010200Z -in 54.csr -out 54.pem -config >> /etc/ssl/openssl.cnf >> >> This previously created certificate also has them same backdated and very >> long valid period: >> >>Validity >>Not Before: Jan 2 00:00:00 2019 GMT >>Not After : Jan 21 23:49:22 2054 GMT >> >> (Notice the not after date is a little different) >> Today, with the new libressl, this certificate verifies OK. >> >> $ openssl verify 54.pem >> 54.pem: OK >> >> Finally, if I create the new certificate WITHOUT backdating it >> e.g.: openssl ca -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf >> >> The certificate is created and verifies OK. >> >> So, it seems, there is some sort of issue with backdating the certificate, >> but not an issue with the crazy long validity window, that was not present >> in January of this year. >> >> However, as I said, if I
Re: Minimum viable HW for OpenBSD
Hi, I lost the thread in my mutt, so I'm hoping marc.info will adjust it in there, the thread is here: https://marc.info/?l=openbsd-misc&m=171059471410619&w=2 Thank you Gabor Nagy! Here is my RPI zero 2W(H) with working wifi in hostap mode, and hopefully working GPIO's I'm going to be studying those closer in the future when I have some time. https://mainrechner.de/P4080036.JPG <-- on my tarot table Best Regards, -pjp -- my associated domains: callpeter.tel|centroid.eu|dtschland.eu|mainrechner.de
Re: 7.5 NO hard drive?
On Sun, Apr 07, 2024 at 05:17:25PM +0200, Wolfgang Pfeiffer wrote: On Sun, Apr 07, 2024 at 12:03:21AM -0700, lati...@vcn.bc.ca wrote: Hello i have 1 DELL Latitude E4300 that had OBSD 7.3 working correctly, but i decided to do a clean installation of 7.5 deleting everything on it with a live cd linux; then tested 7.5 and it says NO disk. After that i tested Linux, NetBSD, FreeBSD all them where installed without a problem; But, OBSD 7.3 7.4 7.5 said NO disk! [ ... ] Seems to be (not only) a DELL thing: Some time ago I tried an Openbsd installer on an Alienware computer, ~10 years old, which was sold by DELL: In UEFI, IIRC, I had to change sata mode from "raid" to "ahci" to let openbsd detect hard disks on that computer. Seems to an older issue: https://daemonforums.org/showthread.php?t=10228 https://www.mail-archive.com/misc@openbsd.org/msg153583.html IIRC, Debian, Fedora, Windows installed without problems on that machine: at least in my case it might be a problem with a BIOS version too old for an openbsd install - not being sure .. Found an article on dell.com titled: "Recommended BIOS Settings for your Linux System" that says: "Linux does not natively support SATA Operation in RAID On mode as of May 2022." Dell later in the article recommends to switch on AHCI for SATA mode: https://www.dell.com/support/kbdoc/en-us/000123462/recommended-bios-settings-for-your-linux-system -- Wolfgang
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Given logger foo;xterm -tn xterm-256color -e ktrace -di /bin/ksh the log message 'ksh: vfprintf %s NULL in "%.*s"' appears when ~/.terminfo/x/xterm/xterm-256color does not exist. The log message no longer appears after running cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/ and comes back after deleting the ~/.terminfo/x/xterm-256color file. The kdump when the log message happens runs along the lines of: 79510 ksh CALL access(0x744b97b272e0,0x4) 79510 ksh NAMI "/home/jmates/.terminfo/x/xterm-256color" 79510 ksh RET access -1 errno 2 No such file or directory 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL open(0x744b97b1b600,0x1) 79510 ksh NAMI "none.db" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x3) 79510 ksh RET mprotect 0 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x1) 79510 ksh RET mprotect 0 79510 ksh CALL open(0x744b97b1eed0,0x1) 79510 ksh NAMI "none" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL sendsyslog(0x744b97b1c140,35,0<>) 79510 ksh GIO fd -1 wrote 35 bytes "<10>ksh: vfprintf %s NULL in "%.*s"" 79510 ksh RET sendsyslog 0
Re: Packages upgrade failure after upgrading to 7.5
On 2024-04-08, Ioan Samarul wrote: > Hello to you all! > > I upgraded without problem to 7.5, everything went smooth as always, > except when I tried to upgrade the packages. > > This are the errors of `doas pkg_add -uV` (there is no version of > firefox installed, if that helps) > > No pkgname in packing-list for .libs1-firefox-esr-91.13.0 > No pkgname in packing-list for .libs1-firefox-esr-102.13.0 > No pkgname in packing-list for .libs-firefox-esr-91.13.0 > Warning: couldn't read packing-list from installed package firefox-119.0 > File /var/db/pkg/firefox-119.0/+CONTENTS does not exist > Error: firefox-119.0 missing from installation You have some corruption in /var/db/pkg. I would try pkg_check and allow it to fix things. > to_install: > lcms2-2.15 => //lcms2-2.15/ > updatedb-0p0 => //updatedb-0p0/ > xz-5.4.5 => //xz-5.4.5/ > zstd-1.5.5 => //zstd-1.5.5/ > tiff-4.6.0 => //tiff-4.6.0/ > quirks-7.14 => //quirks-7.14/ > jpeg-3.0.2v0 => //jpeg-3.0.2v0/ > ImageMagick-6.9.12.96 => ImageMagick-6.9.12.96/ImageMagick-6.9.12.88p0// > lz4-1.9.4 => //lz4-1.9.4/ > libxml-2.12.5 => > libxml-2.12.5/libxml-2.11.5p0,.libs2-libxml-2.10.4,.libs2-libxml-2.9.13p2,.libs-libxml-2.9.13p2,.libs4-libxml-2.11.5p0,.libs1-libxml-2.10.4,.libs1-libxml-2.9.13p2,.libs3-libxml-2.10.4,.libs3-libxml-2.9.13p2,.libs7-libxml-2.11.5p0,.libs2-libxml-2.11.5p0,.libs-libxml-2.10.4,.libs8-libxml-2.11.5p0,.libs6-libxml-2.11.5p0,.libs-libxml-2.11.5p0,.libs1-libxml-2.11.5p0,.libs3-libxml-2.11.5p0,.libs5-libxml-2.11.5p0// > libiconv-1.17 => //libiconv-1.17/ > to_update: > hwdata-0.374 => /hwdata-0.374// > libebml-1.4.4 => /libebml-1.4.4// > libjxl-0.8.2 => /libjxl-0.8.2// > qtlocation-5.15.10 => /qtlocation-5.15.10// > poppler-data-0.4.12 => /poppler-data-0.4.12// > libavif-0.11.1p0 => /libavif-0.11.1p0// > .libs5-libxml-2.11.5p0 => > libxml-2.12.5/libxml-2.11.5p0,.libs2-libxml-2.10.4,.libs2-libxml-2.9.13p2,.libs-libxml-2.9.13p2,.libs4-libxml-2.11.5p0,.libs1-libxml-2.10.4,.libs1-libxml-2.9.13p2,.libs3-libxml-2.10.4,.libs3-libxml-2.9.13p2,.libs7-libxml-2.11.5p0,.libs2-libxml-2.11.5p0,.libs-libxml-2.10.4,.libs8-libxml-2.11.5p0,.libs6-libxml-2.11.5p0,.libs-libxml-2.11.5p0,.libs1-libxml-2.11.5p0,.libs3-libxml-2.11.5p0,.libs5-libxml-2.11.5p0// > pkglocatedb-1.5 => /pkglocatedb-1.5// > universal-ctags-6.0.0 => /universal-ctags-6.0.0// > py3-packaging-23.1 => /py3-packaging-23.1// > texlive_base-2022p0 => /texlive_base-2022p0// > py3-ifaddr-0.2.0 => /py3-ifaddr-0.2.0// > xclip-0.13p1 => /xclip-0.13p1// > ffmpeg-4.4.4p2v1 => /ffmpeg-4.4.4p2v1// > aspell-ro-3.3.2v1 => /aspell-ro-3.3.2v1// > py3-regex-2023.6.3 => /py3-regex-2023.6.3// > lua-5.2.4p1 => /lua-5.2.4p1// > aom-3.8.1 => /aom-3.8.1// > xfce4-mailwatch-1.3.1p1 => /xfce4-mailwatch-1.3.1p1// > libvidstab-1.1.0 => /libvidstab-1.1.0// > libev-4.33 => /libev-4.33// > http-parser-2.9.4 => /http-parser-2.9.4// > polybar-3.6.3p0 => /polybar-3.6.3p0// > lua-compat53-0.9 => /lua-compat53-0.9// > texlive_mktexlsr-2022p0 => /texlive_mktexlsr-2022p0// > libheif-1.16.2p0 => /libheif-1.16.2p0// > py3-autocommand-2.2.2 => /py3-autocommand-2.2.2// > libcares-1.19.1 => /libcares-1.19.1// > openal-1.23.1v0 => /openal-1.23.1v0// > tesseract-ron-4.1.0v0 => /tesseract-ron-4.1.0v0// > py3-jaraco.collections-3.8.0 => /py3-jaraco.collections-3.8.0// > gtk+3-3.24.38 => /gtk+3-3.24.38// > p5-Pango-1.227p3 => /p5-Pango-1.227p3// > py3-socks-1.7.1p5 => /py3-socks-1.7.1p5// > sqlite3-3.44.2 => /sqlite3-3.44.2// > libunbound-1.19.1 => /libunbound-1.19.1// > xfwm4-themes-4.10.0p0 => /xfwm4-themes-4.10.0p0// > .libs3-libxml-2.9.13p2 => > libxml-2.12.5/libxml-2.11.5p0,.libs2-libxml-2.10.4,.libs2-libxml-2.9.13p2,.libs-libxml-2.9.13p2,.libs4-libxml-2.11.5p0,.libs1-libxml-2.10.4,.libs1-libxml-2.9.13p2,.libs3-libxml-2.10.4,.libs3-libxml-2.9.13p2,.libs7-libxml-2.11.5p0,.libs2-libxml-2.11.5p0,.libs-libxml-2.10.4,.libs8-libxml-2.11.5p0,.libs6-libxml-2.11.5p0,.libs-libxml-2.11.5p0,.libs1-libxml-2.11.5p0,.libs3-libxml-2.11.5p0,.libs5-libxml-2.11.5p0// > xfce4-appfinder-4.18.1 => /xfce4-appfinder-4.18.1// > gvfs-1.50.6 => /gvfs-1.50.6// > libvpx-1.13.1v0 => /libvpx-1.13.1v0// > gmp-6.3.0 => /gmp-6.3.0// > json-glib-1.6.6p1 => /json-glib-1.6.6p1// > py3-MarkupSafe-2.1.3 => /py3-MarkupSafe-2.1.3// > .libs-libxml-2.11.5p0 => > libxml-2.12.5/libxml-2.11.5p0,.libs2-libxml-2.10.4,.libs2-libxml-2.9.13p2,.libs-libxml-2.9.13p2,.libs4-libxml-2.11.5p0,.libs1-libxml-2.10.4,.libs1-libxml-2.9.13p2,.libs3-libxml-2.10.4,.libs3-libxml-2.9.13p2,.libs7-libxml-2.11.5p0,.libs2-libxml-2.11.5p0,.libs-libxml-2.10.4,.libs8-libxml-2.11.5p0,.libs6-libxml-2.11.5p0,.libs-libxml-2.11.5p0,.libs1-libxml-2.11.5p0,.libs3-libxml-2.11.5p0,.libs5-libxml-2.11.5p0// > tracker3-miners-3.6.1 => /tracker3-miners-3.6.1// > py3-charset-normalizer-3.2.0 => /p
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-08, Eivind Eide wrote: > 24/04/06 06:04PM, Stuart Henderson: >> The fact that these all started hitting this with the same printf string >> (including tmux, which is in base) makes me wonder if it's coming from a >> library, the most likely being libcurses which was updated between 7.4 >> and 7.5 (which all of those use). >> >> Try to ascertain what's going on when that message is logged. ktrace >> might give some clues. > > Yes, I've been using these apps through numerous releases of OpenBSD > on this apu2 and this have never been triggered until I upgraded to > 7.5. > As pointed out, it also affects prominent members of base; tmux, top, ksh. > What seems to be in common for these apps are the version bump in > libcurses, that would be my guess too. > I tried passing different TERM, no change. I did "env -i mutt" but it > resulted in "Error opening terminal: unknown.". > But if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT > triggering the message. > OK. So I've tried to unset various environmental variables one after > another trying to hunt this down to one variable, but so far, no luck! > I don't understand anything 'bout ktrace, but when I have the time I > could try to look into that... It might be easier to try adding them one by one to the env -i line. If you can find the variable that's triggering it then hopefully others will be able to replicate the problem and track it down. -- Please keep replies on the mailing list.
Re: TLS handshake failure at pkg_update
Mizsei Zoltán : > doas pkg_add [...] > https://ftp2.eu.openbsd.org/pub/OpenBSD//7.5/packages/amd64/: TLS handshake > failure: handshake failed: error:02FFF00D:system > library:func(4095):Permission denied It sounds like your user context (by doas) is not enough to complete pkg_add operations. I suggest to go for the superuser by chance. -Dan
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
24/04/06 06:04PM, Stuart Henderson: > The fact that these all started hitting this with the same printf string > (including tmux, which is in base) makes me wonder if it's coming from a > library, the most likely being libcurses which was updated between 7.4 > and 7.5 (which all of those use). > > Try to ascertain what's going on when that message is logged. ktrace > might give some clues. Yes, I've been using these apps through numerous releases of OpenBSD on this apu2 and this have never been triggered until I upgraded to 7.5. As pointed out, it also affects prominent members of base; tmux, top, ksh. What seems to be in common for these apps are the version bump in libcurses, that would be my guess too. I tried passing different TERM, no change. I did "env -i mutt" but it resulted in "Error opening terminal: unknown.". But if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT triggering the message. OK. So I've tried to unset various environmental variables one after another trying to hunt this down to one variable, but so far, no luck! I don't understand anything 'bout ktrace, but when I have the time I could try to look into that... -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: TLS handshake failure at pkg_update
Thanks for the feedback, but I am sure ntpd is running and the time, date and the timezone configured properly, so the reason must be something else. Regards, --ext whistlez írta 2024. ápr.. 8, H-n 14:27 órakor: > Il 2024-04-08 09:14 Mizsei Zoltán ha scritto: >> Hi, > >> vps$ doas pkg_add micro >> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages-stable/amd64/: >> TLS handshake failure: handshake failed: error:02FFF00D:system >> library:func(4095):Permission denied >> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: TLS >> handshake failure: handshake failed: error:02FFF00D:system >> library:func(4095):Permission denied >> https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: empty >> Can't find micro > > I had this problem in the past and usually means that your clock is not > synchronized. > Maybe you stopped ntpd ? -- --Z--
Re: TLS handshake failure at pkg_update
Il 2024-04-08 09:14 Mizsei Zoltán ha scritto: > Hi, > vps$ doas pkg_add micro > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages-stable/amd64/: > TLS handshake failure: handshake failed: error:02FFF00D:system > library:func(4095):Permission denied > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: TLS > handshake failure: handshake failed: error:02FFF00D:system > library:func(4095):Permission denied > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: empty > Can't find micro I had this problem in the past and usually means that your clock is not synchronized. Maybe you stopped ntpd ?
Re: Libressl verify failure with 3.9.0
On Sun, Apr 07, 2024 at 04:57:24PM -0500, Ted Wynnychenko wrote: > Hello, > > I recently updated to -current (about a week ago). > > I see that Libressl is at 3.9.1 just now, but I hope that won't be an issue > (I did not see anything in the release notes that would impact my question). > --- > $ openssl version > LibreSSL 3.9.0 > --- > > Over the years, I have made certificates for personal servers/resources on > my home network. This is just for me, so I do some things that would be > frowned on (although, technically, there is nothing "wrong" with them). > > In this case, since I have Apple iOS devices that I want to connect to > https, I backdate any certificates I create to 1/2/2019. Apple has imposed > a 300 or 800 day time limit on the validity for certificates created after > (about) 7/1/2019. Since I don't want to constantly make new certificates > for my personal/home network, I have just been setting the certificates' > "not before" date to early 2019. > > Anyway, this had worked fine. > In fact, earlier this year (Jan 2024), I created a new certificate, and all > is good. > > A few weeks ago, I added a new thing to the network - a raspberry pi (I got > as a gift about 2013 and installed a linux image from 2019 on it) that is > connected to the home alarm system. > > Since I was annoyed that my browser was constantly giving me self-signed > certificate warnings, I decided to make a certificate for the nginx running > on this appliance. > > I created a key, made a csr, and then signed it with: > openssl ca -startdate 2019010200Z -in pi.csr -out pi.pem -config > /etc/ssl/openssl.cnf As a workaround, try using '-startdate 19010200Z' instead. I think this is fallout from this commit: https://github.com/openbsd/src/commit/3feee4c53fbd67a4a480080d8ef5ae835d3fbf82 ASN1_TIME_set_string_X509() is documented as In LibreSSL, ASN1_TIME_set_string() and ASN1_TIME_set_string_X509() behave identically and always set the time object to a valid value to use in an X.509 certificate. It seems to me that this is just wrong (it is true that both behave identically because RFC5280 is defined to 0), but they do not set the time object to "a valid value to use in an X.509 certificate". Confusingly, ASN1_TIME_adj_internal() actually honours its RFC5280 parameter by behaving the expected way whereas its meaning in ASN1_TIME_set_string_internal() is different. I am unsure if the bug is in my commit above or in our version of ASN1_TIME_set_string_X509() (or both). > > This all works fine, and a certificate is created > > When I check with: > openssl x509 -text -noout -in pi.pem > > everything seems as expected, including the not before/after dates: > > Validity > Not Before: Jan 2 00:00:00 2019 GMT > Not After : Apr 7 15:39:59 2054 GMT > > (yes, it is valid for 35 years - as I said before, if someone breaks into my > house to secretly do things, I have way bigger problems) > > But, if I try to verify this on the openbsd system, I get: > > # openssl verify pi.pem > C = US, ST = Illinois, L = ***, O = ***, OU = ***, CN = *** > error 20 at 0 depth lookup:unable to get local issuer certificate > pi.pem: verification failed: 20 (unable to get local issuer certificate) > --- > > But, if I install this on the raspberry pi, which has a much older version > of openssl on it: > $ openssl version > OpenSSL 1.1.1c 28 May 2019 > > The certificate verifies without an issue: > $ openssl verify pi.pem > pi.pem: OK > > The last time I created a certificate was in January of this year > (1/22/2024). > I am thinking the openbsd system was using Libressl 3.8.2 at that point. > > I created that certificate in the exact same way, backdating the start date: > openssl ca -startdate 2019010200Z -in 54.csr -out 54.pem -config > /etc/ssl/openssl.cnf > > This previously created certificate also has them same backdated and very > long valid period: > > Validity > Not Before: Jan 2 00:00:00 2019 GMT > Not After : Jan 21 23:49:22 2054 GMT > > (Notice the not after date is a little different) > Today, with the new libressl, this certificate verifies OK. > > $ openssl verify 54.pem > 54.pem: OK > > Finally, if I create the new certificate WITHOUT backdating it > e.g.: openssl ca -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf > > The certificate is created and verifies OK. > > So, it seems, there is some sort of issue with backdating the certificate, > but not an issue with the crazy long validity window, that was not present > in January of this year. > > However, as I said, if I don't backdate, then in about a year the ipad will > refuse to connect because of the restrictions apple has imposed, unless I > update the certificate. > > I know this is not "best practice," but it should still work, right? > > Is there something I am missing? > Otherwise, it appears something has changed in Libressl
TLS handshake failure at pkg_update
Hi, I face this issue on my VPS, do you have any idea what going on? vps$ doas pkg_add micro doas (u...@vps.example.com) password: quirks-7.14 signed on 2024-04-07T18:32:17Z https://ftp2.eu.openbsd.org/pub/OpenBSD//7.5/packages/amd64/: TLS handshake failure: handshake failed: error:02FFF00D:system library:func(4095):Permission denied https://ftp2.eu.openbsd.org/pub/OpenBSD//7.5/packages/amd64/: empty Can't find micro vps$ doas pkg_add micro https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages-stable/amd64/: TLS handshake failure: handshake failed: error:02FFF00D:system library:func(4095):Permission denied https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: TLS handshake failure: handshake failed: error:02FFF00D:system library:func(4095):Permission denied https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: empty Can't find micro Regards, --ext
