WireGuard, worked 7.5Release, not working snapshot
Hi all - hope you guys are doing great. I've been struggling to config WireGuard for a while (roadwarrior on my end, VPN service subscription on server side). Mostly due to my own limitations, really. Yesterday I finally managed to make it work, after upgrading to 7.5 RELEASE, through a lot of trial and error. Main reference on the setup was [1] and [2]. Setup that worked: - */etc/resolvd.conf* nameserver 10.2.0.1 # VPN server config */etc/hostname.wg0* wgkey$WG_MY_PRIV_KEY wgpeer $WG_PEER_PUBKEY inet 192.168.1.2/24 wgrtable 1 up !route add -net default 192.168.1.1 */etc/hostname.iwx0* join $MY_WIFI wpakey $MY_WIFI_PWD rdomain 1 up autoconf */etc/pf.conf* set skip on lo block return ext_if = "iwx0" vpn_if = "wg0" pass in on $ext_if from $ext_if:network rtable 1 pass out on $ext_if from self match out on $vpn_if from $ext_if:network to any nat-to $vpn_if pass out on $vpn_if - Then I decided to sysupgrade to SNAPSHOT, which is what I used to do in the past, and the setup stopped working. I tried using tcpdump to understand what is happening, and my guess is that it has to do with DNS, but I couldn't figure out exactly... I'm sure I'm missing a lot of details, if anyone can point me to the right directions (eg, what to check, possible issues) that would be much appreciated. I don't want to use wireguard-tools. If additional info is needed please let me know. Regards, Michel [1] https://dataswamp.org/~solene/2021-10-09-openbsd-wireguard-exit.html [2] https://blog.lambda.cx/posts/openbsd-wireguard-vpn-gateway/
Missing 7.5 link in security.html
Hello, the current release errata link is missing from http://www.openbsd.org/security.html once again. Kind regards, Piotr Durlej
support new
0 C United States P New York T Lansing Z 14882 O Ready-to-Run Software, Inc. I Jeff Moskow A 212 Cedar Cove M open...@rtr.com U http://www.rtr.com/Ready-to-Run_Software/OpenBSD/ B 607-533-8649 X 607-533-UNIX N We have been installing, supporting and managing OpenBSD systems for over 20 years. Deploying them for firewalls, mail servers, DNS servers, monitoring (Nagios w/custom plugins), relay/proxy servers, web servers, bastion hosts, VPN and more.
Re: Creating GLX context fails on ATI Picasso Radeon
Дана 24/04/11 12:45PM, Jose Maldonado написа: > Hi! Are you installed the firmware? Yes, I have (using the fw_update). I also did `pkg_add -Uu` after upgrading to 7.5, for that matter. > doas fw_update -av I get: $ doas fw_update -av fw_update: add none; update none; keep amd,amdgpu,uvideo,vmm $
Re: Restic rest server broken with relayd.
On 2024-04-10, a...@abiscuola.com wrote:
> Is there a way to restore the previous behaviour in relayd(8)
Only by reverting the commit etc.
> or, is there a known workaround for restic, in this case?
That's probably a question for restic really (or possibly the
requirement is coming from a 3rd party REST library).
> I know that relayd(8) is right
It seems a little strict to me.
To my eye, the older version of the HTTP spec requires it ("The
Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or, in
the case of the HEAD method, the size of the entity-body that would have
been sent had the request been a GET").
That's been replaced now but it's still permitted: "The server SHOULD
send the same header fields in response to a HEAD request as it would
have sent if the request had been a GET, except that the payload header
fields (Section 3.3) MAY be omitted."
--
Please keep replies on the mailing list.
Re: No internet connection (firewall block)
On Thu, Apr 11, 2024 at 07:45:18PM +0200, Karel Lucas wrote:
> The typos have been fixed, and PF's ruleset will be put under a magnifying
> glass.
This is a bit of a personal preference, but (assuming you trust any
traffic generated on the firewall itself), I find it helpful to
start the ruleset with a simple:
block log in
pass out
and then do the filtering what comes _in_ (either via $ext_if or
$int_ifs), by adding "pass in ... on ... " rules.
> Op 11-04-2024 om 10:34 schreef Zé Loff:
> > On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote:
> > > Hi all,
> > >
> > > With the new firewall I am setting up I cannot connect to the internet.
> > > That
> > > starts with traceroute, so let's start there. Ping works fine. Below I
> > > have
> > > listed my pf.conf file.
> > >
> > >
> > >
> > > /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
> > >
> > > block in quick on $ext_if from $martians to any
> > > block out quick on $ext_if from any to $martians
> > >
> > > # 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 egress inet proto udp to port 33433:33626 # for IPv4
> > > pass log out on egress 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
> > > pass log out proto tcp to port $tcp_services # establish keep-stat
> > > pass log log proto udp to port $udp_services # Establish keep-state
> > If I read this correctly, you are not allowing any "in" traffic, except
> > for the two "Letting ping through lines", which are just for ICMP, and
> > on the first two rules on the last part ("...$icmp_types" and
> > "...$client_out"). I am assuming "log log" on the last rule is a typo,
> > and it is actually "log out".
>
--
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 06:15:14PM +0200, Otto Moerbeek wrote:
> On Thu, Apr 11, 2024 at 05:29:14PM +0200, Otto Moerbeek wrote:
>
> > On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote:
> >
> > > On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
> > >
> > > > On 4/11/24 16:15, Claudio Jeker wrote:
> > > > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > > > > On 4/11/24 14:12, Nick Holland wrote:
> > > > > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > > > > We have a server with A LOT of files in some directories (an
> > > > > > > > email
> > > > > > > > server in maildir format).
> > > > > > > >
> > > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing
> > > > > > > > through 7.4) it
> > > > > > > > became very very very slow to access these large directories!
> > > > > > > ,,,
> > > > > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > > > > in 7.4 more than the availability of a knob to twist. This was a
> > > > > > > huge hit for some things -- I had one backup job go from a couple
> > > > > > > hours to eight or so hours. However, it turned out that increase
> > > > > > > in time has not inconvenienced me at all, and some random lockups
> > > > > > > related to softdeps have gone away. Overall, win for me (the
> > > > > > > fscks after a lockup took hours, too, not to mention all the time
> > > > > > > and effort spent replacing part after part assuming it was a HW
> > > > > > > issue).
> > > > > > >
> > > > > > > As I understand it...there were known (known unknown?) bugs in the
> > > > > > > softdep code, the code was ugly, and it made it difficult to
> > > > > > > actually improve the code.
> > > > > >
> > > > > > No, we knew that softdeps were being deprecated and we removed from
> > > > > > everywhere some time ago. It must be something else.
> > > > > >
> > > > > > Anyway, it's strange that dirhash parameters has being changed and
> > > > > > removed
> > > > > > without any mention...
> > > > >
> > > > > It was not (this is on -current amd64):
> > > > > vfs.ffs.dirhash_dirsize=2560
> > > > > vfs.ffs.dirhash_maxmem=5242880
> > > > > vfs.ffs.dirhash_mem=4832510
> > > > >
> > > > > Are you sure your kernel and userland are in sync?
> > > >
> > > > Well, I followed the prescribed procedure (I'm using OpenBSD since...
> > > > about
> > > > 20 years).
> > > >
> > > > In EVERY machine upgraded to 7.5 now I have something like this:
> > > >
> > > > Elrond:/home/giannici$ sysctl vfs.ffs
> > > >
> > > >
> > > >
> > > > vfs.ffs.dirhash_maxmem=2560
> > > > vfs.ffs.dirhash_mem=5242880
> > > >
> > > > Elrond:/home/giannici$ uname -a
> > > >
> > > >
> > > >
> > > > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> > > >
> > > >
> > > > So, I'm the only one?
> > > >
> > > > Thanks.
> > > >
> > >
> > > I suspect
> > >
> > > In
> > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45=1.46=h
> > >
> > > The max_softdeps entry in ffs_extern.h should have been replace by a
> > > { 0, 0 }
> > >
> > > instead of being removed.
> > >
> > > -Otto
> > >
> >
> > Yes, that fixes it for me:
> >
> > $ sysctl vfs.ffs
> > vfs.ffs.dirhash_dirsize=2560
> > vfs.ffs.dirhash_maxmem=5242880
> > vfs.ffs.dirhash_mem=767359
> > $
> >
>
> to elaborate a bit: the vfs.ffs.dirhash_maxmem enty was actually
> showing the value of the vfs.ffs.dirhash_dirsize entry. Trying to set the
> vfs.ffs.dirhash_maxmem entry would result into setting the
> vfs.ffs.dirhash_dirsize entry, which effectively disables dirhash if
> yon set it to a high value.
>
> It remains a mystery why Claudio is seeing the correct values... you'd
> almost think he uses an old sysctl binary, or his tree is out of sync
> somehow.
>
My bad I ran the command on a system that was still running 7.4 without
realizing that.
--
:wq Claudio
Re: No internet connection (firewall block)
PF's ruleset will be put under a magnifying glass.
Op 11-04-2024 om 11:09 schreef Peter N. M. Hansteen:
On Thu, Apr 11, 2024 at 09:34:15AM +0100, Zé Loff wrote:
pass log out on egress inet proto udp to port 33433:33626 # for IPv4
pass log out on egress 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
pass log out proto tcp to port $tcp_services # establish keep-stat
pass log log proto udp to port $udp_services # Establish keep-state
If I read this correctly, you are not allowing any "in" traffic, except
for the two "Letting ping through lines", which are just for ICMP, and
on the first two rules on the last part ("...$icmp_types" and
"...$client_out"). I am assuming "log log" on the last rule is a typo,
and it is actually "log out".
Those are as far as I can tell correct observations. There appears to be
no rule allowing traffic other than the selected icmp types to pass from
anywhere but the local host.
Re: No internet connection (firewall block)
The typos have been fixed, and PF's ruleset will be put under a
magnifying glass.
Op 11-04-2024 om 10:34 schreef Zé Loff:
On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote:
Hi all,
With the new firewall I am setting up I cannot connect to the internet. That
starts with traceroute, so let's start there. Ping works fine. Below I have
listed my pf.conf file.
/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
block in quick on $ext_if from $martians to any
block out quick on $ext_if from any to $martians
# 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 egress inet proto udp to port 33433:33626 # for IPv4
pass log out on egress 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
pass log out proto tcp to port $tcp_services # establish keep-stat
pass log log proto udp to port $udp_services # Establish keep-state
If I read this correctly, you are not allowing any "in" traffic, except
for the two "Letting ping through lines", which are just for ICMP, and
on the first two rules on the last part ("...$icmp_types" and
"...$client_out"). I am assuming "log log" on the last rule is a typo,
and it is actually "log out".
Re: No internet connection (firewall block)
I do get the following error message: sysctl: toplevel name net/inet6 in net/inet6.ip6.forwarding is invalid Op 11-04-2024 om 09:49 schreef Peter N. M. Hansteen: On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote: With the new firewall I am setting up I cannot connect to the internet. That starts with traceroute, so let's start there. Ping works fine. Below I have listed my pf.conf file. This sounds like you have a link to somewhere, at least. The first question would be, when you say "I cannot connect to the internet", where is this in relation to the host with the ruleset you quote? Start with the basics - is the gateway set up to forward packets? The output of $ sysctl net.inet | grep forward will reveal the truth there. And looking at the quoted ruleset, I find it rather unlikely that it will actually load -- you will get a "macro 'martians' not defined" and "unknown port nportntp" and likely a few "syntax error" messages as well. I would advise to take a few steps back, start from the basics and add only the things you know you need.
Re: No internet connection (firewall block)
Output van 'sysctl net.inet | grep forward': net.inet.ip.forwarding=1 net.inet.ip.mforwarding=0 This may sound strange, but I don't get an error message when booting. I did have that problem because the word 'log' appeared in some lines, but that has already been resolved. I'm going to apply a "step by step" approach to the rules in pf.conf. Op 11-04-2024 om 09:49 schreef Peter N. M. Hansteen: On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote: With the new firewall I am setting up I cannot connect to the internet. That starts with traceroute, so let's start there. Ping works fine. Below I have listed my pf.conf file. This sounds like you have a link to somewhere, at least. The first question would be, when you say "I cannot connect to the internet", where is this in relation to the host with the ruleset you quote? Start with the basics - is the gateway set up to forward packets? The output of $ sysctl net.inet | grep forward will reveal the truth there. And looking at the quoted ruleset, I find it rather unlikely that it will actually load -- you will get a "macro 'martians' not defined" and "unknown port nportntp" and likely a few "syntax error" messages as well. I would advise to take a few steps back, start from the basics and add only the things you know you need.
Re: Creating GLX context fails on ATI Picasso Radeon
El Thu, 11 Apr 2024 11:36:54 +0200 Страхиња Радић escribió: > Hi, I noticed that running glxinfo on OpenBSD-release 7.5 amd64 gives > an error: > > $ glxinfo > X Error of failed request: BadValue (integer parameter out > of range for operation) > Major opcode of failed request: 152 (GLX) > Minor opcode of failed request: 24 (X_GLXCreateNewContext) > Value in failed request: 0x0 > Serial number of failed request: 25 > Current serial number in output stream: 26 > name of display: :0 > > I am getting a similar error with some programs using GLX, for > example: glxgears: > > $ glxgears > Error: glXCreateContext failed > > and Lagrange[1] Gemini client: > > $ lagrange > Lagrange: A Beautiful Gemini Client > X Error of failed request: BadValue (integer parameter out > of range for operation) > Major opcode of failed request: 152 (GLX) > Minor opcode of failed request: 3 (X_GLXCreateContext) > Value in failed request: 0x0 > Serial number of failed request: 100 > Current serial number in output stream: 101 > > I'd appreciate some help in diagnosing and solving this problem. This > is the output of various diagnostic programs: > > --- > $ doas inxi -G > Graphics: > Device-1: ATI Picasso driver: amdgpu > Device-2: Sonix Integrated Camera driver: uvideo type: USB > Display: server: X.org v: 1.21.1.11 driver: X: loaded: amdgpu > unloaded: modesetting dri: radeonsi gpu: amdgpu > API: OpenGL Message: GL data unavailable for root. > > $ usbdevs -v > Controller /dev/usb0: > addr 01: 1022: AMD, xHCI root hub > super speed, self powered, config 1, rev 1.00 > driver: uhub0 > addr 02: 2357:010c Realtek, 802.11n NIC > high speed, power 500 mA, config 1, rev 0.00, iSerial > 00E04C0001 driver: urtwn0 > addr 03: 0458:0186 SiGmaMicro, USB Optical Mouse > low speed, power 100 mA, config 1, rev 1.10 > driver: uhidev0 > addr 04: 174f:1176 Sonix Technology Co., Ltd., Integrated Camera > high speed, power 500 mA, config 1, rev 0.28 > driver: uvideo0 > addr 05: 0cf3:e300 Atheros Communications, product 0xe300 > full speed, self powered, config 1, rev 0.01 > driver: ugen0 > > $ doas pcidump > Domain /dev/pci0: > 0:0:0: AMD 17h/1xh Root Complex > 0:0:2: AMD 17h/1xh IOMMU > 0:1:0: AMD 17h PCIE > 0:1:1: AMD 17h/1xh PCIE > 0:1:2: AMD 17h/1xh PCIE > 0:8:0: AMD 17h PCIE > 0:8:1: AMD 17h/1xh PCIE > 0:20:0: AMD FCH SMBus > 0:20:3: AMD FCH LPC > 0:24:0: AMD 17h/1xh Data Fabric > 0:24:1: AMD 17h/1xh Data Fabric > 0:24:2: AMD 17h/1xh Data Fabric > 0:24:3: AMD 17h/1xh Data Fabric > 0:24:4: AMD 17h/1xh Data Fabric > 0:24:5: AMD 17h/1xh Data Fabric > 0:24:6: AMD 17h/1xh Data Fabric > 0:24:7: AMD 17h/1xh Data Fabric > 1:0:0: SK hynix unknown > 2:0:0: Atheros QCA6174 > 3:0:0: ATI Picasso > 3:0:1: ATI Radeon Vega HD Audio > 3:0:2: AMD 17h/1xh Crypto > 3:0:3: AMD unknown > 3:0:5: AMD 17h/1xh I2S Audio > 3:0:6: AMD 17h/1xh HD Audio > > $ dmesg > OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 6277246976 (5986MB) > avail mem = 6065999872 (5784MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xba687000 (50 entries) > bios0: vendor LENOVO version "E8CN34WW" date 04/28/2022 > bios0: LENOVO 82C7 > efi0 at bios0: UEFI 2.7 > efi0: Phoenix Technologies Ltd. rev 0x12345678 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT POAT BATB HPET APIC MCFG VFCT IVRS SSDT > CRAT CDIT SSDT TPM2 FPDT SSDT SSDT SSDT BGRT UEFI SSDT > acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) > GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) GP18(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 3 3250U with Radeon Graphics, 2600.00 MHz, 17-18-01, > patch 08108109 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 64KB 64b/line 4-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, > core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 > fixed ranges cpu0: apic clock running at 25MHz > cpu0: mwait
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 05:29:14PM +0200, Otto Moerbeek wrote:
> On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote:
>
> > On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
> >
> > > On 4/11/24 16:15, Claudio Jeker wrote:
> > > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > > > On 4/11/24 14:12, Nick Holland wrote:
> > > > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > > > We have a server with A LOT of files in some directories (an email
> > > > > > > server in maildir format).
> > > > > > >
> > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through
> > > > > > > 7.4) it
> > > > > > > became very very very slow to access these large directories!
> > > > > > ,,,
> > > > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > > > in 7.4 more than the availability of a knob to twist. This was a
> > > > > > huge hit for some things -- I had one backup job go from a couple
> > > > > > hours to eight or so hours. However, it turned out that increase
> > > > > > in time has not inconvenienced me at all, and some random lockups
> > > > > > related to softdeps have gone away. Overall, win for me (the
> > > > > > fscks after a lockup took hours, too, not to mention all the time
> > > > > > and effort spent replacing part after part assuming it was a HW
> > > > > > issue).
> > > > > >
> > > > > > As I understand it...there were known (known unknown?) bugs in the
> > > > > > softdep code, the code was ugly, and it made it difficult to
> > > > > > actually improve the code.
> > > > >
> > > > > No, we knew that softdeps were being deprecated and we removed from
> > > > > everywhere some time ago. It must be something else.
> > > > >
> > > > > Anyway, it's strange that dirhash parameters has being changed and
> > > > > removed
> > > > > without any mention...
> > > >
> > > > It was not (this is on -current amd64):
> > > > vfs.ffs.dirhash_dirsize=2560
> > > > vfs.ffs.dirhash_maxmem=5242880
> > > > vfs.ffs.dirhash_mem=4832510
> > > >
> > > > Are you sure your kernel and userland are in sync?
> > >
> > > Well, I followed the prescribed procedure (I'm using OpenBSD since...
> > > about
> > > 20 years).
> > >
> > > In EVERY machine upgraded to 7.5 now I have something like this:
> > >
> > > Elrond:/home/giannici$ sysctl vfs.ffs
> > >
> > >
> > >
> > > vfs.ffs.dirhash_maxmem=2560
> > > vfs.ffs.dirhash_mem=5242880
> > >
> > > Elrond:/home/giannici$ uname -a
> > >
> > >
> > >
> > > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> > >
> > >
> > > So, I'm the only one?
> > >
> > > Thanks.
> > >
> >
> > I suspect
> >
> > In
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45=1.46=h
> >
> > The max_softdeps entry in ffs_extern.h should have been replace by a
> > { 0, 0 }
> >
> > instead of being removed.
> >
> > -Otto
> >
>
> Yes, that fixes it for me:
>
> $ sysctl vfs.ffs
> vfs.ffs.dirhash_dirsize=2560
> vfs.ffs.dirhash_maxmem=5242880
> vfs.ffs.dirhash_mem=767359
> $
>
to elaborate a bit: the vfs.ffs.dirhash_maxmem enty was actually
showing the value of the vfs.ffs.dirhash_dirsize entry. Trying to set the
vfs.ffs.dirhash_maxmem entry would result into setting the
vfs.ffs.dirhash_dirsize entry, which effectively disables dirhash if
yon set it to a high value.
It remains a mystery why Claudio is seeing the correct values... you'd
almost think he uses an old sysctl binary, or his tree is out of sync
somehow.
-Otto
Re: IPv6 with umb(4)
. On 11/04/2024 16:43, Julian Huhn wrote: Moin! On Thu, Apr 11, 2024 at 04:01:49PM +0400, Willy Manga wrote: On 10/04/2024 18:24, Julian Huhn wrote: x270$ ifconfig umb0 umb0: flags=8851 mtu 1500 index 5 priority 6 llprio 3 roaming enabled registration home network state up cell-class LTE rssi -89dBm speed 47.7Mbps up 286Mbps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id device EM7455 IMEI firmware SWI9X30C_02.24.03.00 phone# +49xxx APN internet provider Telekom.de provider-id 26201 dns 10.74.210.210 10.74.210.211 groups: egress status: active inet 10.72.239.216 --> 10.72.239.217 netmask 0xfff0 I don't see a link-local address (fe80::/10). Can you confirm that after you enabled IPv6 as per your second email that you can see one? The link-local address shows as soon as I enter # ifconfig umb0 inet6 eui64 Great because you will (always) need a link-local before you get any other type of IPv6 address. After successfull authentication, I also get my global IPv6 address. Good news. Can you check if your network support other mechanisms than eui64: temporary , soii ? 'ifconfig umb0 inet6 temporary' or 'ifconfig umb0 inet6 soii' Don't know if you can combine these options though.. -- Willy Manga
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 05:20:24PM +0200, Otto Moerbeek wrote:
> On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
>
> > On 4/11/24 16:15, Claudio Jeker wrote:
> > > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > > On 4/11/24 14:12, Nick Holland wrote:
> > > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > > We have a server with A LOT of files in some directories (an email
> > > > > > server in maildir format).
> > > > > >
> > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through
> > > > > > 7.4) it
> > > > > > became very very very slow to access these large directories!
> > > > > ,,,
> > > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > > in 7.4 more than the availability of a knob to twist. This was a
> > > > > huge hit for some things -- I had one backup job go from a couple
> > > > > hours to eight or so hours. However, it turned out that increase
> > > > > in time has not inconvenienced me at all, and some random lockups
> > > > > related to softdeps have gone away. Overall, win for me (the
> > > > > fscks after a lockup took hours, too, not to mention all the time
> > > > > and effort spent replacing part after part assuming it was a HW
> > > > > issue).
> > > > >
> > > > > As I understand it...there were known (known unknown?) bugs in the
> > > > > softdep code, the code was ugly, and it made it difficult to
> > > > > actually improve the code.
> > > >
> > > > No, we knew that softdeps were being deprecated and we removed from
> > > > everywhere some time ago. It must be something else.
> > > >
> > > > Anyway, it's strange that dirhash parameters has being changed and
> > > > removed
> > > > without any mention...
> > >
> > > It was not (this is on -current amd64):
> > > vfs.ffs.dirhash_dirsize=2560
> > > vfs.ffs.dirhash_maxmem=5242880
> > > vfs.ffs.dirhash_mem=4832510
> > >
> > > Are you sure your kernel and userland are in sync?
> >
> > Well, I followed the prescribed procedure (I'm using OpenBSD since... about
> > 20 years).
> >
> > In EVERY machine upgraded to 7.5 now I have something like this:
> >
> > Elrond:/home/giannici$ sysctl vfs.ffs
> >
> >
> >
> > vfs.ffs.dirhash_maxmem=2560
> > vfs.ffs.dirhash_mem=5242880
> >
> > Elrond:/home/giannici$ uname -a
> >
> >
> >
> > OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
> >
> >
> > So, I'm the only one?
> >
> > Thanks.
> >
>
> I suspect
>
> In
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45=1.46=h
>
> The max_softdeps entry in ffs_extern.h should have been replace by a
> { 0, 0 }
>
> instead of being removed.
>
> -Otto
>
Yes, that fixes it for me:
$ sysctl vfs.ffs
vfs.ffs.dirhash_dirsize=2560
vfs.ffs.dirhash_maxmem=5242880
vfs.ffs.dirhash_mem=767359
$
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 05:08:01PM +0200, Federico Giannici wrote:
> On 4/11/24 16:15, Claudio Jeker wrote:
> > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote:
> > > On 4/11/24 14:12, Nick Holland wrote:
> > > > On 4/11/24 05:47, Federico Giannici wrote:
> > > > > We have a server with A LOT of files in some directories (an email
> > > > > server in maildir format).
> > > > >
> > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4)
> > > > > it
> > > > > became very very very slow to access these large directories!
> > > > ,,,
> > > > You may be being bitten by the removal of softdeps (soft updates)
> > > > in 7.4 more than the availability of a knob to twist. This was a
> > > > huge hit for some things -- I had one backup job go from a couple
> > > > hours to eight or so hours. However, it turned out that increase
> > > > in time has not inconvenienced me at all, and some random lockups
> > > > related to softdeps have gone away. Overall, win for me (the
> > > > fscks after a lockup took hours, too, not to mention all the time
> > > > and effort spent replacing part after part assuming it was a HW
> > > > issue).
> > > >
> > > > As I understand it...there were known (known unknown?) bugs in the
> > > > softdep code, the code was ugly, and it made it difficult to
> > > > actually improve the code.
> > >
> > > No, we knew that softdeps were being deprecated and we removed from
> > > everywhere some time ago. It must be something else.
> > >
> > > Anyway, it's strange that dirhash parameters has being changed and removed
> > > without any mention...
> >
> > It was not (this is on -current amd64):
> > vfs.ffs.dirhash_dirsize=2560
> > vfs.ffs.dirhash_maxmem=5242880
> > vfs.ffs.dirhash_mem=4832510
> >
> > Are you sure your kernel and userland are in sync?
>
> Well, I followed the prescribed procedure (I'm using OpenBSD since... about
> 20 years).
>
> In EVERY machine upgraded to 7.5 now I have something like this:
>
> Elrond:/home/giannici$ sysctl vfs.ffs
>
>
>
> vfs.ffs.dirhash_maxmem=2560
> vfs.ffs.dirhash_mem=5242880
>
> Elrond:/home/giannici$ uname -a
>
>
>
> OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64
>
>
> So, I'm the only one?
>
> Thanks.
>
I suspect
In
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ffs/ffs_exatern.h.diff?r1=1.45=1.46=h
The max_softdeps entry in ffs_extern.h should have been replace by a
{ 0, 0 }
instead of being removed.
-Otto
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On 4/11/24 16:15, Claudio Jeker wrote: On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote: On 4/11/24 14:12, Nick Holland wrote: On 4/11/24 05:47, Federico Giannici wrote: We have a server with A LOT of files in some directories (an email server in maildir format). Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it became very very very slow to access these large directories! ,,, You may be being bitten by the removal of softdeps (soft updates) in 7.4 more than the availability of a knob to twist. This was a huge hit for some things -- I had one backup job go from a couple hours to eight or so hours. However, it turned out that increase in time has not inconvenienced me at all, and some random lockups related to softdeps have gone away. Overall, win for me (the fscks after a lockup took hours, too, not to mention all the time and effort spent replacing part after part assuming it was a HW issue). As I understand it...there were known (known unknown?) bugs in the softdep code, the code was ugly, and it made it difficult to actually improve the code. No, we knew that softdeps were being deprecated and we removed from everywhere some time ago. It must be something else. Anyway, it's strange that dirhash parameters has being changed and removed without any mention... It was not (this is on -current amd64): vfs.ffs.dirhash_dirsize=2560 vfs.ffs.dirhash_maxmem=5242880 vfs.ffs.dirhash_mem=4832510 Are you sure your kernel and userland are in sync? Well, I followed the prescribed procedure (I'm using OpenBSD since... about 20 years). In EVERY machine upgraded to 7.5 now I have something like this: Elrond:/home/giannici$ sysctl vfs.ffs vfs.ffs.dirhash_maxmem=2560 vfs.ffs.dirhash_mem=5242880 Elrond:/home/giannici$ uname -a OpenBSD Elrond.neomedia.it 7.5 GENERIC.MP#82 amd64 So, I'm the only one? Thanks.
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 04:15:19PM +0200, Claudio Jeker wrote: > On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote: > > On 4/11/24 14:12, Nick Holland wrote: > > > On 4/11/24 05:47, Federico Giannici wrote: > > > > We have a server with A LOT of files in some directories (an email > > > > server in maildir format). > > > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it > > > > became very very very slow to access these large directories! > > > ,,, > > > You may be being bitten by the removal of softdeps (soft updates) > > > in 7.4 more than the availability of a knob to twist. This was a > > > huge hit for some things -- I had one backup job go from a couple > > > hours to eight or so hours. However, it turned out that increase > > > in time has not inconvenienced me at all, and some random lockups > > > related to softdeps have gone away. Overall, win for me (the > > > fscks after a lockup took hours, too, not to mention all the time > > > and effort spent replacing part after part assuming it was a HW > > > issue). > > > > > > As I understand it...there were known (known unknown?) bugs in the > > > softdep code, the code was ugly, and it made it difficult to > > > actually improve the code. > > > > No, we knew that softdeps were being deprecated and we removed from > > everywhere some time ago. It must be something else. > > > > Anyway, it's strange that dirhash parameters has being changed and removed > > without any mention... > > It was not (this is on -current amd64): > vfs.ffs.dirhash_dirsize=2560 > vfs.ffs.dirhash_maxmem=5242880 > vfs.ffs.dirhash_mem=4832510 > > Are you sure your kernel and userland are in sync? > -- > :wq Claudio > Strange, on a very recent snap: $ sysctl | grep ffs.d vfs.ffs.dirhash_maxmem=2560 vfs.ffs.dirhash_mem=5242880 $ -Otto
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On Thu, Apr 11, 2024 at 03:36:29PM +0200, Federico Giannici wrote: > On 4/11/24 14:12, Nick Holland wrote: > > On 4/11/24 05:47, Federico Giannici wrote: > > > We have a server with A LOT of files in some directories (an email > > > server in maildir format). > > > > > > Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it > > > became very very very slow to access these large directories! > > ,,, > > You may be being bitten by the removal of softdeps (soft updates) > > in 7.4 more than the availability of a knob to twist. This was a > > huge hit for some things -- I had one backup job go from a couple > > hours to eight or so hours. However, it turned out that increase > > in time has not inconvenienced me at all, and some random lockups > > related to softdeps have gone away. Overall, win for me (the > > fscks after a lockup took hours, too, not to mention all the time > > and effort spent replacing part after part assuming it was a HW > > issue). > > > > As I understand it...there were known (known unknown?) bugs in the > > softdep code, the code was ugly, and it made it difficult to > > actually improve the code. > > No, we knew that softdeps were being deprecated and we removed from > everywhere some time ago. It must be something else. > > Anyway, it's strange that dirhash parameters has being changed and removed > without any mention... It was not (this is on -current amd64): vfs.ffs.dirhash_dirsize=2560 vfs.ffs.dirhash_maxmem=5242880 vfs.ffs.dirhash_mem=4832510 Are you sure your kernel and userland are in sync? -- :wq Claudio
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On 4/11/24 14:12, Nick Holland wrote: On 4/11/24 05:47, Federico Giannici wrote: We have a server with A LOT of files in some directories (an email server in maildir format). Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it became very very very slow to access these large directories! ,,, You may be being bitten by the removal of softdeps (soft updates) in 7.4 more than the availability of a knob to twist. This was a huge hit for some things -- I had one backup job go from a couple hours to eight or so hours. However, it turned out that increase in time has not inconvenienced me at all, and some random lockups related to softdeps have gone away. Overall, win for me (the fscks after a lockup took hours, too, not to mention all the time and effort spent replacing part after part assuming it was a HW issue). As I understand it...there were known (known unknown?) bugs in the softdep code, the code was ugly, and it made it difficult to actually improve the code. No, we knew that softdeps were being deprecated and we removed from everywhere some time ago. It must be something else. Anyway, it's strange that dirhash parameters has being changed and removed without any mention...
SHA256 of 7.5 has .img and iso files twice
Hello, The SHA256 file of version 7.5 has .img and .iso files listed twice in the arm64 and amd64 directories and potentially other directories too. Best, Zapper
Re: IPv6 with umb(4)
Hi, On 10/04/2024 18:24, Julian Huhn wrote: Moin! [...] x270$ ifconfig umb0 umb0: flags=8851 mtu 1500 index 5 priority 6 llprio 3 roaming enabled registration home network state up cell-class LTE rssi -89dBm speed 47.7Mbps up 286Mbps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id device EM7455 IMEI firmware SWI9X30C_02.24.03.00 phone# +49xxx APN internet provider Telekom.de provider-id 26201 dns 10.74.210.210 10.74.210.211 groups: egress status: active inet 10.72.239.216 --> 10.72.239.217 netmask 0xfff0 I don't see a link-local address (fe80::/10). Can you confirm that after you enabled IPv6 as per your second email that you can see one? -- Willy Manga
Re: IPv6 with umb(4)
Moin! On Thu, Apr 11, 2024 at 04:01:49PM +0400, Willy Manga wrote: On 10/04/2024 18:24, Julian Huhn wrote: x270$ ifconfig umb0 umb0: flags=8851 mtu 1500 index 5 priority 6 llprio 3 roaming enabled registration home network state up cell-class LTE rssi -89dBm speed 47.7Mbps up 286Mbps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id device EM7455 IMEI firmware SWI9X30C_02.24.03.00 phone# +49xxx APN internet provider Telekom.de provider-id 26201 dns 10.74.210.210 10.74.210.211 groups: egress status: active inet 10.72.239.216 --> 10.72.239.217 netmask 0xfff0 I don't see a link-local address (fe80::/10). Can you confirm that after you enabled IPv6 as per your second email that you can see one? The link-local address shows as soon as I enter # ifconfig umb0 inet6 eui64 After successfull authentication, I also get my global IPv6 address. Or as shown in /etc/hostname.umb0, then everything just works automatically. --Huhn umb0: flags=8851 mtu 1500 index 5 priority 6 llprio 3 roaming enabled registration home network state up cell-class LTE rssi -91dBm speed 47.7Mbps up 286Mbps down SIM initialized PIN valid (3 attempts left) subscriber-id ICC-id device EM7455 IMEI firmware SWI9X30C_02.24.03.00 phone# +49 APN internet provider Telekom.de provider-id 26201 dns 10.74.210.210 10.74.210.211 2a01:598:7ff:0:10:74:210:210 2a01:598:7ff:0:10:74:210:211 groups: egress status: active inet6 fe80::e670:xxx%umb0 --> prefixlen 64 scopeid 0x5 inet 10.107.183.79 --> 10.107.183.80 netmask 0xffe0 inet6 2a01:599:642:xxx --> 2a01:599:642:xxx prefixlen 128
Re: Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
On 4/11/24 05:47, Federico Giannici wrote: We have a server with A LOT of files in some directories (an email server in maildir format). Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it became very very very slow to access these large directories! ,,, You may be being bitten by the removal of softdeps (soft updates) in 7.4 more than the availability of a knob to twist. This was a huge hit for some things -- I had one backup job go from a couple hours to eight or so hours. However, it turned out that increase in time has not inconvenienced me at all, and some random lockups related to softdeps have gone away. Overall, win for me (the fscks after a lockup took hours, too, not to mention all the time and effort spent replacing part after part assuming it was a HW issue). As I understand it...there were known (known unknown?) bugs in the softdep code, the code was ugly, and it made it difficult to actually improve the code. Nick.
Upgraded to 7.5: vfs.ffs.dirhash_dirsize no longer exists and large directory ere veeery slow
We have a server with A LOT of files in some directories (an email server in maildir format). Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) it became very very very slow to access these large directories! Up to 7.3 we used the following sysctl settings and everything was ok: vfs.ffs.dirhash_maxmem=1 vfs.ffs.dirhash_dirsize=1024 But now, with 7.5, vfs.ffs.dirhash_dirsize no longer exists! Only vfs.ffs.dirhash_maxmem and vfs.ffs.dirhash_mem exist, but it's not clear how we can use them. For example, according to "man 2 sysctl" vfs.ffs.dirhash_mem is NOT Changeable, but we were able to change it! But it is not clear what it is for... Anyway, the question is: under OpenBSD 7.5, how can we improve the access to directories with A LOT of files (normal FFF2 filesystem)? We already increased the usage of cache memory with "kern.bufcachepercent=80", but it's not enough. Thanks.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Thu, Apr 11, 2024 at 10:10:20AM +0200, Eivind Eide wrote: It is possible that I have missed important context here, but with a bare environment with only essentials like $HOME defined and no ~/.terminfo directory (as opposed to an empty one), do the odd messages still appear? After rm -rf ~/.terminfo/ the message is gone (regardless of environmental variables). FWIW I'm getting a lot more of the same messages without ~/.terminfo than with. I'm using kitty (the terminal) to log into openbsd using ssh, and I've been distributing ~/.terminfo/x/xterm-kitty (and using TERM=xterm-kitty). Starting with 7.5 I was suddenly seeing weird characters appear when using tmux (where TERM=tmux-256color) on openbsd. Copying /usr/share/terminfo/t/tmux-256color to ~/.terminfo/t/tmux-256color seemed to solved this. With this setup I've been seeing maybe 2x 'sh: vfprintf %s NULL in "%.*s"' in /var/log/messages a day. Removing ~/.terminfo entirely (and installing kitty so I have a working terminfo) immediately started throwing *a lot* more of those lines into /var/log/messages, with a lot of other prefixes. The messages stop again if I copy back ~/.terminfo/x/xterm-kitty (and t/tmux-256color when using tmux), though I'll probably still get the occasional one, as before. -- Dennis Eriksen
Creating GLX context fails on ATI Picasso Radeon
Hi, I noticed that running glxinfo on OpenBSD-release 7.5 amd64 gives an error: $ glxinfo X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 152 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 25 Current serial number in output stream: 26 name of display: :0 I am getting a similar error with some programs using GLX, for example: glxgears: $ glxgears Error: glXCreateContext failed and Lagrange[1] Gemini client: $ lagrange Lagrange: A Beautiful Gemini Client X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 152 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 100 Current serial number in output stream: 101 I'd appreciate some help in diagnosing and solving this problem. This is the output of various diagnostic programs: --- $ doas inxi -G Graphics: Device-1: ATI Picasso driver: amdgpu Device-2: Sonix Integrated Camera driver: uvideo type: USB Display: server: X.org v: 1.21.1.11 driver: X: loaded: amdgpu unloaded: modesetting dri: radeonsi gpu: amdgpu API: OpenGL Message: GL data unavailable for root. $ usbdevs -v Controller /dev/usb0: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 2357:010c Realtek, 802.11n NIC high speed, power 500 mA, config 1, rev 0.00, iSerial 00E04C0001 driver: urtwn0 addr 03: 0458:0186 SiGmaMicro, USB Optical Mouse low speed, power 100 mA, config 1, rev 1.10 driver: uhidev0 addr 04: 174f:1176 Sonix Technology Co., Ltd., Integrated Camera high speed, power 500 mA, config 1, rev 0.28 driver: uvideo0 addr 05: 0cf3:e300 Atheros Communications, product 0xe300 full speed, self powered, config 1, rev 0.01 driver: ugen0 $ doas pcidump Domain /dev/pci0: 0:0:0: AMD 17h/1xh Root Complex 0:0:2: AMD 17h/1xh IOMMU 0:1:0: AMD 17h PCIE 0:1:1: AMD 17h/1xh PCIE 0:1:2: AMD 17h/1xh PCIE 0:8:0: AMD 17h PCIE 0:8:1: AMD 17h/1xh PCIE 0:20:0: AMD FCH SMBus 0:20:3: AMD FCH LPC 0:24:0: AMD 17h/1xh Data Fabric 0:24:1: AMD 17h/1xh Data Fabric 0:24:2: AMD 17h/1xh Data Fabric 0:24:3: AMD 17h/1xh Data Fabric 0:24:4: AMD 17h/1xh Data Fabric 0:24:5: AMD 17h/1xh Data Fabric 0:24:6: AMD 17h/1xh Data Fabric 0:24:7: AMD 17h/1xh Data Fabric 1:0:0: SK hynix unknown 2:0:0: Atheros QCA6174 3:0:0: ATI Picasso 3:0:1: ATI Radeon Vega HD Audio 3:0:2: AMD 17h/1xh Crypto 3:0:3: AMD unknown 3:0:5: AMD 17h/1xh I2S Audio 3:0:6: AMD 17h/1xh HD Audio $ dmesg OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6277246976 (5986MB) avail mem = 6065999872 (5784MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xba687000 (50 entries) bios0: vendor LENOVO version "E8CN34WW" date 04/28/2022 bios0: LENOVO 82C7 efi0 at bios0: UEFI 2.7 efi0: Phoenix Technologies Ltd. rev 0x12345678 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT POAT BATB HPET APIC MCFG VFCT IVRS SSDT CRAT CDIT SSDT TPM2 FPDT SSDT SSDT SSDT BGRT UEFI SSDT acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) GP18(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 3 3250U with Radeon Graphics, 2600.00 MHz, 17-18-01, patch 08108109 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 64KB 64b/line 4-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 3 3250U with Radeon Graphics, 2600.00 MHz, 17-18-01, patch 08108109 cpu1:
Re: IPv6 with umb(4)
Moin! On Wed, Apr 10, 2024 at 04:24:48PM +0200, Julian Huhn wrote: I tried unsuccessfully to obtain an IPv6 address with an umb(4) interface. As umb(4) supports IPv6 since 6.7, I seem to be doing something wrong. Can anyone give me a hint what I need to do? After some further investigation I found a commit for sys/dev/usb/if_umb.c from 2020 which says IPv6 is no longer on by default. It must be enabled with "inet6 eui64". This piece was missing for me. Should this be mentioned in the manpage or in the FAQ? For the sake of completeness my new umb0 config is attached. --Huhn x270$ cat /etc/hostname.umb0 inet6 eui64 apn internet pin roaming up
Re: No internet connection (firewall block)
On Thu, Apr 11, 2024 at 09:34:15AM +0100, Zé Loff wrote:
> > pass log out on egress inet proto udp to port 33433:33626 # for IPv4
> > pass log out on egress 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
> > pass log out proto tcp to port $tcp_services # establish keep-stat
> > pass log log proto udp to port $udp_services # Establish keep-state
>
> If I read this correctly, you are not allowing any "in" traffic, except
> for the two "Letting ping through lines", which are just for ICMP, and
> on the first two rules on the last part ("...$icmp_types" and
> "...$client_out"). I am assuming "log log" on the last rule is a typo,
> and it is actually "log out".
Those are as far as I can tell correct observations. There appears to be
no rule allowing traffic other than the selected icmp types to pass from
anywhere but the local host.
--
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.
Re: No internet connection (firewall block)
On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote:
> Hi all,
>
> With the new firewall I am setting up I cannot connect to the internet. That
> starts with traceroute, so let's start there. Ping works fine. Below I have
> listed my pf.conf file.
>
>
>
> /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
>
> block in quick on $ext_if from $martians to any
> block out quick on $ext_if from any to $martians
>
> # 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 egress inet proto udp to port 33433:33626 # for IPv4
> pass log out on egress 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
> pass log out proto tcp to port $tcp_services # establish keep-stat
> pass log log proto udp to port $udp_services # Establish keep-state
If I read this correctly, you are not allowing any "in" traffic, except
for the two "Letting ping through lines", which are just for ICMP, and
on the first two rules on the last part ("...$icmp_types" and
"...$client_out"). I am assuming "log log" on the last rule is a typo,
and it is actually "log out".
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> It is possible that I have missed important context here, but with a > bare environment with only essentials like $HOME defined and no > ~/.terminfo directory (as opposed to an empty one), do the odd messages > still appear? After rm -rf ~/.terminfo/ the message is gone (regardless of environmental variables). -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Thu, Apr 11, 2024 at 09:41:47AM +0200, Eivind Eide wrote: > > HOME="/home/eivind" > > That's the environmental variable that triggers the message if an > empty ~/.terminfo/ directory is present in my home. It is possible that I have missed important context here, but with a bare environment with only essentials like $HOME defined and no ~/.terminfo directory (as opposed to an empty one), do the odd messages still appear? -- 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.
Re: No internet connection (firewall block)
On Wed, Apr 10, 2024 at 11:53:47PM +0200, Karel Lucas wrote: > > With the new firewall I am setting up I cannot connect to the internet. That > starts with traceroute, so let's start there. Ping works fine. Below I have > listed my pf.conf file. This sounds like you have a link to somewhere, at least. The first question would be, when you say "I cannot connect to the internet", where is this in relation to the host with the ruleset you quote? Start with the basics - is the gateway set up to forward packets? The output of $ sysctl net.inet | grep forward will reveal the truth there. And looking at the quoted ruleset, I find it rather unlikely that it will actually load -- you will get a "macro 'martians' not defined" and "unknown port nportntp" and likely a few "syntax error" messages as well. I would advise to take a few steps back, start from the basics and add only the things you know you need. -- 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.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> UPDATE: If the ~/.terminfo/ directory EXIST in users home but the > termcap file is missing, the behaviour returns. > It's to late now, but I will do the tests and report back tomorrow. And... The winner is: HOME="/home/eivind" That's the environmental variable that triggers the message if an empty ~/.terminfo/ directory is present in my home. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
