Re: iked EAP account limit

2022-02-23 Thread readme
On Mon, Feb 21, 2022 at 01:33:12PM +, n8dandy wrote:
>Hello there,
>
>First of all, I would like to thank people involved with iked. It works
>flawlessly, especially with Apple devices. Thanks for your work.  In the
>near future, I plan to allow around 330 people to use this service. Do you
>know how many accounts we can support with the "user" directive ? Is there
>any limit ?

If you're using EAP with Mac clients could you please post santized configs?

TIA!



Re: ikev2 fails with mschap-v2

2022-02-23 Thread readme
On Wed, Feb 23, 2022 at 09:57:30PM +0100, Tobias Heider wrote:
>On Mon, Feb 21, 2022 at 09:12:27AM -0600, rea...@catastrophe.net wrote:
>> On Mon, Feb 21, 2022 at 02:55:39PM +0100, Tobias Heider wrote:
>> >On Sat, Feb 19, 2022 at 12:28:15AM -0600, rea...@catastrophe.net wrote:
>> >> IKE is failing when I connect using a simple password defined in
>> >> /etc/iked.conf. I'm connecting from a native Mac client...is 
>> >> mschap-v2 on MacOS broken or are my configs wrong? Thanks in advance.
>> >> 
>> [..]
>> >> /etc/iked.conf - fails with username/password
>> >> ##
>> >> user "testuser" "testpassword"
>> >> ikev2 "ROAD_WARRIOR" esp \
>> >>   from 0.0.0.0/0 to 10.1.255.0/24 \
>> >>   peer any local vpn.company.com \
>> >> srcid vpn.company.com \
>> >> dstid mac-laptop \
>> >> eap "mschap-v2" \
>> >>   config address 10.1.255.0/24 \
>> >> config name-server 10.1.255.1 \
>> >>   tag "$name-$id"
>> >> 
>> >Hard to tell what's going wrong here. Looks like the mac ignores the 
>> >IKE_AUTH
>> >response and restarts the handshake.  I haven't seen any other reports about
>> >problems with the mac implementation and i don't have one to test.
>> >You could try enabling verbose logging with 'iked -dvvv' or
>> >'ikectl log verbose' and see if that gives us any clues.
>> 
>> Here is the output of iked -dvvv
>
>Looks all ok.  Is there any way to get logs from the mac?
>It still looks like the other side just drops the AUTH response
>for no obvious reason.
>

I honestly have no idea where the logs would even be stored or what
the daemon runs as under MacOS 12.2.1 (Monterey).



privileged instruction fault trap for pf_tabladdr_setup

2022-02-23 Thread David Newman

OpenBSD 7.0 GENERIC#3 i386, running as a VM on VMware vSphere 5.5

After applying a security fix through syspatch, this system failed on 
reboot with the error:


kernel: privileged instruction fault trap, code=0
Stopped at: pf_tabladdr_setup:

Links to trace and ps info below. Thanks in advance for clues on 
reviving this machine.


There are other fault trap threads in the misc archive, but I found none 
about pf_tabladdr_setup.


Some other threads suggesting underlying hardware problems. This is 
certainly possible but there are other VMs running OK on this host, and 
the host logs don't indicate any disk or memory trouble.


FWIW I used this machine for years, at least back into the OpenBSD 5.x 
days, and have upgraded all along without issue.


Here is the ddb trace:

ddb> trace
pf_tabladdr_setup(d0e95da8,d1dfaf58) at pf_tabladdr_setup
pfioctl(4900,ccc84404,d1b26000,3,d19b1980) at pfioctl+0x4028
spec_ioctl(f3ac7734) at spec_ioctl+0x4c
VOP_IOCTL(d19919e4,ccc84404,d1b26000,d19b1980) at VOP_IOCTL+0x53
vn_ioctl(d19bbc60,ccc84404,d1b26000,d19b1980) at vn_ioctl+0x4f
sys_ioctl(d19b1980,f3ac78f0,f3ac78e8) at sys_ioctl+0x240
syscall(f3ac7930) at syscall+0x2cd
Xsyscall_untramp() at Xsyscall_untramp+0xa9
end of kernel

Unfortunately I can't copy/paste the output of 'ps' but I've posted 
screen captures of trace and ps here:


https://ibb.co/WP4R58D

https://ibb.co/9ZCNdd5

Thanks again.

dn





Re: ikev2 fails with mschap-v2

2022-02-23 Thread Tobias Heider
On Mon, Feb 21, 2022 at 09:12:27AM -0600, rea...@catastrophe.net wrote:
> On Mon, Feb 21, 2022 at 02:55:39PM +0100, Tobias Heider wrote:
> >On Sat, Feb 19, 2022 at 12:28:15AM -0600, rea...@catastrophe.net wrote:
> >> IKE is failing when I connect using a simple password defined in
> >> /etc/iked.conf. I'm connecting from a native Mac client...is 
> >> mschap-v2 on MacOS broken or are my configs wrong? Thanks in advance.
> >> 
> [..]
> >> /etc/iked.conf - fails with username/password
> >> ##
> >> user "testuser" "testpassword"
> >> ikev2 "ROAD_WARRIOR" esp \
> >>from 0.0.0.0/0 to 10.1.255.0/24 \
> >>peer any local vpn.company.com \
> >> srcid vpn.company.com \
> >> dstid mac-laptop \
> >> eap "mschap-v2" \
> >>config address 10.1.255.0/24 \
> >> config name-server 10.1.255.1 \
> >>tag "$name-$id"
> >> 
> >Hard to tell what's going wrong here. Looks like the mac ignores the IKE_AUTH
> >response and restarts the handshake.  I haven't seen any other reports about
> >problems with the mac implementation and i don't have one to test.
> >You could try enabling verbose logging with 'iked -dvvv' or
> >'ikectl log verbose' and see if that gives us any clues.
> 
> Here is the output of iked -dvvv

Looks all ok.  Is there any way to get logs from the mac?
It still looks like the other side just drops the AUTH response
for no obvious reason.

> 
> bash-5.1# iked -dvvv 
> create_ike: using signature for peer mac-laptop
> ikev2 "ROAD_WARRIOR" passive tunnel esp inet from 0.0.0.0/0 to 10.1.255.0/24 
> local 192.168.110.50 peer any ikesa enc aes-128-gcm enc aes-256-gcm prf 
> hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group 
> curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group 
> modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc 
> aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf 
> hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth 
> hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group 
> ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group 
> modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa 
> enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 
> auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid vpn.company.com 
> dstid mac-laptop lifetime 10800 bytes 4294967296 eap "MSCHAP_V2" config 
> address 10.1.255.0 config name-server 10.1.255.1 tag "$name-$id"
> /etc/iked.conf: loaded 2 configuration rules
> ca_privkey_serialize: type RSA_KEY length 1192
> ca_pubkey_serialize: type RSA_KEY length 270
> ca_privkey_to_method: type RSA_KEY method RSA_SIG
> ca_getkey: received private key type RSA_KEY length 1192
> ca_getkey: received public key type RSA_KEY length 270
> ca_dispatch_parent: config reset
> ca_reload: loaded cert file vpn.company.com.crt
> ca_validate_cert: /C=US/ST=Anystate/L=Anytown/O=Company.COM/OU=Remote Network 
> Services/CN=vpn.company.com/emailAddress=r...@company.com unable to get local 
> issuer certificate
> ca_reload: local cert type RSA_KEY
> config_getocsp: ocsp_url none tolerate 0 maxage -1
> config_new_user: inserting new user testuser
> user "testuser" "testpassword"
> ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0
> config_getpolicy: received policy
> config_getpfkey: received pfkey fd 3
> config_getcompile: compilation done
> config_getsocket: received socket fd 4
> config_getsocket: received socket fd 5
> config_getsocket: received socket fd 6
> config_getsocket: received socket fd 7
> config_getstatic: dpd_check_interval 60
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> config_getstatic: no stickyaddress
> policy_lookup: setting policy 'ROAD_WARRIOR'
> spi=0x2cb46a467283eb2e: recv IKE_SA_INIT req 0 peer 172.20.20.11:62336 local 
> 192.168.110.50:500, 604 bytes, policy 'ROAD_WARRIOR'
> ikev2_recv: ispi 0x2cb46a467283eb2e rspi 0x
> ikev2_policy2id: srcid FQDN/vpn.company.com length 23
> ikev2_pld_parse: header ispi 0x2cb46a467283eb2e rspi 0x 
> nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 
> 604 response 0
> ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 220
> ikev2_pld_sa: more 2 reserved 0 length 44 proposal #1 protoid IKE spisize 0 
> xforms 4 spi 0
> ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
> ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
> ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
> ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
> ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_2048
> ikev2_pld_sa: more 2 reserved 0 length 44 proposal #2 protoid IKE spisize 0 
> xforms 4 spi 0
> 

Re: How to disable disk's NCQ at boot (SOLVED)

2022-02-23 Thread Pekka Niiranen

HI,

I solved my problems by replacing the Samsung EVO 860 500GB SSD disk
with Western digital WD BLUES 3D NAND SSD 500GB disk.
Model: WDS5000G2B0A-00SM50

dmesg-

OpenBSD 7.0 (GENERIC.MP) #5: Mon Jan 31 09:09:02 MST 2022

r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3847286784 (3669MB)
avail mem = 3714658304 (3542MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xea840 (42 entries)
bios0: vendor Phoenix Technologies Ltd. version "3.0U" date 09/15/2017
bios0: WYSE D CLASS
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG SBST UEFI UEFI SSDT SSDT UEFI
acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S4) 
EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) SBAZ(S4) KBC0(S3) 
MSE0(S3) P2P_(S5) SPB0(S4) [...]

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 G-T48E Processor, 1397.55 MHz, 14-02-00
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T48E Processor, 1397.04 MHz, 14-02-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,

SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-31
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB4_)
acpiprt2 at acpi0: bus -1 (PB5_)
acpiprt3 at acpi0: bus -1 (PB6_)
acpiprt4 at acpi0: bus -1 (PB7_)
acpiprt5 at acpi0: bus 1 (P2P_)
acpiprt6 at acpi0: bus 2 (SPB0)
acpiprt7 at acpi0: bus 4 (SPB1)
acpiprt8 at acpi0: bus -1 (SPB2)
acpiprt9 at acpi0: bus -1 (SPB3)
acpibtn0 at acpi0: PWRB
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpiac0 at acpi0: AC unit online
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpipwrres0 at acpi0: P0L0, resource for Z0F0
acpipwrres1 at acpi0: P0L1, resource for Z0F1
acpipwrres2 at acpi0: P0L2, resource for Z0F2
acpipwrres3 at acpi0: P0L3, resource for Z0F3
acpitz0 at acpi0: critical temperature is 115 degC
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
acpivout0 at acpivideo1: LCD_
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6250" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci0 dev 1 function 1 "ATI Radeon HD 6310 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 
19, AHCI 1.2

ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  
naa.5001b448bc3f01f4

sd0: 476940MB, 512 bytes/sector, 976773168 sectors, thin
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support

ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 
2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support

ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "ATI EHCI root hub" rev 
2.00/1.00 addr 1

piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40
ppb0 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
pci1 at ppb0 bus 1
ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support

ppb1 at pci0 dev 

Re: 12-hour vs. 24-hour clock format

2022-02-23 Thread Christian Groessler

On 2/23/22 17:58, Laura Smith wrote:



a lot of peole don't do 24 hour clocks well.


For almost everyone outside North America, 24 hour clocks is the *only* thing 
they do. A bit like the weird American affection for m/d/y.  ;-)



Here in Germany, Bavaria at least, most people are using 12h 
colloquially, 24h clocks only in "offical" talking and writing.


regards,
chris



Re: 12-hour vs. 24-hour clock format

2022-02-23 Thread Theo de Raadt
So you want this command to behave differently in different environments?
Who wants that unpredicabtility?  I suspect noone wants that.

Your reference to POSIX is irrelevant because "w" is not a POSIX command.

Furthermore that feature creep in POSIX locales is not done by most
programs which do 24-hour clock by default, meaning it cannot force them
do 12-hour clock when requested, so the proposal feels like a one-way
road.

Anyways, it is like you didn't read my reply, I was saying: I don't
think we want to do your proposal.

Svyatoslav Mishyn  wrote:

> (Wed, 23 Feb 09:13) Theo de Raadt:
> > We do not have a firm rule that all programs must use 24-hour clock,
> > and I don't think we should create such a rule either.
> 
> OK, how about then before printing a date to check T_FMT_AMPM[0]?
> But if it were added to all code where approriate, then it would change
> standard behavior to some programs which currently display in 24-hour 
> format...
> so again no. 
> 
> As like in DragonflyBSD/FreeBSD:
> https://gitweb.dragonflybsd.org/dragonfly.git/blob/022bb0a9ed6967bc18e421ed074f5727e49314e0:/usr.bin/w/w.c#l133
> https://cgit.freebsd.org/src/tree/usr.bin/w/w.c?h=2d3725d62acbaca2fe84d43e8fd32ae9fb9a915b#n151
> 
> [0]: 
> https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap07.html
> 



Re: Updating mrouted in Base

2022-02-23 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2022/02/23 09:16, Theo de Raadt wrote:
> > Stuart Henderson  wrote:
> > 
> > > On 2022-02-21, Trace the Route  wrote:
> > > > Is it possible to include a newer version of mrouted in the base
> > > > installation of OpenBSD? The existing version of mrouted (v3.8) is
> > > > obviously quite old and lacks functionality found in newer versions.
> > > >
> > > > For example, the existing version of mrouted is not able to bind to
> > > > both ends of a pair(4) interface, whereas the latest version (v4.4)
> > > > has no issue with this.
> > > 
> > > It probably makes more sense to remove it from base. Do you fancy writing
> > > a port so it can be included there instead?
> > 
> > I dunno...
> > 
> > It seems to me that if multicast routing is going to be maintained in our
> > base tree, we probably want base utilities for it.  Otherwise, how would
> > anyone working in base development remember to test it when they make
> > changes?
> 
> Utilities yes, but do we need two different DVMRP daemons, one
> OpenBSD-style and privsepped and the other old and unmaintained?

No, we don't.

But included in the original email was a report that mrouted works better
tham dvmrpd...



Re: Updating mrouted in Base

2022-02-23 Thread Stuart Henderson
On 2022/02/23 09:16, Theo de Raadt wrote:
> Stuart Henderson  wrote:
> 
> > On 2022-02-21, Trace the Route  wrote:
> > > Is it possible to include a newer version of mrouted in the base
> > > installation of OpenBSD? The existing version of mrouted (v3.8) is
> > > obviously quite old and lacks functionality found in newer versions.
> > >
> > > For example, the existing version of mrouted is not able to bind to
> > > both ends of a pair(4) interface, whereas the latest version (v4.4)
> > > has no issue with this.
> > 
> > It probably makes more sense to remove it from base. Do you fancy writing
> > a port so it can be included there instead?
> 
> I dunno...
> 
> It seems to me that if multicast routing is going to be maintained in our
> base tree, we probably want base utilities for it.  Otherwise, how would
> anyone working in base development remember to test it when they make
> changes?

Utilities yes, but do we need two different DVMRP daemons, one
OpenBSD-style and privsepped and the other old and unmaintained?

> Sadly, we don't appear to have a mrouted developer.



Re: Updating mrouted in Base

2022-02-23 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2022-02-21, Trace the Route  wrote:
> > Is it possible to include a newer version of mrouted in the base
> > installation of OpenBSD? The existing version of mrouted (v3.8) is
> > obviously quite old and lacks functionality found in newer versions.
> >
> > For example, the existing version of mrouted is not able to bind to
> > both ends of a pair(4) interface, whereas the latest version (v4.4)
> > has no issue with this.
> 
> It probably makes more sense to remove it from base. Do you fancy writing
> a port so it can be included there instead?

I dunno...

It seems to me that if multicast routing is going to be maintained in our
base tree, we probably want base utilities for it.  Otherwise, how would
anyone working in base development remember to test it when they make
changes?

Sadly, we don't appear to have a mrouted developer.



Re: 12-hour vs. 24-hour clock format

2022-02-23 Thread Theo de Raadt
Svyatoslav Mishyn  wrote:

> just wondering why are some programs using 12-hour/24-hour clock format
> by default?
> 
> For instance, 12-hour clock format:
> w(1)/uptime(1) 
> Should it be fixed?

We do not have a firm rule that all programs must use 24-hour clock,
and I don't think we should create such a rule either.