Re: Openbsd 6.9 Default gateway

[Irshad Sulaiman]

Thank you for the reply 


I could do by 
Delete and adding route with route command manually 
But is there any better way to do this 





> On 08-May-2021, at 2:28 AM,   wrote:
> 
>> How to set hostname.iwn0 as default gateway
> 
> Probably there is a better solution. Maybe someone with more
> knowledge of netstart can help. I'd try my luck with pf and create
> a natting rule to check for traffic leaving em0 that's not - for
> example - 192.168.1.0/24:
> 
> pass out on em0 from $int_net to ! $int_net received-on em0 nat-to iwn0
> 
> Didn't have the time to check this rule though.

Re: Openbsd 6.9 Default gateway

[liqor]

> How to set hostname.iwn0 as default gateway

Probably there is a better solution. Maybe someone with more
knowledge of netstart can help. I'd try my luck with pf and create
a natting rule to check for traffic leaving em0 that's not - for
example - 192.168.1.0/24:

pass out on em0 from $int_net to ! $int_net received-on em0 nat-to iwn0

Didn't have the time to check this rule though.

Can't compile php from ports

[Mik J]

Hello,
Does anyone knows why compiling php from ports systematically fails ? It's been 
since openbsd 6.8 that it acts this way
/usr/ports/pobj/php-7.4.19/bin/install -c -m 644 
/usr/ports/pobj/php-7.4.19/php-7.4.19/modules/opcache.so  
/usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/lib/php-7.4/modules/opcache.so
echo "zend_extension=opcache.so" >  
/usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/share/examples/php-7.4/opcache.ini
/usr/ports/pobj/php-7.4.19/bin/install -d -m 755 
/usr/ports/pobj/php-7.4.19/fake-amd64//var/www/etc
echo "www:*:67:67::0:0:dummy user to appease 
c-client:/nonexistent:/sbin/nologin" >  
/usr/ports/pobj/php-7.4.19/fake-amd64//var/www/etc/master.passwd.imap
pwd_mkdb -d /usr/ports/pobj/php-7.4.19/fake-amd64//var/www/etc 
master.passwd.imap
/usr/ports/pobj/php-7.4.19/bin/install -c -m 644 
/usr/ports/pobj/php-7.4.19/php-7.4.19/sapi/cli/php.1 
/usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/man/man1/php-7.4.1
ln -s phar-7.4 /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/phar
ln -s php-7.4 /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php
Reading existing plist for php-7.4.19
Reading existing plist for php-apache-7.4.19
Reading existing plist for php-cgi-7.4.19
Reading existing plist for php-dbg-7.4.19
Reading existing plist for php-xmlrpc-7.4.19
Reading existing plist for php-bz2-7.4.19
Reading existing plist for php-curl-7.4.19
Reading existing plist for php-dba-7.4.19
Reading existing plist for php-enchant-7.4.19
Reading existing plist for php-gd-7.4.19
Reading existing plist for php-gmp-7.4.19
Reading existing plist for php-intl-7.4.19
Reading existing plist for php-imap-7.4.19
Reading existing plist for php-ldap-7.4.19
Reading existing plist for php-mysqli-7.4.19
Reading existing plist for php-odbc-7.4.19
Reading existing plist for php-pcntl-7.4.19
Reading existing plist for php-pdo_mysql-7.4.19
Reading existing plist for php-pdo_odbc-7.4.19
Reading existing plist for php-pdo_pgsql-7.4.19
Reading existing plist for php-pdo_sqlite-7.4.19
Reading existing plist for php-pgsql-7.4.19
Reading existing plist for php-pspell-7.4.19
Reading existing plist for php-shmop-7.4.19
Reading existing plist for php-soap-7.4.19
Reading existing plist for php-snmp-7.4.19
Reading existing plist for php-sqlite3-7.4.19
Reading existing plist for php-pdo_dblib-7.4.19
Reading existing plist for php-tidy-7.4.19
Reading existing plist for php-xsl-7.4.19
Reading existing plist for php-zip-7.4.19
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/Makefile.new
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-main
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-apache
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-cgi
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-dbg
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-xmlrpc
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-bz2
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-curl
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-dba
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-enchant
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-gd
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-gmp
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-intl
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-imap
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-ldap
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-mysqli
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-odbc
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pcntl
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pdo_mysql
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pdo_odbc
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pdo_pgsql
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pdo_sqlite
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pgsql
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pspell
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-shmop
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-soap
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-snmp
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-sqlite3
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-pdo_dblib
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-tidy
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-xsl
Writing /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/PLIST-zip
Renaming /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/Makefile.new to 
Makefile
> Extracting debug info from 
> /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4
> Extracting debug info from 
> /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/lib/php-7.4/modules/opcache.so
> Extracting debug info from 
> 

Openbsd 6.9 Default gateway

[Irshad Sulaiman]

Hi 
How to set only one default gateway if I have multiple interface , one is 
in DHCP and other in Static ip 
I have set /etc/mygate 192.168.100.1 and hostname.em0 (DHCP) and hostname.iwn0 
(static 192.168.100.163 255.255.255.0)

But when I sh /etc/netstart it sets multiple gateway with following 
Internet:

DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.1.1UGS0   37 - 8 em0
default192.168.100.1  UGS00 -12 iwn0

Only iwn0 have internet and I cannot connect to internet 

How to set hostname.iwn0 as default gateway 
 
With multiple default gateway I cannot ping outside 


Appreciate 
 

Re: Openbsd 6.9 Default gateway

[Daniel Jakots]

On Sat, 8 May 2021 02:37:41 +0300, Irshad Sulaiman
 wrote:

> Thank you for the reply 
> 
> 
>   I could do by 
> Delete and adding route with route command manually 
> But is there any better way to do this 

If you used the same network both on wired and wireless, you could use
a trunk(4) in failover mode for a transparent transition. Check
"Trunking Your Wireless Adapter" in
https://www.openbsd.org/faq/faq6.html

Cheers,
Daniel

Re: Extremely bizarre using sysupgrade from May 6 -current

[Chris Bennett]

Ha! Sorry for the noise.
I needed to check a file from etc with the latest -current.
I untarred base69.tgz in the _sysupgrade directory.

Script choked on the existing wrong files.

+1 for good work on sysupgrade!
-1/2 for me not cleaning up!

ROFL at myself,
Chris Bennett

Extremely bizarre using sysupgrade from May 6 -current

[Chris Bennett]

I just ran sysupgrade -snk and got this:

CX ~ # sysupgrade -snk  
  
Fetching from https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/
SHA256.sig   100% 
||  2144
   00:00
Signature Verified
Verifying old sets.
rm: altroot: is a directory
rm: bin: is a directory
rm: dev: is a directory
rm: etc: is a directory
rm: home: is a directory
rm: mnt: is a directory
rm: root: is a directory
rm: sbin: is a directory
rm: tmp: is a directory
rm: usr: is a directory
rm: var: is a directory

CX ~ # ls /home/_sysupgrade/
  
total 200
drwxr-xr-x  13 root  wheel512 May  7 19:47 .
drwxr-xr-x  30 root  wheel   2560 May  6 07:09 ..
-rw-r--r--   1 root  wheel  43523 Feb 16 11:10 INSTALL.amd64
-rw-r--r--   1 root  wheel   1992 May  7 19:47 SHA256
drwxr-xr-x   2 root  wheel512 May  6 03:29 altroot
drwxr-xr-x   2 root  wheel   1024 May  6 03:29 bin
drwxr-xr-x   2 root  wheel512 May  6 03:29 dev
drwxr-xr-x  21 root  wheel   1024 May  6 03:30 etc
drwxr-xr-x   2 root  wheel512 May  6 03:29 home
drwxr-xr-x   2 root  wheel512 May  6 03:29 mnt
drwx--   3 root  wheel512 May  6 03:29 root
drwxr-xr-x   2 root  wheel   1536 May  6 03:29 sbin
drwxr-xr-x   2 root  wheel512 May  6 03:29 tmp
drwxr-xr-x  12 root  wheel512 May  6 03:29 usr
drwxr-xr-x  23 root  wheel512 May  6 03:29 var
CX ~ # ls /home/_sysupgrade/bin
total 20328
drwxr-xr-x   2 root  wheel1024 May  6 03:29 .
drwxr-xr-x  13 root  wheel 512 May  7 19:47 ..
-r-xr-xr-x   2 root  wheel  128232 May  6 03:29 [
-r-xr-xr-x   1 root  wheel  130680 May  6 03:29 cat
-r-xr-xr-x   3 root  wheel  281992 May  6 03:29 chgrp
-r-xr-xr-x   1 root  wheel  149304 May  6 03:29 chio
-r-xr-xr-x   3 root  wheel  281992 May  6 03:29 chmod
-r-xr-xr-x   5 root  wheel  184632 May  6 03:29 cksum
-r-xr-xr-x   1 root  wheel  159872 May  6 03:29 cp
[snip]

All mounts are correct and nothing unexpected from last.
After all of the "fun" about sysupgrade, I can almost believe this
is a joke. ROFL if it is!

Either way, I'll check out a fresh src.

Chris Bennett

OpenBSD 6.9-current (GENERIC.MP) #5: Thu May  6 02:53:29 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34289893376 (32701MB)
avail mem = 33235222528 (31695MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8f676000 (36 entries)
bios0: vendor American Megatrends Inc. version "2.2" date 05/23/2018
bios0: Supermicro X11SSD-F
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG HPET LPIT SSDT SSDT SSDT DBGP 
DBG2 SSDT PRAD SSDT UEFI SSDT DMAR EINJ ERST BERT HEST
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) 
RP13(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz, 3801.19 MHz, 06-9e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz, 3800.01 MHz, 06-9e-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz, 3800.01 MHz, 06-9e-09
cpu2: 

Re: pf ipv6 source-routing 6.9

[Stuart Henderson]

On 2021-05-07, Bastien Durel  wrote:
> Hello,
>
> I have multiple ISPs plugged on my OpenBSD box, each one providing its
> IPv6 address space.
>
> I used to route outgoing streams with :
>
> net2_if = pppoe0 
> ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
> ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
> table  const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
> pass out on $net_if from $ovh_v6_prefix to ! route-to 
> $ovh_v6_router
> pass out on $tun_ifs from $ovh_v6_prefix to ! route-to 
> $ovh_v6_router

This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.

Re: bitcoind out of memory

[Stuart Henderson]

On 2021-05-07, yancy ribbens  wrote:
> I'm running 6.8 and trying to run bitcoind (C++), however, I continue to
> receive a core dump while running the application (out of memory).  The
> dmesg file is below.

Always surprises me when people are willing to run things like that as root..

> The application is running as root and I've set datasize-max and
> datasize-cur to infinity in the login.conf daemon section as I suspect the
> core dump is happening because of an upper memory bound enforced by the OS.

Did you logout and back in between updating login.conf and retrying?
(Needs to be a full logout; if you use an ssh persistent connection that
will need to be closed; if you use X that needs to be restarted).
Check what ulimit -a says.

> running the application \time -l twice shows the resident set size each
> time to be:
> 662128
> 650388
>
> I've also observed "top" while running and there is more than 1GB free and
> SWAP is not being used at the time it core dumps (out of memory).

If it requests an allocation which fails, that memory won't be "used" to
show up in top / time -l.

> Is this a problem with a login.conf parameter or something else?
>
> OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct  4 18:33:20 MDT 2020
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
...
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

LONG in the cpu capabilities line means that the hardware can usually run
amd64. That would give you a few hundred MB more physical memory, and much
more available memory address space (and a lot of software is only really
tested on 64-bit archs these days anyway..) So you might possibly like
to try that.

pf ipv6 source-routing 6.9

[Bastien Durel]

Hello,

I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.

I used to route outgoing streams with :

net2_if = pppoe0 
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table  const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router

And incoming with :

pass in on $net2_if inet6 reply-to $ovh_v6_router keep state

I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0 to let pf
load its configuration file, but this does not seems to work:

Here are incoming packets :

fremen# tcpdump -nvv -i pppoe0 host 2001:41d0:8:91a::1
tcpdump: listening on pppoe0, link-type PPP_ETHER
17:50:30.401270 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: 
icmp6: echo request (id:3a19 seq:100) [icmp6 cksum ok] (len 64, hlim 55)
17:50:31.409201 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: 
icmp6: echo request (id:3a19 seq:101) [icmp6 cksum ok] (len 64, hlim 55)

Here are outgoing ones :

fremen# tcpdump -nvv -i wg2 host 2001:41d0:8:91a::1 
tcpdump: listening on wg2, link-type LOOP
17:51:14.753505 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: 
icmp6: echo reply (id:3a19 seq:144) [icmp6 cksum ok] [flowlabel 0xe86a] (len 
64, hlim 63)
17:51:15.761535 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: 
icmp6: echo reply (id:3a19 seq:145) [icmp6 cksum ok] [flowlabel 0xe86a] (len 
64, hlim 63)

There is a route for 2001:41d0::/32 on wg2, that's why it takes it, but
the route-to should have forced it to exit via pppoe0, isn't it ? (wg2
is in $tun_ifs)

What's the correct syntax to make route-to works with LL addresses ?

BTW, if there's a better way of handling this source-routing problem,
I'm open to suggestions

Regards,

-- 
Bastien

bitcoind out of memory

[yancy ribbens]

I'm running 6.8 and trying to run bitcoind (C++), however, I continue to
receive a core dump while running the application (out of memory).  The
dmesg file is below.

The application is running as root and I've set datasize-max and
datasize-cur to infinity in the login.conf daemon section as I suspect the
core dump is happening because of an upper memory bound enforced by the OS.

running the application \time -l twice shows the resident set size each
time to be:
662128
650388

I've also observed "top" while running and there is more than 1GB free and
SWAP is not being used at the time it core dumps (out of memory).

Is this a problem with a login.conf parameter or something else?

OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct  4 18:33:20 MDT 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 3707572224 (3535MB)
avail mem = 3623641088 (3455MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/22/09, BIOS32 rev. 0 @ 0xffa10, SMBIOS rev. 2.4
@ 0xf6510 (54 entries)
bios0: vendor Dell Inc. version "A14" date 12/22/2009
bios0: Dell Inc. Latitude E4300
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET  APIC ASF! MCFG TCPA SLIC BOOT SSDT
acpi0: wakeup devices PCI0(S4) PCIE(S4) USB1(S0) USB2(S0) USB3(S0) USB4(S0)
USB5(S0) USB6(S0) EHC2(S0) EHCI(S0) AZAL(S3) RP01(S4) RP02(S4) RP03(S3)
RP04(S3) RP05(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P9400 @ 2.40GHz ("GenuineIntel" 686-class)
2.40 GHz, 06-17-06
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P9400 @ 2.40GHz ("GenuineIntel" 686-class)
2.40 GHz, 06-17-06
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCIE)
acpiprt2 at acpi0: bus 11 (RP01)
acpiprt3 at acpi0: bus 12 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 13 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiec0 at acpi0
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
"*pnp0c14" at acpi0 not configured
acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 107 degC
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: LCD_
acpivideo1 at acpi0: VID2
bios0: ROM list: 0xc/0xf800! 0xcf800/0x800
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 2 int 16, GM45, gen 4
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address
00:24:e8:a8:ee:60
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 2 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 2 int 22
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: IDT 92HD71B7, Intel/0x2802, using IDT 92HD71B7
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: apic 2 int 16
pci1 at ppb0 bus 11
ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: apic 2 int 17
pci2 at ppb1 bus 12
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
3T3R, MoW, address 00:21:6a:2d:87:7c
ppb2 at pci0 dev 28 function 3 

Re: Tor Relay log warning

[lawgiver]

On 5/5/2021 at 5:34 PM, "Theo Buehler"  wrote:
>
>On Wed, May 05, 2021 at 08:06:09AM -0300, Matheus Coelho wrote:
>> Hello List!
>> 
>> I have a tor relay server and in version 6.9 of openbsd the log 
>started
>> showing this message:
>> 
>> tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake 
>didn't get
>> set. Fixing that. (on Tor 0.4.5.7 )

Experiencing the same (running a bridge).

>> I suspect something related to libressl according to this post:
>
>Yes, libressl doesn't fully support the info callback that tor
>relies on to set wasV2Handshake. This will be a bit tricky to fix.
>I think tor will still work, but the log spam is annoying.

For what it's worth, metrics.torproject.org now reports my bridge as "offline", 
so in this instance tor no longer appears to still work.

>> https://gitlab.torproject.org/tpo/core/tor/-/issues/40128
>
>This post conflates many different issues, most of which should be
>resolved.
>
>> 
>> it makes sense?
>> 
>> thanks in advance.
>> --
>> Matheus Coelho Torres Macedo

-lg.

Re: fighting amplification attack --was: Re: pf: block drop not working

[Stuart Henderson]

No this is not possible. UDP is trivially spoofed (which is probably why 
you see the problem in the first place; the source IPs you see on the 
packets are the *victims* not the attacker). Doing this for UDP opens an 
easy DoS of your legitimate clients.


--
 Sent from a phone, apologies for poor formatting.
On 7 May 2021 09:54:58 Axel Rau  wrote:





Am 05.05.2021 um 16:20 schrieb Stuart Henderson :


This is usually best dealt with in your DNS server software e.g. by using
the rrl-* configuration in NSD, see nsd.conf(5), or "rate-limit" config
section in BIND.


Yes, I have this in place now, but I try to let the fw drop them:
This seems not working:
udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
 flush global )'

…
pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns inbound"
Is this not possible with udp?

Axel

---
PGP-Key: CDE74120  ☀  computing @ chaos claudius

Re: IKEv2: CHILD_SA is not created

[Tobias Heider]

On Fri, May 07, 2021 at 12:17:35PM +0300, Денис Давыдов wrote:
> Hello all,
> 
> I can't understand why I got SA_INIT timeout:
> May  5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free:
> SA_INIT timeout
> 
> 1.1.1.1 (crypto-gw2) - my host
> 7.7.7.7 - our isp provider (some of cisco devices)
> 
> /etc/iked.conf (on 1.1.1.1):
> 
> ikev2 crypto-primary active esp \
>   from 10.21.139.8/30 to 2.2.2.2 \
>   from 10.21.139.8/30 to 3.3.3.3 \
>   peer 7.7.7.7 \
>   ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group modp2048
> \
>   childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
>   ikelifetime 86400 lifetime 28800 \
>   psk "secret"
> 
> The remote side claims to have the same settings.
> 
> crypto-gw2# ikectl sh sa | grep 7.7.7.7
> iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd
> 1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0 pol
> 0xb0e9b38d000
> 
> Why CHILD_SA is not being created? I tried to figure it out from the logs
> but couldn't.


It looks like the peer sends its IKE_AUTH reply without SA payload but
with a TS_UNACCEPTABLE notification.
The most likely cause is that your "from ... to ..." configuration is
incompatible with the configuration of your peer.

Thanks for the report, I will see how I can make this error more obvious
in the logs.

Re: fighting amplification attack --was: Re: pf: block drop not working

[Tom Smyth]

Hello Axel,

Check out fastnetmon  if you have SFLOW (Preferably ) or Netflow
support on your switches   /or routers facing external providers
you can put pps per second thresholds on .

but bear in mind if the amount of bandwdith being sent to your router
exceeds capacity you need to send a BGP community to
do  remote Triggered Black Holeto your providers...  RTBH ... (BGP
Communities) etc..

Best of Luck

On Fri, 7 May 2021 at 10:10, Axel Rau  wrote:
>
>
>
> > Am 05.05.2021 um 16:20 schrieb Stuart Henderson  > >:
> >
> > This is usually best dealt with in your DNS server software e.g. by using
> > the rrl-* configuration in NSD, see nsd.conf(5), or "rate-limit" config
> > section in BIND.
>
> Yes, I have this in place now, but I try to let the fw drop them:
> This seems not working:
> udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
>  flush global )'
> …
> pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
> port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns 
> inbound"
>
> Is this not possible with udp?
>
> Axel
> ---
> PGP-Key: CDE74120computing @ chaos claudius
>


-- 
Kindest regards,
Tom Smyth.

IKEv2: CHILD_SA is not created

[Денис Давыдов]

Hello all,

I can't understand why I got SA_INIT timeout:
May  5 13:18:54 crypto-gw2 iked[65530]: spi=0x73bcd531eb2e8899: sa_free:
SA_INIT timeout

1.1.1.1 (crypto-gw2) - my host
7.7.7.7 - our isp provider (some of cisco devices)

/etc/iked.conf (on 1.1.1.1):

ikev2 crypto-primary active esp \
  from 10.21.139.8/30 to 2.2.2.2 \
  from 10.21.139.8/30 to 3.3.3.3 \
  peer 7.7.7.7 \
  ikesa auth hmac-sha2-256 enc aes-256 prf hmac-sha2-256 group modp2048
\
  childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
  ikelifetime 86400 lifetime 28800 \
  psk "secret"

The remote side claims to have the same settings.

crypto-gw2# ikectl sh sa | grep 7.7.7.7
iked_sas: 0xb0e1878b7d0 rspi 0x2d606f017d098928 ispi 0xd0497626849535cd
1.1.1.1:500->7.7.7.7:500[] AUTH_SUCCESS i nexti 0x0 pol
0xb0e9b38d000

Why CHILD_SA is not being created? I tried to figure it out from the logs
but couldn't.

Verbose log here:
https://pastebin.com/yifQdjGy

I would be glad for any advice.

--
Sincerely,
Denis

Re: Trying to understand/debug caldav vs. httpd issue

[Stuart Henderson]

On 2021-05-05, T. Ribbrock  wrote:
> Hi all,
>
> this may be a long shot, but I'm looking for someone who can give me a
> few pointers (if this is better posted to another list, please let me
> know as well).
>
> TL;DR: I am running into issues with a webdav/caldav client
> connecting to a Nextcloud instance running on OpenBSD httpd, so someone
> with a more intimate knowledge of httpd would probably already be a
> great help.

This is not a bad place to ask. Your description is good but anyone
looking into what's up will want to test, so if you could include
the test tools and a description of setup needed to reproduce that
would help. Including the tcpdump traces would help too. Don't worry
about the mail being long.

> Using tcpdump on the test server, I was able to determine some
> differences between the two test clients:
>
> The Perl-client seems to send both http-headers and the XML-body for the
> PROPFIND in one go, gets a 401 response and then re-issues the request
> with authorisation (which then succeeds).
>
> The Qt-client sends the http-headers first in one TCP-segment (I'm not
> too good on terminology...). Once that has happened, httpd already sends
> back the 401 - and *then* the Qt-client sends the XML-body in a second
> TCP-segment, causing the "400 Bad Request" response (I presume because
> httpd is expecting new headers at this point, not a content body).

It makes no difference to the HTTP protocol whether headers and body are
in separate TCP segments, but some software may handle things wrongly.
httpd uses libevent and it wouldn't be the first time libevent-based
software has problems with data in separate TCP segments (I have a
feeling we might have had a problem with ftp-proxy related to this
but can't find any details, perhaps it was never fixed),

> What I am now trying to figure out (and I neither know the relevant
> standards nor httpd well enough to do so) is whether this is something
> weird on the Qt side - or on the OpenBSD/httpd side so I can eventually
> provide input to the right people to hopefully get this fixed at some
> point.

Pretty sure it will be on the httpd side.

Re: fighting amplification attack --was: Re: pf: block drop not working

[Axel Rau]

> Am 05.05.2021 um 16:20 schrieb Stuart Henderson  >:
> 
> This is usually best dealt with in your DNS server software e.g. by using
> the rrl-* configuration in NSD, see nsd.conf(5), or "rate-limit" config
> section in BIND.

Yes, I have this in place now, but I try to let the fw drop them:
This seems not working:
udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
 flush global )'
…
pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns inbound"

Is this not possible with udp?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP

Re: I can’t get veb/vport to work with vmd.

[Stuart Henderson]

On 2021-05-06, Luke Small  wrote:
> I got it working. I have a pretty hefty amount of vether0 and
> vether0:network in my pf.conf that I changed to vport0 and vport0:network.
>
> That fixed every single thing!
>
> I somehow completely forgot about all the vether0 pf rules which isolates
> the the various local systems so VMs are isolated from being able to do
> anything malicious to any local systems.
>
> I silently redirect the VMs' dns and ntp calls to my OpenBSD services to
> harden them a bit too.
>
> -Luke
>

Make sure you remember you've done this when you try to debug a DNS
problem on the VMs. Recursive and authoritative DNS lookups aren't
interchangeable...

If you want to force a specific DNS server I recommend blocking others,
not silently redirecting.

Re: DHCPd - option capwap (code 138)

[Stuart Henderson]

On 2021-05-06, Radek  wrote:
> Hello,
> I want to use dhcpd server to push Wireless Controller's IP address to the 
> APs.
>
> According to this:
> http://systemnetworksecurity.blogspot.com/2013/02/adding-custom-options-in-isc-dhcpds.html
> https://www.secuvera.de/blog/capwap-dhcp-option-138-auf-isc-dhcpd-server-einrichten/
> I need to add *option capwap* to /etc/dhcpd.conf
>
> option capwap code 138 = ip-address; #Custom Option capwap
> option capwap 192.168.1.110; #WLAN-Controller-IP
>
> I can't find the capwap option in dhcp-options(5) i OpenBSD.
> How can I do what I need using other options/configuration? 
> Thanks!

It's a proper RFC protocol so we could add it to dhcpd. Possible
diff below, maybe it should be moved to the named part of
dhcp_option_default_priority too but there are other named options
which aren't listed so I've left that out for now.

CAPWAP is RFC5415, the DHCP option is defined in RFC5417.

Index: dhcp-options.5
===
RCS file: /cvs/src/usr.sbin/dhcpd/dhcp-options.5,v
retrieving revision 1.31
diff -u -p -r1.31 dhcp-options.5
--- dhcp-options.5  8 May 2019 22:00:55 -   1.31
+++ dhcp-options.5  7 May 2021 08:38:48 -
@@ -169,6 +169,13 @@ Some DHCP clients will support it, and o
 This option specifies the broadcast address in use on the client's subnet.
 Legal values for broadcast addresses are specified in section 3.2.1.3 of
 RFC 1122.
+.It Ic option capwap-ac Ar ip-address Oo , Ar ip-address ... Oc ;
+The
+.Ic capwap-ac
+option specifies a list of IP addresses of Wireless Access Controllers.
+These are used by Wireless Termination Points using the Control And
+Provisioning of Wireless Access Points (CAPWAP) protocol, RFC 5415.
+Addresses should be listed in order of preference.
 .It Ic option classless-static-routes Ar cidr ip-address Oo , Ar cidr 
ip-address ... Oc ;
 This option specifies a list of destination networks and the
 associated gateways.
Index: dhcp.h
===
RCS file: /cvs/src/usr.sbin/dhcpd/dhcp.h,v
retrieving revision 1.11
diff -u -p -r1.11 dhcp.h
--- dhcp.h  8 May 2019 22:00:55 -   1.11
+++ dhcp.h  7 May 2021 08:38:48 -
@@ -173,6 +173,7 @@ struct dhcp_packet {
 #define DHO_NDS_CONTEXT87
 #define DHO_DOMAIN_SEARCH  119
 #define DHO_CLASSLESS_STATIC_ROUTES121
+#define DHO_CAPWAP_AC  138
 #define DHO_TFTP_CONFIG_FILE   144
 #define DHO_VOIP_CONFIGURATION_SERVER  150
 #define DHO_CLASSLESS_MS_STATIC_ROUTES 249
Index: tables.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/tables.c,v
retrieving revision 1.14
diff -u -p -r1.14 tables.c
--- tables.c8 May 2019 22:00:55 -   1.14
+++ tables.c7 May 2021 08:38:48 -
@@ -214,7 +214,7 @@ struct option dhcp_options[256] = {
{ "option-135", "X",_universe, 135 },
{ "option-136", "X",_universe, 136 },
{ "option-137", "X",_universe, 137 },
-   { "option-138", "X",_universe, 138 },
+   { "capwap-ac", "lA",_universe, 138 },
{ "option-139", "X",_universe, 139 },
{ "option-140", "X",_universe, 140 },
{ "option-141", "X",_universe, 141 },
@@ -404,6 +404,8 @@ unsigned char dhcp_option_default_priori
DHO_NETBIOS_SCOPE,
DHO_FONT_SERVERS,
DHO_X_DISPLAY_MANAGER,
+   DHO_CAPWAP_AC,
+   DHO_VOIP_CONFIGURATION_SERVER,
DHO_DHCP_PARAMETER_REQUEST_LIST,
DHO_DHCP_USER_CLASS_ID,
DHO_RELAY_AGENT_INFORMATION,/* Should be the last option. */
@@ -417,9 +419,9 @@ unsigned char dhcp_option_default_priori
100, 101, 102, 103, 104, 105, 106, 107, 108, 109,
110, 111, 112, 113, 114, 115, 116, 117, 118,
120,  122, 123, 124, 125, 126, 127, 128, 129,
-   130, 131, 132, 133, 134, 135, 136, 137, 138, 139,
+   130, 131, 132, 133, 134, 135, 136, 137,  139,
140, 141, 142, 143, 144, 145, 146, 147, 148, 149,
-   150, 151, 152, 153, 154, 155, 156, 157, 158, 159,
+151, 152, 153, 154, 155, 156, 157, 158, 159,
160, 161, 162, 163, 164, 165, 166, 167, 168, 169,
170, 171, 172, 173, 174, 175, 176, 177, 178, 179,
180, 181, 182, 183, 184, 185, 186, 187, 188, 189,