Re: openssl cms -encrypt does not work with EC key/cert

[Theodore Wynnychenko]

Hello again:

I am re-posting this message with additional information..
While I have no expectation that there will be any reply, I am hopeful there
may be.

In any case, I have been struggling with this, and cannot get it to work
with EC certificates.
I am now wondering if this is a bug or a, currently, unsupported function in
Libressl..

$ openssl version
LibreSSL 3.3.2


> Hello
> 
> 
> I recently decided to change from RSA to EC keys/certs.
> I do this primarily as a learning exercise (there is no real corporate
> or
> professional demand to have this working).
> I am running OpenBSD current (6.9) from about 1 month ago.
> 
> Now that I am migrating to EC keys/certificates, I need to switch to
> "openssl cms".


It is my understanding that openssl smime only supports RSA certs, but
openssl cms should support RSA and EC certificates.


> 
> However, I am unable to encrypt using the EC certificate.
> 
> When I use:
> (I am going to obfuscate the emails in plain text.)
> 
> cat text.in | /usr/bin/openssl cms -encrypt -from 'User
> ' -to 'Admin ' -subject "Test
> Email"
> -aes256 encryption.pem > encrypted.out
> 
> with the old RSA certificate, everything works as expected.
> 
> But, when I replace the RSA cert with the EC certificate, it does not.
> Instead, I see:
> 
> 15724089243112:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl
> failure:/usr/src/lib/libcrypto/cms/cms_env.c:124:
> 15724089243112:error:2EFFF074:CMS routines:CRYPTO_internal:error
> setting
> recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944:
> 15724089243112:error:2EFFF068:CMS routines:CRYPTO_internal:cms
> lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850:
> 
> And the output file is zero size.
> 
> I tried a more basic command:
> 
> openssl cms -encrypt -in text.in -out encrypted.out -recip
> encryption.pem
> 
> Works with RSA certificate, same error with EC certificate.
> 
> I also tried (not really understanding):
> 
> openssl cms -encrypt -in text.in -out encrypted.out -recip
> encryption.pem
> -keyopt ecdh_kdf_md:sha256
> 
> and got the same error.
> 
> I then created some very basic self-signed EC certs.
> 


...

> 
> The second with the CN as the email, but no email in the DN:
> 
> Certificate:
> Data:
> Version: 1 (0x0)
> Serial Number:
> e5:fd:15:21:f1:b2:71:de
> Signature Algorithm: ecdsa-with-SHA384
> Issuer: C=US, ST=State, L=City, O=Org, OU=Home,
> CN=ad...@example.com
> Validity
> Not Before: May  6 17:18:43 2021 GMT
> Not After : May  6 17:18:43 2022 GMT
> Subject: C=US, ST=State, L=City, O=Org, OU=Home,
> CN=ad...@example.com
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (384 bit)
> pub:
> 04:8e:11:20:73:c8:8d:5d:61:43:c4:6b:bf:04:fe:
> c6:5d:a8:22:79:ae:0a:eb:de:0b:67:e6:32:24:43:
> 30:56:61:0a:e6:31:e4:82:cc:a8:9c:37:e9:90:01:
> df:e7:90:79:dc:d5:f1:c6:0c:6e:2f:bd:51:f8:98:
> 4e:4b:1b:16:52:73:73:d6:fd:1f:00:a1:f6:39:03:
> 98:3e:64:43:77:c3:c5:95:61:c3:22:05:3c:e6:d2:
> 86:29:e1:a3:9c:b9:32
> ASN1 OID: secp384r1
> NIST CURVE: P-384
> Signature Algorithm: ecdsa-with-SHA384
>  30:64:02:30:3f:06:2c:b1:e1:2f:b1:0b:1e:a1:1a:eb:29:1e:
>  8c:e5:c4:6a:73:f5:43:4e:24:77:88:bf:b1:99:51:15:02:50:
>  12:cd:50:ae:d1:7f:4f:e5:3b:ba:38:06:c4:26:ea:4b:02:30:
>  66:9d:a4:38:7e:45:ed:7d:db:7c:3e:f9:f7:68:80:e0:13:79:
>  8b:85:9c:5d:b6:29:91:73:59:04:6a:73:8e:bb:bb:15:49:cc:
>  68:63:25:b9:c6:fe:30:40:39:65:97:57
> 
> Both using the same EC secp384r1 key.
> 
> When I try to do the most (I think) basic openssl cms -encrypt, I get
> the
> same error.
> 
> openssl cms -encrypt -in in.txt -out encrypt.out test.pem
> openssl cms -encrypt -in in.txt -out encrypt.out -recip test.pem
> openssl cms -encrypt -in in.txt -out encrypt.out -recip test.pem -
> keyopt
> ecdh_kdf_md:sha256
> 
> with either of the certificates (email in DN or not), they all produce:
> 
> 11034533897704:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl
> failure:/usr/src/lib/libcrypto/cms/cms_env.c:124:
> 11034533897704:error:2EFFF074:CMS routines:CRYPTO_internal:error
> setting
> recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944:
> 11034533897704:error:2EFFF068:CMS routines:CRYPTO_internal:cms
> lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850:



However, if I do the same thing (create a basic, self signed RSA
certificate):

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
df:31:84:a5:79:b6:d4:7a
Signature Algorithm: sha384WithRSAEncryption
Issuer: C=US, ST=State, L=City, O=Org, OU=Home, CN=ad...@example.com
Validity
Not Before: May  8 13:18:17 2021 GMT
Not After : May  8 13:18:17 2022 GMT

openssl cms -encrypt does not work with EC key/cert

[Theodore Wynnychenko]

Hi

I posted this to the openssl user list the other day, but now think that was
the wrong place, since it is libressl on openbsd, right?

So, let me ask here:

Hello


I recently decided to change from RSA to EC keys/certs.
I do this primarily as a learning exercise (there is no real corporate or
professional demand to have this working).
I am running OpenBSD current (6.9) from about 1 month ago.


Previously, I have been using "openssl smime" to sign and encrypt emails.

Now that I am migrating to EC keys/certificates, I need to switch to
"openssl cms".

However, I am unable to encrypt using the EC certificate.

When I use:
(I am going to obfuscate the emails in plain text.)

cat text.in | /usr/bin/openssl cms -encrypt -from 'User
' -to 'Admin ' -subject "Test Email"
-aes256 encryption.pem > encrypted.out

with the old RSA certificate, everything works as expected.

But, when I replace the RSA cert with the EC certificate, it does not.
Instead, I see:

15724089243112:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl
failure:/usr/src/lib/libcrypto/cms/cms_env.c:124:
15724089243112:error:2EFFF074:CMS routines:CRYPTO_internal:error setting
recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944:
15724089243112:error:2EFFF068:CMS routines:CRYPTO_internal:cms
lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850:

And the output file is zero size.

I tried a more basic command:

openssl cms -encrypt -in text.in -out encrypted.out -recip encryption.pem

Works with RSA certificate, same error with EC certificate.

I also tried (not really understanding):

openssl cms -encrypt -in text.in -out encrypted.out -recip encryption.pem
-keyopt ecdh_kdf_md:sha256

and got the same error.

I then created some very basic self-signed EC certs.

The first, with an email in the DN, and the email as the CN:

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
cd:c8:e1:f4:f8:f7:32:dd
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, ST=State, L=City, O=Org, OU=Home,
CN=ad...@example.com/emailAddress=ad...@example.com
Validity
Not Before: May  6 17:19:53 2021 GMT
Not After : May  6 17:19:53 2022 GMT
Subject: C=US, ST=State, L=City, O=Org, OU=Home,
CN=ad...@example.com/emailAddress=ad...@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:8e:11:20:73:c8:8d:5d:61:43:c4:6b:bf:04:fe:
c6:5d:a8:22:79:ae:0a:eb:de:0b:67:e6:32:24:43:
30:56:61:0a:e6:31:e4:82:cc:a8:9c:37:e9:90:01:
df:e7:90:79:dc:d5:f1:c6:0c:6e:2f:bd:51:f8:98:
4e:4b:1b:16:52:73:73:d6:fd:1f:00:a1:f6:39:03:
98:3e:64:43:77:c3:c5:95:61:c3:22:05:3c:e6:d2:
86:29:e1:a3:9c:b9:32
ASN1 OID: secp384r1
NIST CURVE: P-384
Signature Algorithm: ecdsa-with-SHA384
 30:64:02:30:38:e0:dc:6d:2a:87:d0:a5:c8:9e:eb:c9:03:f6:
 fc:6d:aa:80:8c:cf:8d:11:15:70:ee:1b:b6:29:21:53:40:a4:
 3a:29:30:7d:5c:d5:ac:df:44:fc:a9:eb:a9:1a:b8:34:02:30:
 15:42:91:ae:e3:2d:b3:3b:bd:78:63:9d:89:1c:5f:28:5c:bb:
 c9:a0:01:6a:31:84:94:e0:e7:45:73:0a:51:84:0e:0b:79:a8:
 04:eb:62:5b:71:cf:c8:6a:d1:86:3d:e6


The second with the CN as the email, but no email in the DN:

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
e5:fd:15:21:f1:b2:71:de
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, ST=State, L=City, O=Org, OU=Home, CN=ad...@example.com
Validity
Not Before: May  6 17:18:43 2021 GMT
Not After : May  6 17:18:43 2022 GMT
Subject: C=US, ST=State, L=City, O=Org, OU=Home,
CN=ad...@example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:8e:11:20:73:c8:8d:5d:61:43:c4:6b:bf:04:fe:
c6:5d:a8:22:79:ae:0a:eb:de:0b:67:e6:32:24:43:
30:56:61:0a:e6:31:e4:82:cc:a8:9c:37:e9:90:01:
df:e7:90:79:dc:d5:f1:c6:0c:6e:2f:bd:51:f8:98:
4e:4b:1b:16:52:73:73:d6:fd:1f:00:a1:f6:39:03:
98:3e:64:43:77:c3:c5:95:61:c3:22:05:3c:e6:d2:
86:29:e1:a3:9c:b9:32
ASN1 OID: secp384r1
NIST CURVE: P-384
Signature Algorithm: ecdsa-with-SHA384
 30:64:02:30:3f:06:2c:b1:e1:2f:b1:0b:1e:a1:1a:eb:29:1e:
 8c:e5:c4:6a:73:f5:43:4e:24:77:88:bf:b1:99:51:15:02:50:
 12:cd:50:ae:d1:7f:4f:e5:3b:ba:38:06:c4:26:ea:4b:02:30:
 66:9d:a4:38:7e:45:ed:7d:db:7c:3e:f9:f7:68:80:e0:13:79:
 8b:85:9c:5d:b6:29:91:73:59:04:6a:73:8e:bb:bb:15:49:cc:
 68:63:25:b9:c6:fe:30:40:39:65:97:57

Both using the same EC secp384r1 key.

When I try to do the most (I think) basic openssl cms -encrypt, I get 

Re: How I got iked in -current to work with iOS

[Theodore Wynnychenko]

Hello - I have added a small bit of additional information at the end.

-Original Message-
From: Theodore Wynnychenko
Sent: Friday, April 02, 2021 1:46 PM
To: misc@openbsd.org
Subject: How I got iked in -current to work with iOS

Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about
3/28/2021) to work with Apple's iOS (iphone/ipad's) version (about)
14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS
devices will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use
ikectl to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer
than the Apple limit.  Therefore, I needed to have a CA certificate, and
TLS certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 20190101" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary
is to add "-startdate 2019010200Z" to the openssl ca command when
signing the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited
out many things in the actual file I used, but I THINK what is left is all
that may be really needed, but my openssl knowledge is not absolute, and I
may have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not
use them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits= 4096
default_keyfile = key.pem   
default_md  = sha384
string_mask = utf8only
distinguished_name  = req_distinguished_name
attributes  = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, openssl.cnf:

basicConstraints

Re: How I got iked in -current to work with iOS

[Theodore Wynnychenko]

Hello - I have added a small bit of additional information at the end.

-Original Message-
From: Theodore Wynnychenko [mailto:t...@uchicago.edu] 
Sent: Friday, April 02, 2021 1:46 PM
To: misc@openbsd.org
Subject: How I got iked in -current to work with iOS

Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about
3/28/2021) to work with Apple's iOS (iphone/ipad's) version (about)
14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS
devices will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use
ikectl to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer
than the Apple limit.  Therefore, I needed to have a CA certificate, and
TLS certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 20190101" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary
is to add "-startdate 2019010200Z" to the openssl ca command when
signing the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited
out many things in the actual file I used, but I THINK what is left is all
that may be really needed, but my openssl knowledge is not absolute, and I
may have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not
use them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits= 4096
default_keyfile = key.pem   
default_md  = sha384
string_mask = utf8only
distinguished_name  = req_distinguished_name
attributes  = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, opens

How I got iked in -current to work with iOS

[Theodore Wynnychenko]

Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about 3/28/2021)
to work with Apple's iOS (iphone/ipad's) version (about) 14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS devices
will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use ikectl
to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer than
the Apple limit.  Therefore, I needed to have a CA certificate, and TLS
certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 20190101" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary is
to add "-startdate 2019010200Z" to the openssl ca command when signing
the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited out
many things in the actual file I used, but I THINK what is left is all that
may be really needed, but my openssl knowledge is not absolute, and I may
have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not use
them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits= 4096
default_keyfile = key.pem   
default_md  = sha384
string_mask = utf8only
distinguished_name  = req_distinguished_name
attributes  = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, openssl.cnf:

basicConstraints= CA:TRUE
subjectKeyIdentifier= hash
authorityKeyIdentifier  = keyid:always,issuer:always
issuerAltName   = issuer:copy

For the TLS certs, when creating the signing request, openssl.cnf:

basicConstraints= CA:FALSE
subjectKeyIdentifier= hash
authorityKeyIdentifier  = keyid:always,issuer:always
subjectAltName  = email:move

F

iked in -current with Apple iOS 14

[Theodore Wynnychenko]

Hello
After avoiding this for a couple of years, I just spent a lot of time
figuring out how to get iked in -current to play with Apple iOS 14 (most
recent version).

I had been limping along by replacing iked in current with an older version,
but Apple has made iOS ikev2 more and more restrictive, so I finally decided
to upgrade.

I now have iked using ECDSA384 certificates working with my iPhone (also
with ECDSA384 certificates).

I am sending this note to see if it would be of help to send a detailed
accounting of how this was done to the list.

It is a bit convoluted (especially if you want to use certificates that will
live longer than about 13 (or 26) months - a new limitation from Apple).

If my process for this would be helpful to others, please let me know, and I
will type something up in the next week or two.

Ted
 

Icinga2 endpoints unable to connect to master after update to current package 2.12.1-1

[Theodore Wynnychenko]

Hello

The other day I updated to current (6.8 GENERIC.MP#188).

I then updated packages.

I have been using Icinga2 since about OpenBSD 5.6, and everything was fine.

A few hours after the update, I got a warning that my /var/log filesystem on
the icinga2 master was full.

Then, I noticed warnings in icinga2 for pretty much every check that state:

"Error: Function call 'pipe2' failed with error code 24, 'Too many
open files'"

I only have a couple of dozen endpoints, and have never had this issue
before.  I tried increasing the file limits, but that only increased the
time before icinga2 crashed into the limit with too many open files.

I then noticed that icinga2 was now throwing a warning about self signed
certificates.

Specifically, I was getting log messages on the endpoints "New client
connection for identity 'master.my.tld' to [172.xx.xx.99]:5665 (certificate
validation failed: code 19: self signed certificate in certificate chain)".

On the master, I was getting the same, but inverted, error:  "New client
connection for identity 'endpoint.my.tld' from [172.xx.xx.1]:3621
(certificate validation failed: code 19: self signed certificate in
certificate chain)".

So, I decided to add the icinga CA certificate to the list of trusted
certificates in /etc/ssl/cert.pem on both master and endpoint.

Now, when I connect (either from master to endpoint, or the reverse) using
s_client, I see:

openssl s_client -connect endpoint.my.tld:5665

CONNECTED(0003)
depth=1 CN = Icinga CA
verify return:1
depth=1 CN = Icinga CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
depth=1 CN = Icinga CA
verify return:1
depth=0 CN = endpoint.my.tld
verify return:1
depth=0 CN = endpoint.my.tld
verify return:1
write W BLOCK
---
Certificate chain
 0 s:/CN=endpoint.my.tld
   i:/CN=Icinga CA
 1 s:/CN=Icinga CA
   i:/CN=Icinga CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIFAjCCAuqgAwIBAgIUZuaLfnjnY6dLkKTQ3J6GGGcCYnowDQYJKoZIhvcNAQEL
BQAwFDESMBAGA1UEAwwJSWNpbmdhIENBMB4XDTE4MDUxNjE2MzQzN1oXDTMzMDUx
MjE2MzQzN1owJzElMCMGA1UEAwwccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNv
bTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJzPMaQdWkhb/YMy242C
jmbRVcwOqZrCRPwscYhAfhfSwNJfSN7k5I9UCFszgvAU3QU3RhEElrJYOQY7UKp1
V7D4MO88S5NMh6rLrjyCuojxVnbwCA4WwIXMA0zNY6EEG8/1LbcfA8utSy1Y1X0c
xb4FJKv3ar02j9A5XleZf0p9bKQezysxB3TT17L4AhWsoE1w/7GCfU715OEch+Dw
WI9TusrJXKLFwHvk1j+ZCjiNM49F7gFDpw3m/Asekt5B3M6L7ZkPM9jI1ThX4etj
kEC1C2371lP9OdFExqScLudHCL8+2IILd3i+/7YxWFTnxhFszyWMDiMll/omcpot
qDbFhQdVrfnTo4lczK42EfhQuDMdESkmvay8UVGyUe90AEaQ38V3w8B0iDzgGQTX
UZNxpurotW2zU1XPhzTOawRlp1POFQ1tnFJzH+iyBCxZZZfZsQchJbMJz/JCGIiW
qkhTN5bAKoAgO6GglTmqktSZmixa38fZ8qIJ8Y0UZsnH5zRQWcbzKr49u3FhH2rH
pC9Dh+zlRj/LiMM4c/UF2LzwuIQ3fjZMEff+q3vzs6cXgs8FICX7uvpB4yqqt4Vn
/ZSRrq++dUAav+0JhTYlW2m+sa/ga4HVAB+zNN7+l92PWSJ0b3DDzZt6CHLp/lWX
zCPDpo7ABbk+xrg+NEoym8ejAgMBAAGjOTA3MAwGA1UdEwEB/wQCMAAwJwYDVR0R
BCAwHoIccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNvbTANBgkqhkiG9w0BAQsF
AAOCAgEAGh1goJVNy4Ltpv0+x1okod55g7ob6/l2hAwrq0jXBca4zIGncQcdl0jg
+z6TDMiq+2UUoKB80k5D947t2VHtp+d/wuSTNwpzESNplh5GWpqkdpOHcAN1lkku
ZgCUnQH/ZFa4Q2V01rPHSaf1znMpaqaYTjAKwNwZY9qRxjXUZg62/D/y9pfmy+VC
yvZype5rETXjLxr0WN6LABRgda41wiLszMWLAonHRHRVkhdyUYC+brmDNhfByqGJ
L5oHpvCq9Oywk4zKO02y3wrhL1+JHt0TH/5RmaalWQRsB0vJY9699cnLk6DK/+CD
YyHecKplsnwnfvwau6aMlwg6zilCZ+YMl3Jwj0vQeG/h8DyTw6t9HtknlnRfcfQ/
eyTHZtdyH1y1O5v4BQJNt5Ewc7y144IP2g/9Y7g3n7GFlvd68TQjJmI6I4nGsJ+u
iNu+DGzD6Ih9UhFCWMrR57r9utdarBWYV4NJaXldNnqXrL099Hu3CLzdjikabeHE
J56gkXOHQdQi2xIyIgIuMHMF+niJkqAmxyGaMfnBOOv6Gvt7TAMLrt4dIFSgomKe
Rd6xSyCh66H/AYF8b4NlwVCjDmvQf31OtGrl8xVlXDnOeaUHoZsu/ECO9f7E5yuN
od5dNX4mJoSCkESbwQ67IumOLxSEw5extwTNplG/oEqgl6YalJI=
-END CERTIFICATE-
subject=/CN=endpoint.my.tld
issuer=/CN=Icinga CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3436 bytes and written 392 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
AF10B5FA058B109699E87151A6BFCE6E9AD4968C04F6E8C1EFE24C8830AE7D5F
Session-ID-ctx:
Master-Key:
6509DF9A604E5FB4C7F3BD55DC4666FDD93315CA00AA8E373E8C41BD93E3E1D91961AEA35642
A684F45DA530C4FDF260
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - b1 ef 85 f6 29 57 ee 81-8f d7 af 12 de 8e 19 1e
)W..
0010 - c4 3d b8 5d 68 1e d0 87-9a 88 09 b8 e5 b8 fd 7d
.=.]h..}
0020 - 6e 48 ea 63 5f df 83 54-9a d3 b4 3e e6 3a 30 a4
nH.c_..T...>.:0.
0030 - 83 0b df 4d 3e 7b da a2-47 a0 c2 2b 2c 4e 4e f6
...M>{..G..+,NN.
0040 - f3 b5 6c 24 da 6a f1 c8-bf 27 08 23 1e 37 21 9a
..l$.j...'.#.7!.
0050 - 93 dd 87 a5 95 b8 72 3c-14 07 33 a1 e4 23 b7 2d
..r<..3..#.-
0060 - 16 0e b8 ad c4 f9 be 72-a0 44 1f 09 c9 47 47 8a
...r.D...GG.
0070 - a6 97 10 55 77 a3

Guidance: How often to update -current?

[Theodore Wynnychenko]

Hello
I have been following -current since (about) 5.6.
At first, I was pretty good.  Probably no more than about 1 month between
updates.
But, life gets in the way...
Recently, I had a prolonged (probably >4-6 month) period where I did not
update, although I have recovered.
Since then, I have been reasonably good, I think.  No more than 2 months
between updates.
This last one seemed not to have too many changes/things I needed to deal
with, and went quickly.

But, this got me thinking (I am better with schedules):  What is a
reasonable amount of time between updates of -current?

I think if I have a firm time limit in my head, I would be better able at
sticking to it.
Just looking for opinions.

Thanks
Ted

Re: Courier-Imap no longer accepts ssl connections after update to -current

[Theodore Wynnychenko]

Yes, it is (was) a permission issue. 

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Giovanni Bechis 
> Sent: Sunday, November 03, 2019 5:22 AM 
> To: misc@openbsd.org 
> Subject: Re: Courier-Imap no longer accepts ssl connections after 
> update to -current 
> 
> Theodore Wynnychenko  wrote: 
> > Hi (again): 
> > 
> > After updating to current yesterday, and then updating all the 
> packages 
> > (using "pkg_add -vui -Dsnap"), I can no longer connect to the ssl 
> (993) port 
> > of the courier-imap server running on the system. 
> > 
> > Prior to the update, ssl connections were working without an issue. 
> > 
> it's working fine for me with: 
> $ ldd /usr/local/bin/couriertls | grep ssl 
> 11ae13a38000 11ae13a9c000 rlib  01   0 
> /usr/lib/libssl.so.48.0 
> and 
> OpenBSD 6.6-current (GENERIC.MP) #425: Fri Nov  1 23:49:35 MDT 2019 
> 
I updated this AM to be sure: 

OpenBSD 6.6-current (GENERIC.MP) #427: Sat Nov  2 13:23:11 MDT 2019 

# ldd /usr/local/bin/couriertls | grep ssl 
113249966000 1132499ca000 rlib  01   0
/usr/lib/libssl.so.48.1 

But, I kept getting the error and no connection: 
# openssl s_client -connect 127.0.0.1:993 
CONNECTED(0003) 
11102104709736:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl
handshake failure:/usr/src/lib/libssl/ssl_pkt.c:585:


I then compared to prior (6.5) working courier package with the -current
one. 
When I compared /usr/local/libexec/imapd-ssl.rc (and pop3d-ssl.rc), I
noticed the addition of: 
> 
56a62 
>   -user=_courier \ 

So, it seems that before the last update, couriertls ran as root, and now it
runs as _courier. 

I completely understand the desire to drop root.  But, in my case, my
private cert was in /etc/ssl/private. 

drwx--   2 root  wheel  512B Nov  2 14:00 private 
and: 
-rw---   1 root  wheel   6.2K Dec 17  2016 imapd.pem 

So, this was the issue for me. 

I did not want to disrupt the structure of my ssl private keys too much, so
I just made a second "private" directory for courier.

drwx--   2 _courier  _courier   512B Nov  3 17:17
private-courier 
Put a copy of the file there. 
-rw---   1 _courier  _courier   6.2K Nov  3 17:09 imapd.pem 

And updated the /etc/imap-ssl configuration: 

TLS_CERTFILE=/etc/ssl/private-courier/imapd.pem 
TLS_DHPARAMS=/etc/ssl/private-courier/imapd.pem 

This fixed my issue (did the same for the pop3-ssl configuration). 

I reviewed my notes from when I installed this (back around 5.5-5.6 - I did
not realize I was following -current for so long), and did not see a note
that couriertls required the private key to be non-root readable.

Also, the current README/config file does not inform that the cert file must
now be readable by _courier, it only indicates that it "must not be
world-readable."

I am posting this here in case someone else runs into a similar issue. 

Thanks again for pointing me in the right direction. 
Ted 

Re: Following current - pkg_add update forward depedencies don't match question

[Theodore Wynnychenko]

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Stuart Henderson 
> Sent: Sunday, November 03, 2019 7:59 AM 
> To: misc@openbsd.org 
> Subject: Re: Following current - pkg_add update forward depedencies 
> don't match question 
> 
> On 2019-11-02, Theodore Wynnychenko  wrote: 
> > I decided to just try updating gettext, so (this is the full output 
> on that 
> > system): 
> 
> Well, that's the problem. Partial updates work sometimes but they can't 
> be relied upon, in particular won't work around some types of 
> restructuring 
> changes as happened to the gettext port. 
> 

I tried running 'pkg_add -u' (not as a partial update) probably 5-10 times,
always getting the same 'forward dependencies don't match' notice, and
pkg_add ending with the notices:

Couldn't find updates for ... gettext-0.19.8.1p3 ... (and all the other
'don't match' packages) 
Couldn't install gettext-runtime-0.20.1p0 ... (and all the other 'don't
match' packages) 


> Flavours are after the version number (mutt-1.12.2v3-gpgme: this is the 
> "gpgme" flavour of mutt). 
> 
> gettext was split into multiple parts (runtime, tools, and 
> libtextstyle) 
> in separate packages and there is no more package just named "gettext". 
> Say you have A+B installed and want to update them, both use gettext. 
> A(old)+B(old) depend on gettext; A(new)+B(new) depend on gettext- 
> runtime. 
> gettext and gettext-runtime contain same files so can't be installed 
> together. Therefore you can't update A(old) to A(new) without also 
> updating B(old) to B(new). 
> 

In my case, pkg_add -u did not succeed regardless of whether or not it was a
complete update. 

> > Now, I really have little idea of what this means, or what I am 
> doing, but I 
> > decided I would just manually "fix" the @depend line in my local 
> > "/var/db/pkg/[package]/+CONTENTS" to the "new" line (with 
> > "gettext-runtime-0.20.1p0" in it). 
> 
> That probably didn't cause any big problems in this case, but I just 
> want 
> to make sure that it's showing in the thread for the list archives: 
> don't 
> do that :-) 
> 

I agree that it did not seem like the best idea (a little knowledge is a
dangerous thing).  When I was thinking about it, I thought of deleting
gettext (so that I could install gettext-runtime), but that seemed to lead
to a lot of other required package deletions, and I was worried that
something would break.

I could not figure out how to get one package (in this case, getext) to be
deleted, for just a few minutes, so that I could install gettext-runtime
without being forced to accept the deletion of a bunch of other packages.

Is there a way to do something like that?   I could not find one. 


> I would suggest running pkg_check now for a sanity check of the package 
> database. 
> 

Did that immediately after the update - I guess I got something right :-) 
Thanks again 
Ted 

Courier-Imap no longer accepts ssl connections after update to -current

[Theodore Wynnychenko]

Hi (again): 

After updating to current yesterday, and then updating all the packages
(using "pkg_add -vui -Dsnap"), I can no longer connect to the ssl (993) port
of the courier-imap server running on the system.

Prior to the update, ssl connections were working without an issue. 

Now, when trying to connect, the client gets a "A secure connection to the
server cannot be established" message. 

On the server, I see the following in the log for each ssl connection
attempt: 

Nov  2 07:40:38 host imapd-ssl: ip=[:::127.0.0.1], couriertls:
/etc/ssl/private/imapd.pem: error:02FFF00D:system
library:func(4095):Permission denied

Nov  2 07:40:38 host imapd-ssl: ip=[:::127.0.0.1], couriertls:
/etc/ssl/private/imapd.pem: error:20FFF002:BIO
routines:CRYPTO_internal:system lib

The packages for courier currently installed are: 

pkg_info | grep courier 
courier-authlib-0.69.1  authentication library for courier 
courier-authlib-mysql-0.69.1mysql authentication module for
courier-authLib 
courier-imap-5.0.8  imap server for maildir format mailboxes 
courier-pop3-5.0.8  pop3 server for maildir format mailboxes 
courier-unicode-2.1 courier unicode library 

I did not make any changes to the /etc/courier/imapd-ssl configuration file.
What was working for me before was: 
cat imapd-ssl |grep -v ^$ | grep -v ^# 
SSLPORT=993 
SSLADDRESS=0 
MAXDAEMONS=500 
MAXPERIP=100 
SSLPIDFILE=/var/run/courier/imapd-ssl.pid 
SSLLOGGEROPTS="-name=imapd-ssl" 
IMAPDSSLSTART=YES 
IMAPDSTARTTLS=NO 
IMAP_TLS_REQUIRED=0 
COURIERTLS=/usr/local/bin/couriertls 
TLS_CERTFILE=/etc/ssl/private/imapd.pem 
TLS_DHPARAMS=/etc/ssl/private/imapd.pem 
TLS_TRUSTCERTS=/etc/ssl/CA/cacert.pem 
TLS_VERIFYPEER=NONE 
MAILDIRPATH=Maildir 

Anyway, I don't know what the error lines really mean.  I am wondering if it
is something do with the "interface" between courier and the ssl libraries.
I have tried "exploring" the web on this over the last 24 hours, but have
been unable to find anything to point me in any direction.

As this is an "internal" mail-server, I just re-enabled the non-ssl
connection, so I can still connect to my mail. 

But, I am wondering if there is anything that I could do to resolve this
ssl-connection issue. 

Thanks (again) 
Ted 

Re: Following current - pkg_add update forward depedencies don't match question

[Theodore Wynnychenko]

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Stuart Henderson 
> Sent: Saturday, November 02, 2019 4:12 AM 
> To: misc@openbsd.org 
> Subject: Re: Following current - pkg_add update forward depedencies 
> don't match question 
> 
> On 2019-11-01, Theodore Wynnychenko  wrote: 
> > Hello 
> > 
> > I just updated a system to current the other day. 
> > 
> > OpenBSD 6.6 GENERIC.MP#411 amd64 
> > 
> > The last time I updated was probably 2-3 months ago. 
> > 
> > Anyway, when I went to updated packages (also following 
> current/snapshots), 
> > I got a number of "forward dependencies - don't match" notices and 
> the 
> > packages don't update. 
> 
> What command are you running to update? 
> 
> The "don't match" are expected but (at least with "pkg_add -u" without 
> restricting to a subset of packages) it shouldn't stop packages from 
> updating anyway. 
> 
> Can you show the pkg_add command line you're using and complete output? 
> i.e. run it under script(1) and send the typescript. 
> 
> This doesn't match "probably 2-3 months ago", php 5.6 and the 
> associated 
> pecl packages were removed before 6.5, and php-7.1.27 was from 
> somewhere 
> between 6.4 and 6.5. Not that this matters in itself, an update over 
> that time period would still be expected to work, but if you're 
> going to be updating infrequently you should definitely stick to 
> releases+syspatch rather than -current. 
> 

Sorry, it was probably longer than "2-3 months."  Life got in the way.  I
should do better going forward, and I understand that going "back" to
release from current can be problematic.

In any case, I wanted to describe my "experience" with this issue.  I will
try to be brief. 
Yesterday afternoon, I noticed that the timestamps for packages had updated.

So, I tried again (on another system where "breaking" is less
consequential). 

I decided to just try updating gettext, so (this is the full output on that
system): 

# PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/
pkg_add -u -Dsnap gettext 

quirks-3.184 signed on 2019-11-01T17:28:51Z 
.libs1-gettext-0.19.4p0+gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward

dependencies: 
| Dependencies of python-2.7.16 on gettext-* don't match 
| Dependencies of python-3.6.8p0 on gettext-* don't match 
| Dependencies of libidn-1.35 on gettext-* don't match 
| Dependencies of glib2-2.58.3p8 on gettext-* don't match 
| Dependencies of wget-1.20.2 on gettext-* don't match 
| Dependencies of libpsl-0.20.2 on gettext-* don't match 
| Dependencies of libgpg-error-1.36 on gettext-* don't match 
| Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match 

Merging python-2.7.16->2.7.16p1 (ok) 
NOT MERGING: can't find update for [python-3.6.8p0] (ok) 
Merging libidn-1.35->1.35p0 (ok) 
Merging glib2-2.58.3p8->2.60.7 (ok) 
Merging wget-1.20.2->1.20.3p1 (ok) 
Merging libpsl-0.20.2->0.20.2p0 (ok) 
Merging libgpg-error-1.36->1.36p0 (ok) 
Merging monitoring-plugins-2.2p7->2.2p8 (ok) 
Proceed with update anyway ? [y/N/a] y 
Detected loop, merging sets ok 
| python-3.7.5 
| 
.libs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+

libidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2

->gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+li

bpsl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+wget-1.20.3p1 
[python-3.6.8p0].libs-glib2-2.56.1+.libs-libidn-1.34+.libs-libpsl-0.7.1p1+.l

ibs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+li

bidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2->

gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+libp

sl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+python-3.7.5+wget-1.20.

3p1 forward dependencies: 
| Dependencies of python-3.6.8p0 on gettext-* don't match 
Proceed with update anyway ? [y/N/a] y 
Can't install 
[python-3.6.8p0].libs-glib2-2.56.1+.libs-libidn-1.34+.libs-libpsl-0.7.1p1+.l

ibs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+li

bidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2->

gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+libp

sl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+python-3.7.5+wget-1.20.

3p1: can't resolve gettext-* 
Couldn't find updates for .libs-glib2-2.56.1 .libs-libidn-1.34 
.libs-libpsl-0.7.1p1 .libs1-gettext-0.19.4p0 gettext-0.19.8.1p3 
glib2-2.58.3p8 libgpg-error-1.36 libidn-1.35 libpsl-0.20.2 
monitoring-plugins-2.2p7 python-2.7.1

Following current - pkg_add update forward depedencies don't match question

[Theodore Wynnychenko]

Hello 

I just updated a system to current the other day. 

OpenBSD 6.6 GENERIC.MP#411 amd64 

The last time I updated was probably 2-3 months ago. 

Anyway, when I went to updated packages (also following current/snapshots),
I got a number of "forward dependencies - don't match" notices and the
packages don't update.

For example: 

gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies: 
| Dependencies of php-apache-7.1.27p0 on gettext-* don't match 
| Dependencies of gnupg-1.4.23p1 on gettext-* don't match 
| Dependencies of glib2-2.58.3p8 on gettext-* don't match 
| Dependencies of courier-imap-4.18.2p0 on gettext-* don't match 
| Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match 
| Dependencies of libgpg-error-1.36 on gettext-* don't match 
| Dependencies of python-3.6.8p0 on gettext-* don't match 
| Dependencies of samba-4.8.9 on gettext-* don't match 
| Dependencies of gdbm-1.16 on gettext-* don't match 
| Dependencies of popt-1.16p1 on gettext-* don't match 
| Dependencies of aspell-0.60.6.1p8 on gettext-* don't match 
| Dependencies of libpsl-0.20.2 on gettext-* don't match 
| Dependencies of wget-1.20.2 on gettext-* don't match 
| Dependencies of php-7.1.27 on gettext-* don't match 
| Dependencies of libidn-1.35 on gettext-* don't match 
| Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match 
| Dependencies of python-2.7.16 on gettext-* don't match 
| Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match 
| Dependencies of fetchmail-6.3.26p2 on gettext-* don't match 
| Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match 
| Dependencies of p11-kit-0.23.15p0 on gettext-* don't match 

When I check: 
# pkg_info  | grep gettext 
gettext-0.19.8.1p3  GNU gettext runtime libraries and programs 

And the mirror shows: 
gettext-runtime-0.20.1p0.tgz 

Or (another example), with similar notices about forward dependencies not
matching: 
# pkg_info  | grep php-7 
php-7.1.27  server-side HTML-embedded scripting language 

And the mirror shows: 
php-7.1.32.tgz 

I see that I can "force" the update with "pkg_add -u -D updatedepends". 

It seems like this should be safe to do, but it's not something I have done
before. 

While my system isn't "production" for a large multi-national, I do use it
as a file server and stuff, and it is working right now, and I don't want to
make it not work.

So, before I did this, I was wondering if there was anything I should
consider/do to address this issue, other than just "forcing" the update?

I guess, when at its core, I don't really completely understand what the
notice means, and how and why it happened. 

Thanks 
Ted 

Re: Adding an additional IP on a NIC getting DHCP address

[Theodore Wynnychenko]

Hello 

This is the first time I am responding to a post that is not my mine.  I hope 
it is not too uninformed. 

Anyway, back in about October, 2016, I noticed that the included dhcp client 
would no longer assign an alias address alongside the address from the dhcp 
lease.  Before about this time, I seem to recall, it would.

My solution was to use the isc-dhcp-client from ports.  But, that also had some 
issues. 

My solution (and if it is a poor solution, sorry) is on the mailing list at: 

https://marc.info/?l=openbsd-misc 
 
&m=147638874608453&w=2 

It is working as expected through my last update of current, which was about 2 
months ago. 

Ted 


> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Lars Bonnesen 
> Sent: Friday, March 22, 2019 5:06 AM 
> To: misc@openbsd.org 
> Subject: Adding an additional IP on a NIC getting DHCP address 
> 
> The NIC hostname file contains: 
> 
> dhcp 
> 
> and it configures the nic with a DHCP address and configure mygate 
> according to this. 
> 
> Now I need to add an additional static IP on top of this and use the 
> static 
> IP address gateway address (thus not configuring myname from DHCP) 
> 
> Can I just add inet x.x.x.x b.b.b.b to myname so that it reads: 
> 
> dhcp 
> inet x.x.x.x b.b.b.b 
> 
> and if so, how do I make sure that mygate does not get overwritten from 
> dhcp? 
> 
> Regards, Lars. 

Re: TLS suddenly not working over IKED site-to-site - SOLVED?

[Theodore Wynnychenko]

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of William Ahern 
> Sent: Monday, December 17, 2018 1:11 PM 
> To: Theodore Wynnychenko 
> Cc: misc@openbsd.org 
> Subject: Re: TLS suddenly not working over IKED site-to-site 
> 
. 
. 
. 
> I'm not well versed in these issues but if I were in your shoes I would 
> 
> 1) Figure out why those packets were unprotected. (Could be normal for 
> all I 
> know, but in a quick test on my enc0 I didn't see any packets like 
> that.) 
> 
> 2) Make sure the tunnel handles fragmentation correctly. Are fragments 
> being 
> dropped? Are reassembled fragments being dropped? 
> 
> 2.a) Relatedly, make sure the tunnel handles pMTU discovery. Do ICMP 
> Fragmentation Needed packets make it back through the tunnel? pMTU and 
> ICMP 
> issues are very common with IPSec tunnels. IME most people "fix" these 
> issues by forcing a lower MSS or setting a lower MTU at the ingress 
> point 
> rather than properly configuring routing so ICMP errors are properly 
> routed. 
> I've experienced this issue myself and had to learn the hard way. 
> 
> 3) From an earlier post it looks like you're using ipcomp. You should 
> remove 
> this complication while debugging. It's possible ipcomp is hiding MTU 
> issues. 


Thank you so much for the suggestions. 

To summarize, I have noticed that in the last month, SSL/TLS connections were 
failing when traversing an ipsec tunnel created by iked.

This had worked stably for over a year, with no changes to iked.conf or 
pf.conf. 

In trying to find the issue, I had added "max-mss" to pf and tried decreasing 
MTU values on the adapters.  This did not seem to make a difference.

In addition, the problem was very sporadic, and seemed to "evolve" over the 
last few weeks.  In the last few days, I was able to establish https 
connections over the tunnel when that connection was initiated by the gateway 
openbsd machine or a Mac on the "local" network; but connections from another 
openbsd machine "behind" the gateway, and a Windows 7 machine kept hanging.

Anyway, I decided to revert everything to the way it was.  I removed all 
"max-mss" entries and reset MTU values to 1500.

Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, 
https (and imaps) were working without an issue from openbsd, Windows 7, and 
Macs!

Just to be sure, I updated this am to the 12/19 amd64 snapshot. 

When I turn on ipcomp, https/imaps hangs for most connections; when I turn 
ipcomp off, https/imaps works. 

I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this 
is the code that is involved) in the log (I think) was about 3 months ago, and 
at this point, I can't recall if my last updated (prior to the one where the 
instability began) was before or after that change.

I was going to try to recompile it with the change undone, but am not sure how 
to do that, or even if it can be done for just that one part of sys.

And, after removing ipcomp from iked.conf, my subjective observation is that 
things load a lot faster than they seemed to in the past with ipcomp on; so, I 
am happy with where I am.

I was just posting my observations in case anyone else has a similar issue. 

Ted 

Re: TLS suddenly not working over IKED site-to-site

[Theodore Wynnychenko]

Hello again: 

I updated my iked endpoints to the most recent (12/14/18) amd64 snapshot today, 
and am still having problems with secure connections.

So, today, I am just looking at the gateway machines. 

The iked vpn tunnel gets established without an issue. 

# ipsecctl -s all 
FLOWS: 
flow esp in from xx.xx.xx.xx to 172.30.1.20 peer xx.xx.xx.xx srcid FQDN/x.x.x 
dstid FQDN/x.x.x type use 
flow ipcomp in from 172.30.6.0/23 to 172.30.0.0/22 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type use 
flow ipcomp out from 172.30.0.0/22 to 172.30.6.0/23 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type require 
flow esp out from 172.30.1.20 to xx.xx.xx.xx peer xx.xx.xx.xx srcid FQDN/x.x.x 
com dstid FQDN/x.x.x type require 

SAD: 
ipcomp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x54ab comp deflate 
ipcomp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0x8bf1 comp deflate 
esp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x0934ef93 auth hmac-sha2-256 
enc aes-256 
esp transport from xx.xx.xx.xx to 172.30.1.20 spi 0x29a95d18 auth hmac-sha2-256 
enc aes-256 
esp transport from 172.30.1.20 to xx.xx.xx.xx spi 0x7b90f84c auth hmac-sha2-256 
enc aes-256 
esp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0xa9238cfb auth hmac-sha2-256 
enc aes-256 


I have also added "set skip on { lo enc0 }" to pf.conf on both gateways (trying 
to take that out of the equation). 


If, on the remote gateway I run: 
# nc -l https 

Then, when, on the local gateway I run: 
# nc remote.gateway https 
(( and enter "some text" and  )) 

On the remote gateway I see: 
"some text" 

OK, traffic is flowing from one to the other and allowed on https.  Right? 

If I run s_server on the remote gateway: 
# openssl s_server -state -accept https -CAfile /etc/ssl/cert.pem -cert 
/etc/ssl/server.crt -key /etc/ssl/private/server.key

The s_server starts: 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 

When I try connecting with s_client on the local gateway: 
# openssl s_client -state -connect remote.gateway:https 

All I see is: 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 


And there is no output on the server side (the remote gateway). 

At the same time, tcpdump of enc0 shows: 

On the local gateway: 

17:37:00.199269 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.235313 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.235335 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:00.236086 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:01.726509 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:04.726571 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:07.777123 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.820525 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)

17:37:10.726697 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: FP 1:197(196) ack 1 win 256  (encap)

17:37:11.724643 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: F 1:1(0) ack 1 win 271  (DF) (encap)

17:37:11.724680 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 2 win 256  (encap)

17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) 
(encap)


But, tcpdump of enc0 on the remote gateway only shows: 

17:37:00.207517 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.207551 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.244461 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:07.792702 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)


Needless to say, if I try these connections WITHOUT traversing the iked vpn, 
the openssl s_client to s_server connection works as expected.

Not being in any way an expert on these things, I cannot understand why 
"regular" tcp packets are able to traverse the VPN and emerge on the other 
side, while tcp pakets to the same port attempting to establish a secure 
co

Re: TLS suddenly not working over IKED site-to-site

[Theodore Wynnychenko]

I would like to re-title this as something like "pf and iked instability on 
recent snapshots," but don’t know if doing so would break the mailing list 
thread, exiso, I left the subject unchanged...

> -Original Message----- 
> From: Theodore Wynnychenko [mailto:t...@uchicago.edu] 
> Sent: Saturday, December 08, 2018 4:03 PM 
> To: misc@openbsd.org 
> Cc: 'Rachel Roch' 
> Subject: RE: TLS suddenly not working over IKED site-to-site 
> 
> > 
. 
. 
. 
> I now find I can no longer connect to with TLS/SSL over the iked tunnel 
> (the original behavior that seemed to have corrected itself).  Also, 
> icinga continues to be unable to verify the status of the remote hosts 
> over port 5665. 
> 
> I don't have time right now to try using s_client and s_server and 
> watching enc0 to see what is happening, but I will when I can. 
> 
> If anyone has an ideas on what may be happening, please let me know. 
> 
> Thanks 
> Ted 


Hello again; 

So, I am at a complete loss to understand what is going on. 
Today, I tried using openssl s_client and s_server to make a connection through 
the iked vpn (as I described in my last post).  However, with NO changes to 
iked.conf or pf.conf, today I had several connection attempts that completed 
correctly.  I have not included any output from those sporadic, completely 
functional connections.

Rather, today, most of the connections by s_client are not even acknowledged by 
the s_server on the other side of the iked vpn.

For example: 
On the s_client machine: 

# openssl s_client -state -connect "remote.host":https 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
... and nothing more ... 

But on the s_server machine today all I see is: 
# openssl s_sever -state -accept https ...certificate options... 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
... and no connection attempt is ever acknowledged ... 

(Yesterday, at least this first part of the connection was received by the 
s_server: 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
SSL_accept:before/accept initialization 
... and nothing more yesterday ...) 


So, today using tcpdump on the outgoing interface of the s_client machine and 
the incoming interface of the "local" iked vpn endpoint shows:

16:43:05.107524 172.30.1.254.7305 > 172.30.7.205.443: S 
1751796302:1751796302(0) win 16384 

16:43:05.149146 172.30.1.254.7305 > 172.30.7.205.443: . ack 2119500805 win 256 


16:43:05.149895 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:06.648487 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:09.648557 172.30.1.254.7305 > 172.30.7.205.443: P 0:196(196) ack 1 win 
256 

16:43:09.948433 172.30.1.254.7305 > 172.30.7.205.443: F 196:196(0) ack 1 win 
256 

16:43:15.648712 172.30.1.254.7305 > 172.30.7.205.443: FP 0:196(196) ack 1 win 
256 

And this traffic (incomplete thought it may be for an ssl handshake) appears to 
be passed to enc0 intact: 

16:43:05.105044 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: S 3570513915:3570513915(0) win 16384  (encap)

16:43:05.146122 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384  
(encap)

16:43:05.146654 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: . ack 1 win 256  
(encap)

16:43:05.147365 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:06.645932 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:09.646049 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: P 1:197(196) ack 1 win 256  (encap)

16:43:09.945908 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: F 197:197(0) ack 1 win 256  (encap)

16:43:09.981966 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: . ack 1 win 261  (encap)

16:43:15.646158 (unprotected): SPI 0xef27: 172.30.1.254.7305 > 
172.30.7.205.443: FP 1:197(196) ack 1 win 256  (encap)


BUT, at the other end of the VPN, on enc0, all that is seen leaving the iked 
VPN tunnel is: 

16:43:05.130558 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: S 3570513915:3570513915(0) win 16384  (encap)

16:43:05.131049 (authentic,confidential): SPI 0xe1c30e4a: 172.30.7.205.443 > 
172.30.1.254.7305: S 1312941075:1312941075(0) ack 3570513916 win 16384  
(encap)

16:43:05.174802 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: . ack 1 win 256  
(encap)

16:43:09.966420 (authentic,confidential): SPI 0x151333df: 172.30.1.254.7305 > 
172.30.7.205.443: F 197:197(0) ack 

Re: TLS suddenly not working over IKED site-to-site

[Theodore Wynnychenko]

> 
> > Rachel, 
> > 
> > As a first step, try using s_client to connect to a TLS service and 
> see what comes back: 
> > 
> > $ openssl s_client -connect : -showcerts 
> > 
> > There are more possible options on s_client to debug more deeply but 
> this is a good start. 
> > 
> > 
> > --Paul 
> > 
> 
> In answer to the above. Testing against three "random" servers  (see 
> bottom of the email for full exchange, top three are through VPN, rest 
> are bypassing VPN): 
> 


I wanted to follow up on this. 

I updated the servers that create the iked VPN to the 12/5 snapshot the other 
day. 

I then took one machine on the "remote" net and ran openssl s_server. 
I had another machine on the "local" net try to connect with openssl s_client. 

So, the s_client shows: 

SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
... and nothing more. 

The s_server shows: 

Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 
SSL_accept:before/accept initialization 
... and nothing more. 

I also had tcpdump running at several places along the route. 

On the outgoing/sending interface of the "s_client" machine I see: 

21:19:54.735257 172.30.1.254.44715 > 172.30.7.205.443: S 950714671:950714671(0) 
win 16384  
(DF)

21:19:54.773320 172.30.7.205.443 > 172.30.1.254.44715: S 668125506:668125506(0) 
ack 950714672 win 16384 

21:19:54.773391 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 (DF) 
21:19:54.774143 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:56.272544 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:59.272615 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:20:05.272786 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256 

21:20:10.743468 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.781912 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.124726 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.124786 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.162326 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 
21:20:17.273069 172.30.1.254.44715 > 172.30.7.205.443: FP 1:197(196) ack 2 win 
256  (DF)


On the incoming/receiving interface of the "local" iked machine I see: 

21:19:54.737490 172.30.1.254.44715 > 172.30.7.205.443: S 950714671:950714671(0) 
win 16384  
(DF)

21:19:54.775299 172.30.7.205.443 > 172.30.1.254.44715: S 668125506:668125506(0) 
ack 950714672 win 16384 

21:19:54.775625 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 (DF) 
21:19:54.776378 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:56.274790 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:19:59.274859 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256  (DF)

21:20:05.275017 172.30.1.254.44715 > 172.30.7.205.443: P 1:197(196) ack 1 win 
256 

21:20:10.745731 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.783860 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.126709 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.127041 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.164312 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


But, on the outgoing/sending interface of the "remote" iked machine, all that I 
see is: 

21:19:54.733973 172.30.1.254.44715 > 172.30.7.205.443: S 
4173630539:4173630539(0) win 16384 

21:19:54.734355 172.30.7.205.443 > 172.30.1.254.44715: S 
2645985599:2645985599(0) ack 4173630540 win 16384 

21:19:54.773048 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 
21:20:10.742843 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.743111 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.085788 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.123252 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.123472 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


And that is all that gets delivered to the incoming/receiving interface of the 
"s_server" machine: 

21:19:54.710031 172.30.1.254.44715 > 172.30.7.205.443: S 
4173630539:4173630539(0) win 16384 

21:19:54.710134 172.30.7.205.443 > 172.30.1.254.44715: S 
2645985599:2645985599(0) ack 4173630540 win 16384 

21:19:54.749110 172.30.1.254.44715 > 172.30.7.205.443: . ack 1 win 256 
 
21:20:10.718972 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 1 win 
256 

21:20:10.719023 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 


21:20:12.061678 172.30.7.205.443 > 172.30.1.254.44715: F 1:1(0) ack 1 win 261 
 
21:20:12.099433 172.30.1.254.44715 > 172.30.7.205.443: F 197:197(0) ack 2 win 
256 

21:20:12.099484 172.30.7.205.443 > 172.30.1.254.44715: . ack 1 win 261 
 


Now, if I try connecting using

IKED fails to establish VPN on last 2 amd64 snapshots

[Theodore Wynnychenko]

Hello 

I am sorry, but I don't have access to any specific output right at this
moment. 

However, there appears to be something odd happening with iked. 

Last week I noticed that ssl connections, when attempted through an iked vpn
tunnel, appeared to hang, when those same connections made directly (not via
iked VPN) worked as expected.  I tried mss clamping in pf, but that did not
really seem to do anything.

In hoping for a solution, I upgrade with the 12/1 snapshot for amd64 2 days
ago. 

After that upgrade, an openbsd<->openbsd iked VPN was NOT able to be
created. 

I had made no changes to pf.conf or iked.conf from the working (over at
least the last 1-2 years) iked VPN to the non-working iked VPN after the
snapshot on 12/1/18.

So, I tried making changes to pf.conf - essentially liberalizing the rules,
even "skipping" filtering on enc0.  But, this made no difference.

Today, I updated again to last night's amd64 snapshot on both ends of the
iked VPN.  No change, the OpenBSD<->OpenBSD iked VPN does not get
established.

But, if I downgrade iked/ikectl (TZ=UTC cvs up -D '2017/03/23 05:29:48' -P
sbin/iked usr.sbin/ikectl - etc... I have been doing this to maintain
function between openbsd iked and apple ios ikev2 - I know there would be no
support for this, I am only mentioning as part of my observations) then
apple ios devices CAN establish an ikev2 connection to the openbsd machine.
At the same time, even though both ends of the openbsd<->openbsd VPN are
running the same exact downgraded versions of iked, they are NOT able to
establish a VPN (but they were able to do so before the 12/1 snapshot).

To recap, after the snapshot of 12/1 on amd64, with no changes to iked.conf
or pf.conf, an ikev2 VPN is no longer created between two openbsd systems.
This is also true for last night's snapshot.

I don't know if this is in anyway related to the ssl over iked difficulties.


I will be happy to provide any information/output that may be helpful, I
just don't know exactly what that information would be.

Thanks 
Ted 

Re: TLS suddenly not working over IKED site-to-site

[Theodore Wynnychenko]

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Rachel Roch 
> Sent: Monday, December 03, 2018 11:19 AM 
> To: misc@openbsd.org 
> Subject: TLS suddenly not working over IKED site-to-site 
> 
> I hope someone here can shed light on an infuriating problem I’ve spent 
> a week trying to resolve without luck. 
> 
> The problem concerns an IKED site-to-site VPN on OpenBSD 6.3 (both 
> endpoints fully syspatched). 
. 
. 
. 
> 
> 
> This whole thing is just driving me crazy ! 


Hello, 
This appears to be the same thing I have been having issues with and mentioned 
in a post to misc last week ("Untable ssl connections over ikev2 VPN") - (yes, 
typo intact - it should be "unstable").

I have tried adding a "max-mss 1300" directive into pf.conf (i.e.: "match in 
all scrub (no-df random-id max-mss 1300)").

At first, I _thought_ this made a difference, but I am not sure if that is 
really true. 

I have also noticed that the TLS failures seem to vary based on OS.  At this 
point, I was able to get an https connection to work with firefox on MacOS, but 
the TLS handshake continues to hang (100% of the time) with firefox on a 
Windows 7 PC.  With an openBSD laptop, it seems like it sometimes works and 
sometimes doesn't (using "openssl s_client" to test).

I also made no changes in pf.conf or iked.conf from the working to non-working 
period. 

I have no idea what to do; I am just posting my observations if that helps. 
Thanks 

Re: Untable ssl connections over ikev2 VPN

[Theodore Wynnychenko]

> -Original Message- 
> Hello 
> 
> I have been having trouble getting an openBSD laptop to connect to ssl 
> connections when communicating over ikev2. 
> 
> In general terms (since I don't know exactly what specifics would be 
> important), this is what I observe: 
> 
> 1.  OpenBSD laptop has no issues connecting to imaps or https on a 
> openBSD server when connected to the local network over wireless 
> connection.  For example: 
> 
> $ openssl s_client -state -connect name.tld:imaps 
> CONNECTED(0003) 
> SSL_connect:before/connect initialization 
> SSL_connect:SSLv3 write client hello A 
> SSL_connect:SSLv3 read server hello A 
> . 
> . 
> . 
> verify return:1 
> SSL_connect:SSLv3 read server certificate A 
> SSL_connect:SSLv3 read server key exchange A 
> SSL_connect:SSLv3 read server done A 
> SSL_connect:SSLv3 write client key exchange A 
> SSL_connect:SSLv3 write change cipher spec A 
> SSL_connect:SSLv3 write finished A 
> SSL_connect:SSLv3 flush data 
> SSL_connect:SSLv3 read server session ticket A 
> SSL_connect:SSLv3 read finished A 
> --- 
> Certificate chain 
> . 
> . 
> . 
> --- 
> No client certificate CA names sent 
> Server Temp Key: ECDH, X25519, 253 bits 
> --- 
> SSL handshake has read 4779 bytes and written 281 bytes 
> --- 
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305 
> Server public key is 4096 bit 
> Secure Renegotiation IS supported 
> Compression: NONE 
> Expansion: NONE 
> No ALPN negotiated 
> SSL-Session: 
> . 
> . 
> . 
> Timeout   : 7200 (sec) 
> Verify return code: 0 (ok) 
> --- 
> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL 
> ACL2=UNION] Courier-IMAP ready. Copyright 1998-2017 Double Precision, 
> Inc.  See COPYING for distribution information. 
> 
> 
> 2.  Apple iOS devices have no issues connecting to imaps/https on 
> openbsd server, when connected to the local network. 
> 
> 3.  OpenBSD laptop, when connected remotely using iked is unable to 
> complete ssl connection _most_ of the time (by this, I would guesstimate 
> about 95%+ of the connections to imaps "hang," and about 75%+ of the 
> connections to https "hang").  This occurs at one of two places. 
> Either: 
> 
> $ openssl s_client -state -connect name.tld:imaps 
> CONNECTED(0003) 
> SSL_connect:before/connect initialization 
> SSL_connect:SSLv3 write client hello A 
> SSL_connect:SSLv3 read server hello A 
> 
> ... and that's it.  Or: 
> 
> $ openssl s_client -state -connect name.tld:imaps 
> CONNECTED(0003) 
> SSL_connect:before/connect initialization 
> SSL_connect:SSLv3 write client hello A 
> SSL_connect:SSLv3 read server hello A 
> . 
> . 
> . 
> verify return:1 
> SSL_connect:SSLv3 read server certificate A 
> SSL_connect:SSLv3 read server key exchange A 
> SSL_connect:SSLv3 read server done A 
> SSL_connect:SSLv3 write client key exchange A 
> SSL_connect:SSLv3 write change cipher spec A 
> SSL_connect:SSLv3 write finished A 
> SSL_connect:SSLv3 flush data 
> 
> ... and nothing more.  However, using nc to connect to the non-ssl imap 
> port appears to work (both locally and over the ikev2 VPN): 
> 
> $ nc name.tld imap 
> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] 
> Courier-IMAP ready. Copyright 1998-2017 Double Precision, Inc.  See 
> COPYING for distribution information. 
> 
> 
> 4.  Apple iOS devices, when connected (using ssl) over iked VPN appear 
> to be much more reliable.  While there are times when they appear to 
> "hang" when connecting, it seems like it happens < 20% of the time. 
> 
> I don't use my laptop remotely very often; the last time I did was about 
> 4-5 months ago.  At that point, I was able to connect to imaps much more 
> reliably (basically, the mail client worked over imaps, and there was no 
> reason to investigate anything). 
> 
> I don't think this is a pf issue, since the connection attempts over ssl 
> get an initial response. 
> 
> I tried dropping the mtu on the openbsd laptop's wireless adapter to 
> 1200; but that did not seem to change anything. 
> 
> I guess I don't really have much of an idea how to investigate this 
> further. 
> 
> Any suggestions on how to proceed would be great. 
> 
> Thanks 
> Ted 
> 


I wanted to update my observations. 

I now realize that since my most recent update (yesterday), I am getting
100% failure of https/imaps connection, when that connection includes
traversing a VPN tunnel established by iked.

This is true both for an openBSD laptop with a wireless connection to the
network, and openBSD servers connected with a cable.

This behavior did not exist prior to my update yesterday. 

As I stated above, my laptop can connect over ssl to https/imaps when on the
local network. 
However, when attempting those connections over an iked VPN, ssl connections
fail. 

I also have a remote server at a remote location that uses rsync 

Re: Courier Imap not accepting connections after updat to -curent

[Theodore Wynnychenko]

> -Original Message- 
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
> Of Giovanni Bechis 
> Sent: Wednesday, November 21, 2018 4:28 AM 
> To: t...@uchicago.edu; misc@openbsd.org 
> Subject: Re: Courier Imap not accepting connections after updat to - 
> curent 
> 
> On 11/18/18 10:35 PM, Theodore Wynnychenko wrote: 
> > Hello 
> > 
> > I just updated to -current using a snapshot. 
> > 
> > I then updated packages (pkg_add -vui), which updated courier-imap. 
> > 
> > pkg_info | grep courier 
> > courier-authlib-0.68.0p4 authentication library for courier 
> > courier-authlib-mysql-0.68.0p3 mysql authentication module for 
> > courier-authLib 
> > courier-imap-4.18.2p0 imap server for maildir format mailboxes 
> > courier-pop3-4.18.2p0 pop3 server for maildir format mailboxes 
> > courier-unicode-2.0p0 courier unicode library 
> > 
> > Courier does start, and is listening for imap-ssl connections: 
> > 
> > netstat -an | grep 993 
> > tcp 0 0 *.993 *.* LISTEN 
> > tcp6 0 0 *.993 *.* LISTEN 
> > 
> what's the output of 
> openssl s_client -connect $YOURIP:993 
> 
> does it works without ssl ? 
> There were some issues recently fixed in libssl land, can you try very 
> latest snapshot ? 
> 
>  Cheers 
>   Giovanni 

Thank you (and Stuart) for the reply.  I was away for the holiday in the US, 
and did not get a chance to look at this until the other day.

At that point, I upgraded to the most recent snapshot, upgraded the packages, 
and connections to imaps work without an issue on the local network.

It appears whatever was happening was a temporary problem. 
But... 

Thanks 
Ted 

Untable ssl connections over ikev2 VPN

[Theodore Wynnychenko]

Hello 

I have been having trouble getting an openBSD laptop to connect to ssl
connections when communicating over ikev2. 

In general terms (since I don't know exactly what specifics would be
important), this is what I observe: 

1.  OpenBSD laptop has no issues connecting to imaps or https on a openBSD
server when connected to the local network over wireless connection.  For
example:

$ openssl s_client -state -connect name.tld:imaps 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
SSL_connect:SSLv3 read server hello A 
. 
. 
. 
verify return:1 
SSL_connect:SSLv3 read server certificate A 
SSL_connect:SSLv3 read server key exchange A 
SSL_connect:SSLv3 read server done A 
SSL_connect:SSLv3 write client key exchange A 
SSL_connect:SSLv3 write change cipher spec A 
SSL_connect:SSLv3 write finished A 
SSL_connect:SSLv3 flush data 
SSL_connect:SSLv3 read server session ticket A 
SSL_connect:SSLv3 read finished A 
--- 
Certificate chain 
. 
. 
. 
--- 
No client certificate CA names sent 
Server Temp Key: ECDH, X25519, 253 bits 
--- 
SSL handshake has read 4779 bytes and written 281 bytes 
--- 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305 
Server public key is 4096 bit 
Secure Renegotiation IS supported 
Compression: NONE 
Expansion: NONE 
No ALPN negotiated 
SSL-Session: 
. 
. 
. 
Timeout   : 7200 (sec) 
Verify return code: 0 (ok) 
--- 
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP
ready. Copyright 1998-2017 Double Precision, Inc.  See COPYING for
distribution information.


2.  Apple iOS devices have no issues connecting to imaps/https on openbsd
server, when connected to the local network. 

3.  OpenBSD laptop, when connected remotely using iked is unable to complete
ssl connection _most_ of the time (by this, I would guesstimate about 95%+
of the connections to imaps "hang," and about 75%+ of the connections to
https "hang").  This occurs at one of two places.  Either:

$ openssl s_client -state -connect name.tld:imaps 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
SSL_connect:SSLv3 read server hello A 

... and that's it.  Or: 

$ openssl s_client -state -connect name.tld:imaps 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 
SSL_connect:SSLv3 read server hello A 
. 
. 
. 
verify return:1 
SSL_connect:SSLv3 read server certificate A 
SSL_connect:SSLv3 read server key exchange A 
SSL_connect:SSLv3 read server done A 
SSL_connect:SSLv3 write client key exchange A 
SSL_connect:SSLv3 write change cipher spec A 
SSL_connect:SSLv3 write finished A 
SSL_connect:SSLv3 flush data 

... and nothing more.  However, using nc to connect to the non-ssl imap port
appears to work (both locally and over the ikev2 VPN):

$ nc name.tld imap 
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready.
Copyright 1998-2017 Double Precision, Inc.  See COPYING for distribution
information.


4.  Apple iOS devices, when connected (using ssl) over iked VPN appear to be
much more reliable.  While there are times when they appear to "hang" when
connecting, it seems like it happens < 20% of the time.

I don't use my laptop remotely very often; the last time I did was about 4-5
months ago.  At that point, I was able to connect to imaps much more
reliably (basically, the mail client worked over imaps, and there was no
reason to investigate anything).

I don't think this is a pf issue, since the connection attempts over ssl get
an initial response. 

I tried dropping the mtu on the openbsd laptop's wireless adapter to 1200;
but that did not seem to change anything. 

I guess I don't really have much of an idea how to investigate this further.


Any suggestions on how to proceed would be great. 

Thanks 
Ted 

Courier imap not accepting connections after update to -curent

[Theodore Wynnychenko]

Hello 

I just updated to -current using a snapshot. 

I then updated packages (pkg_add -vui), which updated courier-imap. 

pkg_info | grep courier 
courier-authlib-0.68.0p4 authentication library for courier 
courier-authlib-mysql-0.68.0p3 mysql authentication module for
courier-authLib 
courier-imap-4.18.2p0 imap server for maildir format mailboxes 
courier-pop3-4.18.2p0 pop3 server for maildir format mailboxes 
courier-unicode-2.0p0 courier unicode library 

Courier does start, and is listening for imap-ssl connections: 

netstat -an | grep 993 
tcp 0 0 *.993 *.* LISTEN 
tcp6 0 0 *.993 *.* LISTEN 

I can also confirm the port is open from the connecting machine. 

However, mail clients cannot connect to the imap server.  They indicate the
server is not responding. 

Nothing in the configuration has changed since the update occurred. 

The imapd does use its own access file, so I tried commenting that out, and
restarting, but there was no change. 

It is listening, but does not accept connections. 

Not knowing what else to do, I downgraded to a previous version (the
packages associated with 6.3), and re-enabled the access file.

pkg_info | grep courier 
courier-authlib-0.68.0p3 authentication library for courier 
courier-authlib-mysql-0.68.0p2 mysql authentication module for
courier-authLib 
courier-imap-4.18.2p0 imap server for maildir format mailboxes 
courier-pop3-4.18.2p0 pop3 server for maildir format mailboxes 
courier-unicode-2.0p0 courier unicode library 

And, it works again, accepting connections from mail clients. 

But, this seems like a poor solution. 

If anyone has an idea of what I can try to get the current version of
courier working, that would be great. 


Thanks 
Ted 

Re: Change to init in -current?

[Theodore Wynnychenko]

-Original Message-
From: Theo de Raadt [mailto:dera...@openbsd.org] 
Sent: Saturday, November 10, 2018 7:57 PM
To: t...@uchicago.edu
Cc: misc@openbsd.org
Subject: Re: Change to init in -current?

Theodore Wynnychenko  wrote:

> So, to do this, I edited the appropriate terminal line in /etc/ttys to a
custom
> entry defined in /etc/gettytab; then added an entry to /etc/gettytab, using
> 'lo:' to point to a ksh script which (basically) looks at the input given to
> getty, and if it contains a specific username, runs "/usr/bin/login -f root" -
> if the user name entered is something different, the ksh script runs -> exec
> /usr/bin/login "$@" <- which allows any other user to login with a password.

Yes it is the unveil of /usr/bin/login specifically, rather than the
variable 'LO' which is 

gettytab.h:#define  LO  gettystrs[10].value

which is initialized by calling gettable() not just the first time,
but also later.  That picks up the change, but it is too late it is
after unveil() has locked the filesystem space down.

So we'll need to consider softening the unveil position, or removing
the obscure feature which no longer works.


-

I wanted to follow-up.  I guess I am just looking to understand/clarify.

In the reply above, it states that the problem lies in the "unveil of
/usr/bin/login specifically."

Does this mean that getty is only allowed to access "/usr/bin/login," and that
my custom script is not in an allowed location after unveil "locks down" getty?

This seems to make sense to me.  When I ran ktrace on the getty process that was
active for the local serial line, near the end of the trace (before the getty
session died and was re-spawned as a new/distinct process), I see:

...
 55962 gettyCALL  getpid()
 55962 gettyRET   getpid 55962/0xda9a
 55962 gettyCALL  sendsyslog(0x7f7bf2d0,64,0x2)
 55962 gettyGIO   fd -1 wrote 64 bytes
   "<35>getty[55962]: /local/autologin.sh: No such file or directory"
 55962 gettyRET   sendsyslog 0
 55962 gettyCALL  kbind(0x7f7c1338,24,0x6843e8d8b828be73)
 55962 gettyRET   kbind 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  kbind(0x7f7c1248,24,0x6843e8d8b828be73)
 55962 gettyRET   kbind 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  munmap(0x15931882b000,0x1000)
 55962 gettyRET   munmap 0
 55962 gettyCALL  exit(1)



Obviously, my script is named autologin.sh and lives in /local; and it does
exist with appropriate file permissions.  It appears that getty does not have
access to it any longer.  I surmise this error is because getty's filesystem
access has been locked down by unveil.

Is that what was meant by "unveil of /usr/bin/login specifically," or is it
something else?

Also, I am assuming that the only way I could correct this for myself would be
to learn a lot more of C than I know now, edit the getty source, and compile it
locally.  In other words, there isn't something I can do from the command line
to get it to work again, is there?

Again, thanks.  I totally understand that this functionality in getty may or may
not be available going forward.

Ted

Change to init in -current?

[Theodore Wynnychenko]

Hello 

I just updated to -current.  It had been about 2-3 months since I last updated.
I have been doing so since (about) 5.9 or so.

Anyway, way back then, I wanted to be able to login on a local serial terminal
without entering a password (yes, I know that there may be disagreement about
the wisdom of this, but, it's what I wanted).

So, to do this, I edited the appropriate terminal line in /etc/ttys to a custom
entry defined in /etc/gettytab; then added an entry to /etc/gettytab, using
'lo:' to point to a ksh script which (basically) looks at the input given to
getty, and if it contains a specific username, runs "/usr/bin/login -f root" -
if the user name entered is something different, the ksh script runs -> exec
/usr/bin/login "$@" <- which allows any other user to login with a password.

Anyway, this has worked without an issue until today. 

After the update to current, I cannot login on the serial console.  This is true
regardless of whether I use the "specific name" or any other user name on the
system.  Basically, after entering any user name at the login prompt, there is a
delay, and then the login prompt reappears (it appears getty just restarts).

If I return /etc/ttys to a "default" entry (with the "lo:" option removed, so
that the default /usr/bin/login is run), I can login with any username on the
system, using a password.

I have checked the man pages for ttys, getty, gettytab, init, ksh, and login,
and can't find anything that has changed. 

I am wondering if something has changed, and, if so, what that may be? 

Thanks 
Ted 

Is anyone able to use certificates with openbsd iked/ikev2 and Apple iOS (iphone)?

[Theodore Wynnychenko]

Hello

Last year (before about 3/27/2017 when "Add support for RFC4754 (ECDSA) and
RFC7427 authentication" diff was committed to current), I had set up and had
been able to connect iOS devices (iphone/ipad) to OpenBSD's iked, and have ikev2
VPN's happen, almost as if by, magic.

Authentication was accomplished using certificates signed by a local authority
and then distributed to the iOS devices.

Since 3/27/17, this has not been working.  I sent a couple of emails about this
last year (the initial one:
https://marc.info/?l=openbsd-bugs&m=149706080419488&w=2).

Over the last year, I have tried many things.  Even though I don't know anything
about programming (or C), I tried making little changes to the iked source, all
without success.  (Is that any surprise? No.  I was amazed at times that my
changes even resulted in a program that would actually start up and run.)

I have tried creating several different CA's and certificates, using various
different algorithms (ECDSA and RSA, with varying key lengths), all without
success.  For example, I just tried creating a CA and certificates with
ECDSA384/SHA2-384; I distribute those to the iOS device (which supports them),
but, iked will not accept them and create a tunnel.

In iked.conf, if I don't explicitly state something like "ecdsa384" as the
authentication method (and, this requires having a local copy of the public key
on the openbsd machine), iked falls back to rfc7427 for authentication, but it
appears that iOS does not support this (yet?).

I have been downgrading iked to a version before the 3/27/17 (every time I
update -current), and this still allows my old certificates to work.  But, that
doesn't seem sustainable.

I have no idea how to proceed?

Has anyone been able to get -current (or at least, a snapshot after 3/27/17)
version of iked to work with any iOS devices using certificates successfully?

If so, I would really appreciate some advice on how it can be done.

Thanks
Ted

bioctl "intermitently" reports RAID 1 array as degraded

[Theodore Wynnychenko]

Hello

I am trying to understand what I may be missing (I have been noticing this issue
for a year or so).

I have a machine running -current that is setup with 2 SSD hard drives.

The SSD's are fdisk'ed with 1 openbsd partition:

# fdisk sd0
Disk: sd0   geometry: 19457/255/63 [312581808 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
*3: A6  0   1   2 -  19456 254  63 [  64:   312576641 ] OpenBSD

The disklabels on each disk have an "a" 4.2BSD partition, a "b" swap partition,
and then a "m" RAID partition:

# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: INTEL SSDSA2BW16
duid: 43d094716532e926
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 19457
total sectors: 312581808
boundstart: 64
boundend: 312576705
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  2104448   64  4.2BSD   2048 16384 1 # /
  b: 18860313  2104512swap# none
  c:3125818080  unused
  m:291611880 20964825RAID

Most of the time, everything is fine:

# bioctl -i sd2
Volume  Status   Size Device
softraid0 0 Online   149305012224 sd2 RAID1
  0 Online   149305012224 0:0.0   noencl 
  1 Online   149305012224 0:1.0   noencl 


BUT, every once in a while (let's say, a couple of weeks, then a couple of
months), all of sudden the array will report as being degraded.

However, other than the notice that the array is degraded and that a mirror is
offline, I can find nothing in any log, or any changes in the dmesg to suggest
what may have happened.

I have changed the hard drive cables.  I have changed out the SSD drives.

But, it still happens every so often.

When the array is degraded, I can still fdisk/disklabel the "offline" disk
without a problem.  I can rebuild the degraded array with the "offline" disk (#
bioctl -R /dev/sd1m sd2), and the rebuild completes without a problem, and the
array is stable for weeks/months until, randomly, it happens again.

I am wondering if there is anything I should be looking at/for to help figure
out what the issue is?

As I said, I have already swapped out hardware (at least) once.  If it is a
hardware issue, I can keep swapping out hardware, but (at this point) it seems
that the probability is really low that I would have multiple drives that have
the same intermittent problem (but, obviously, not zero).

I would appreciate any advice on how to track down what the problem may be the
next time it happens.

Thanks
Ted

Re: fw_update signify unsigned package on current and 6.2-stable -SOLVED

[Theodore Wynnychenko]

-Original Message-
From: Theodore Wynnychenko 
Sent: Wednesday, November 01, 2017 8:43 AM
To: misc@openbsd.org
Subject: fw_update signify unsigned package on current and 6.2-stable

Hello:



How do I install the iwm-firmware without a network connection on either
6.2-stable or -current?

Thanks
Ted



I just wanted to say thank you to Nigel Taylor who sent some advice off list.
I don't know how I f...ed up, but the problem was one of my own doing apparently
(somehow, I had downloaded install media and firmware that were out of sync, and
did not realize I had done so).

So, after purging and then re-downloading the correct files, everything "just
worked."

Sorry for the noise.

fw_update signify unsigned package on current and 6.2-stable

[Theodore Wynnychenko]

Hello:

A couple of month ago, I decided to take the plunge and setup an openbsd laptop.
I bought a relatively newer ThinkPad, and (a couple of months ago) set it up and
started playing with the desktop environment.

Well, life happened, and I put it aside for a while.  Yesterday, I decided to
look at it again, and decided I would just start over.

So, I downloaded the current install image, and installed it on the laptop.

This laptop has no wired Ethernet port, just wireless which requires the
iwm-firmware.

So, after installing -current and booting into the system, I plugged in a USB
drive with the "iwm-firmware-0.20170105.tgz" on it, and issued:
# fw_update -p /mnt iwm

This worked a couple of months ago, and the wireless came up.  Yesterday (and
today), I got/get:

file:/mnt/iwm-firmware-0.20170105.tgz: unsigned package (signify(1) doesn't see
old-style signatures)

I see that how signify works had recently changed, so, I reinstalled with the
6.2 stable image.
But, I get the same error.

I would rather not go all the way back to 6.1.
I can find no way in the man page to get fw_update to install without checking
signatures.  I did try using "pkg_add -D unsigned" as a guess (with little
hope), but that did not work either.

It seems that the firmware package ("20170105") is from the time before signify
changed, and has not been brought into sync with the new signify (that's just a
guess).

How do I install the iwm-firmware without a network connection on either
6.2-stable or -current?

Thanks
Ted



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theodore Wynnychenko]

On Sep 25, 2017, at 9:31 PM, Philip Guenther  wrote:

On Mon, 25 Sep 2017, Theodore Wynnychenko wrote:



I noticed this message in the dmesg after updating -current yesterday.



I am not sure what it means.



There is no file "test-ld.so" anywhere on the system that I can find.

I also see that it appears this part of rc was just committed in the

last few weeks.



Why is this happening, and is there anything that I should do to correct

the "Permission denied" error?



It means that after /etc/rc had built a new ld.so, when it tried to test
it by running the test-ld.so program (which is packaged inside
/usr/libdata/ld.so.a), it failed with that error, EACCES.

My guess is that you're hitting this:

[EACCES]   The new process file is on a filesystem mounted with
   execution disabled (MNT_NOEXEC in ).

If you're mounting /tmp with the noexec flag, then stop doing that.


Philip Guenther





Thank you for the information.  I removed the “noexec” flag from fstab and the 
error has disappeared.



But, I am also surprised by the requirement that /tmp _not_ be mounted noexec 
for this to function correctly.  I recall reading that it was best to mount 
filesystems with the most restrictive settings possible for that specific 
filesystem, and that /tmp should be mounted with (essentially) nothing set (ie: 
nodev, nosuid, noexec).



Am I incorrect or has something changed in this regard?



It seems to me that, as a general rule, making /tmp noexec is a good thing from 
a security standpoint; but I admit that I don’t know enough about this to be 
sure.



Anyway, I just added a line to rc.local to remount temp as noexec at the end of 
the boot so that rc would work without errors and that /tmp is noexec once the 
system is up.



Is that bad?



Thanks



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: apache2 cgi script stopped working with -current about April 2017

[Theodore Wynnychenko]

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart
Henderson
Sent: Sunday, September 24, 2017 2:43 PM
To: misc@openbsd.org
Subject: Re: apache2 cgi script stopped working with -current about April 2017

On 2017-09-24, Theodore Wynnychenko  wrote:
> This was working for years, until about April or May.  Then, after an update
of
> the base system (and before an update of the installed packages), I noticed
the
> scripts had stopped working.  I updated the packages, and the scripts
continued
> to not work.

First thing I'd try is updating the copies of binaries/libraries/ld.so inside
the chroot jail.




Thank you.

I don't know why I just didn't do that to begin with, as it was not a hard thing
to do (especially since I was wasting all sorts of time looking for more
esoteric causes).

So, I updated the libraries and binaries in the chroot, and the scripts work.

I think I was confused by the fact that the scripts worked from the shell using
the chroot command; but, I am guessing, the call from the running apache2
process is not _exactly_ the same.

Thanks





---
This email has been checked for viruses by AVG.
http://www.avg.com

reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theodore Wynnychenko]

Hello

I noticed this message in the dmesg after updating -current yesterday.

I am not sure what it means.

There is no file "test-ld.so" anywhere on the system that I can find.  I also
see that it appears this part of rc was just committed in the last few weeks.

Why is this happening, and is there anything that I should do to correct the
"Permission denied" error?


Thank you.
Ted



---
This email has been checked for viruses by AVG.
http://www.avg.com

apache2 cgi script stopped working with -current about April 2017

[Theodore Wynnychenko]

Hello

I have delayed asking for help hoping that I would figure this out on my own.

But, after several months, of on-and-off attempts, I can't think of anything
else, so...

I have been following current for some time, now:  OpenBSD 6.2 GENERIC.MP#105
amd64

I also continue to use apache2 in ports:  apache-httpd-2.4.27p0

I have a few small /bin/sh scripts.  Basically, I have a cron job that runs and
writes some system info to a file in the /var/www chroot, so that I can quickly
check a few things via a web-browser.

My instance of apache2 runs as www.www and is chroot'ed to /var/www:
>From /etc/apache2/httpd2.conf:

...snip...
User www
Group www
ChrootDir "/var/www"
...snip...

This was working for years, until about April or May.  Then, after an update of
the base system (and before an update of the installed packages), I noticed the
scripts had stopped working.  I updated the packages, and the scripts continued
to not work.

An example:

I point my web-browser to:  https://example.com/cgi-bin/viewsys

I get an "Internal Server Error" displayed.

When I look at the apache error logs, I see (I have turned up the logging a
bit):

[Sun Sep 24 12:01:31.534535 2017] [ssl:info] [pid 16510] [client
xxx.xxx.2.10:21991] AH01964: Connection to child 0 established (server
example.com:443)
[Sun Sep 24 12:01:31.535886 2017] [socache_shmcb:debug] [pid 16510]
mod_socache_shmcb.c(530): AH00835: socache_shmcb_retrieve (0x91 -> subcache 17)
[Sun Sep 24 12:01:31.535905 2017] [socache_shmcb:debug] [pid 16510]
mod_socache_shmcb.c(916): AH00851: shmcb_subcache_retrieve found no match
[Sun Sep 24 12:01:31.535909 2017] [socache_shmcb:debug] [pid 16510]
mod_socache_shmcb.c(541): AH00836: leaving socache_shmcb_retrieve successfully
[Sun Sep 24 12:01:31.535937 2017] [ssl:debug] [pid 16510]
ssl_engine_kernel.c(2126): [client xxx.xxx.2.10:21991] AH02043: SSL virtual host
for servername example.com found
[Sun Sep 24 12:01:31.535943 2017] [core:debug] [pid 16510] protocol.c(2220):
[client xxx.xxx.2.10:21991] AH03155: select protocol from , choices=h2,http/1.1
for server example.com
[Sun Sep 24 12:01:31.535952 2017] [ssl:debug] [pid 16510]
ssl_engine_kernel.c(2126): [client xxx.xxx.2.10:21991] AH02043: SSL virtual host
for servername example.com found
[Sun Sep 24 12:01:31.635216 2017] [ssl:debug] [pid 16510]
ssl_engine_kernel.c(2053): [client xxx.xxx.2.10:21991] AH02041: Protocol:
TLSv1.2, Cipher: ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
[Sun Sep 24 12:01:31.636987 2017] [ssl:debug] [pid 16510]
ssl_engine_kernel.c(361): [client xxx.xxx.2.10:21991] AH02034: Initial (No.1)
HTTPS request received for child 0 (server example.com:443), referer:
https://example.com/
[Sun Sep 24 12:01:31.637039 2017] [authz_core:debug] [pid 16510]
mod_authz_core.c(806): [client xxx.xxx.2.10:21991] AH01626: authorization result
of Require all granted: granted, referer: https://example.com/
[Sun Sep 24 12:01:31.637046 2017] [authz_core:debug] [pid 16510]
mod_authz_core.c(806): [client xxx.xxx.2.10:21991] AH01626: authorization result
of : granted, referer: https://example.com/
[Sun Sep 24 12:01:31.642334 2017] [cgi:error] [pid 16510] [client
xxx.xxx.2.10:21991] End of script output before headers: viewsys, referer:
https://example.com/
[Sun Sep 24 12:01:31.642971 2017] [ssl:debug] [pid 16510] ssl_engine_io.c(1099):
[client xxx.xxx.2.10:21991] AH02001: Connection closed to child 0 with standard
shutdown (server example.com:443)


So, the cgi-script is called, but appears not to return anything:  "End of
script output before headers"



I enabled logging of cgi info in apache2, and in the "cgi_log" I see:

%% [Sun Sep 24 12:01:31 2017] GET /cgi-bin/viewsys HTTP/1.1
%% 500 /cgi-bin/viewsys
%request
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101
Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://example.com/
Cookie: icingaweb2-tzo=-18000-1; icingaweb2-session=1506271615;
Icingaweb2=6h1eginggl1ktaioce40d56p225b63gm
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
%response


And that's it, no response.


So, this makes you think that there is a problem with the script running in the
chroot.

But, if I run the script (nothing fancy - basically, it is just printing out
http of dmesg info that has been stuck into a file in the chroot by a cron job
running outside the chroot):
cat viewsys
..
#!/bin/sh
. /cgi-bin/web.functions

htmlhead "System Information"
dmesg=`cat ../tmp/dmesginfo`

b_head

t_head " System DMESG "
cat <<- /DMESGINFO
 
  
$dmesg
  
 
/DMESGINFO
t_foot

b_foot
htmlend
.

Using chroot:

# chroot -u www /var/www /cgi-bin/viewsys

I see the correct output:
..
Content-type:text/html

System Information


H1 {font-family: Comic Sans MS,sans-serif; font-size: 40px; color:#009900;
line-height: 45px; text-align: center; text-decoration: none

Re: Unable to establish ikev2 vpn with ios using current - OpenBSD 6.1 GENERIC.MP#106 amd64 - can anyone help?

[Theodore Wynnychenko]

Hello

I have updated to the last several snapshots as they have come out, but continue
to be unable to establish a VPN between iOS and OpenBSD.  As the iOS device has
not been updated recently, the "problem" appears to relate to something that
changed on the OpenBSD side.

I don't know, and don't even have an idea of how I could find out, if this is a
problem with iOS not following some standard, or if it is an issue with
OpenBSD's iked.

I am not trying to be demanding, and I am not suggesting that I am entitled to
any help whatsoever.  But, I will admit that I have come to rely on iked, and
the loss of a VPN to iOS is a problem for me.

I got logs off the an iphone (a snip is below), but other than seeing that the
iphone tries to create a VPN, and then fails and disconnects (despite the fact
that openBSD states the connection is ESTABLISHED), I have no clue what is
happening.

---
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] : Not
hashing value with class __NSDate
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] :
NESMIKEv2VPNSession[Wynnychenko VPN:D636E9EF-3B66-4537-93E8-0E3DEC18D7AB]:
Received a start command from Preferences[200]
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] :
NESMIKEv2VPNSession[Wynnychenko VPN:D636E9EF-3B66-4537-93E8-0E3DEC18D7AB]:
status changed to connecting
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] : Plugin
com.apple.neplugin.IKEv2 does not have a bundle URL
Jun  6 14:54:14 iPhone kernel(Sandbox)[0] : SandboxViolation:
nesessionmanager(124) deny(1) file-issue-extension target:
/System/Library/Frameworks/NetworkExtension.framework/PluginIKEv2.vpnplugin
class: com.apple.vpn-plugin
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] :
sendInitCommand: failed to create a com.apple.vpn-plugin sandbox extension for
/System/Library/Frameworks/NetworkExtension.framework/PluginIKEv2.vpnplugin
Jun  6 14:54:14 iPhone neagent(NetworkExtension)[824] : Certificate at
index 0 could not be created
Jun  6 14:54:14 iPhone neagent(NetworkExtension)[824] : Certificate
authentication data could not be verified
Jun  6 14:54:14 iPhone neagent(NetworkExtension)[824] : Failed to process
IKE Auth packet
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] :
NESMIKEv2VPNSession[Wynnychenko VPN:D636E9EF-3B66-4537-93E8-0E3DEC18D7AB]:
status changed to disconnecting
Jun  6 14:54:14 iPhone configd[32] : network changed
Jun  6 14:54:14 iPhone kernel[0] : SIOCPROTODETACH_IN6: ipsec3 error=6
Jun  6 14:54:14 iPhone configd(IPConfiguration)[32] :
siocprotodetach(pdp_ip0) failed, Resource busy (16)
Jun  6 14:54:14 iPhone nesessionmanager(NetworkExtension)[124] :
NESMIKEv2VPNSession[Wynnychenko VPN:D636E9EF-3B66-4537-93E8-0E3DEC18D7AB]:
status changed to disconnected, last stop reason Plugin initiated
---

If anyone can offer anything to help fix this issue, even just letting me know
that this a problem that I am experiencing locally and not a problem with the
current iked, I would really appreciate it.

Thank you
Ted



-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Theodore Wynnychenko
Sent: Monday, June 05, 2017 7:16 PM
To: misc@openbsd.org
Subject: Re: Unable to establish ikev2 vpn with ios after update to current -
OpenBSD 6.1 GENERIC.MP#103 amd64

I updated to the most recent snapshot (OpenBSD 6.1 GENERIC.MP#103 amd64).

Unfortunately, while an OpenBSD to OpenBSD ikev2 tunnel works as expected,
attempts to establish a tunnel from ios to OpenBSD fail.

However, the OpenBSD machine appears to believe that the tunnel is up and fine
("sa_state: VALID -> ESTABLISHED"), while the iOS device indicates that no VPN
is up.

There appears to be no change from the snapshot from a couple of days ago, and
this had been working flawlessly through several snapshots over the last year.

Does anyone have any advice on this, and what might have changed?

I see nothing obvious that I need to change in the iked.conf based on the my
reading of the current manpage.

Thank you
Ted


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Theodore Wynnychenko
Sent: Sunday, June 04, 2017 8:14 PM
To: misc@openbsd.org
Subject: Unable to estable ikev2 vpn with ios after update to current

Hello

I have been a bit remiss, and have not updated my system in a couple of months.
I have been following current for a year or two, in general, without incident.

Anyway, after updating last night, I am unable to establish a ikev2 vpn with an
ios 10.3.2 device.  A OBSD6.1<->OBSD6.1 ikev2 vpn is working fine.

I am hoping that someone could shove me in a direction.

I have been using iked with iOS for about a year without a problem.

However, after the update, I noticed that all iOS vpn attempts were failing.

Running # iked -dvvv and trying to connect showed:

...
ca_setauth: auth length 510
ikev2_ike_auth_recv: unexp

Re: Unable to establish ikev2 vpn with ios after update to current - OpenBSD 6.1 GENERIC.MP#103 amd64

[Theodore Wynnychenko]

I updated to the most recent snapshot (OpenBSD 6.1 GENERIC.MP#103 amd64).

Unfortunately, while an OpenBSD to OpenBSD ikev2 tunnel works as expected,
attempts to establish a tunnel from ios to OpenBSD fail.

However, the OpenBSD machine appears to believe that the tunnel is up and fine
("sa_state: VALID -> ESTABLISHED"), while the iOS device indicates that no VPN
is up.

There appears to be no change from the snapshot from a couple of days ago, and
this had been working flawlessly through several snapshots over the last year.

Does anyone have any advice on this, and what might have changed?

I see nothing obvious that I need to change in the iked.conf based on the my
reading of the current manpage.

Thank you
Ted


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Theodore Wynnychenko
Sent: Sunday, June 04, 2017 8:14 PM
To: misc@openbsd.org
Subject: Unable to estable ikev2 vpn with ios after update to current

Hello

I have been a bit remiss, and have not updated my system in a couple of months.
I have been following current for a year or two, in general, without incident.

Anyway, after updating last night, I am unable to establish a ikev2 vpn with an
ios 10.3.2 device.  A OBSD6.1<->OBSD6.1 ikev2 vpn is working fine.

I am hoping that someone could shove me in a direction.

I have been using iked with iOS for about a year without a problem.

However, after the update, I noticed that all iOS vpn attempts were failing.

Running # iked -dvvv and trying to connect showed:

...
ca_setauth: auth length 510
ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
ikev2_resp_recv: failed to send auth response
sa_state: AUTH_REQUEST -> CLOSED from xxx.yyy.1.254:64252 to xxx.yyy.1.20:4500
policy 'ios_vpn'
ikev2_recv: closing SA
sa_free: ispi 0xcd95648ffb47ac65 rspi 0x86e6b00a7646172e
config_free_proposals: free 0x13f816f06500
config_free_proposals: free 0x13f8e4f63580
ca_setauth: auth length 528
ca_validate_pubkey: could not open public key pubkeys/fqdn/ios.ikev2.myfqdn.com
ca_x509_subjectaltname: FQDN/ios.ikev2.myfqdn.com
ca_validate_cert: /C=US/ST=Illinois... ok
ikev2_getimsgdata: imsg 24 rspi 0x86e6b00a7646172e ispi 0xcd95648ffb47ac65
initiator 0 sa invalid type 14 data length 528
ikev2_dispatch_cert: invalid auth reply


I found a suggestion that placing an RSA public certificate on the local OBSD
machine could help.

So, I used:

# openssl rsa -in private.key -pubout >
/etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com

Now, running # iked -dvvv shows:

set_policy_auth_method: using rsa for peer
/etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com
set_policy: found pubkey for /etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com
ikev2 "ios_vpn" passive esp inet from 0.0.0.0/0 to xxx.yyy.15.0/24 local
xxx.yyy.1.20 peer any ikesa enc aes-256,aes-192,aes-128,3des prf
hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group
modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth
hmac-sha2-256,hmac-sha1 srcid ikesync.myfqdn.com dstid ios.ikev2.myfqdn.com
ikelifetime 1800 lifetime 1800 bytes 536870912 rsa config address xxx.yyy.15.131
config netmask 255.255.255.0 config name-server xxx.yyy.1.128 config name-server
xxx.yyy.1.129 config netbios-server xxx.yyy.2.99
ca_privkey_serialize: type RSA_KEY length 2349
ca_pubkey_serialize: type RSA_KEY length 526
ca_privkey_to_method: type RSA_KEY method RSA_SIG
config_getpolicy: received policy
ca_getkey: received private key type RSA_KEY length 2349
ca_getkey: received public key type RSA_KEY length 526
ca_dispatch_parent: config reset
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
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
ca_reload: loaded ca file ca.crt
ca_reload: /C=US/ST=Illinois...
ca_reload: loaded 1 ca certificate
ca_reload: loaded cert file local.myfqdn.com.crt
ca_reload: loaded cert file ikesync.myfqdn.com.crt
ca_validate_cert: /C=US/ST=Illinois... ok
ca_validate_cert: /C=US/ST=Illinois... ok
ca_reload: local cert type X509_CERT
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_recv: IKE_SA_INIT request from initiator xxx.yyy.1.254:55008 to
xxx.yyy.1.20:500 policy 'jacqueline_iphone_vpn' id 0, 432 bytes
ikev2_recv: ispi 0xd14315b81593285a rspi 0x
ikev2_policy2id: srcid FQDN/ikesync.myfqdn.com length 27
ikev2_pld_parse: header ispi 0xd14315b81593285a rspi 0x
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 432
response 0
ikev2_pld_payl

Unable to estable ikev2 vpn with ios after update to current

[Theodore Wynnychenko]

Hello

I have been a bit remiss, and have not updated my system in a couple of months.
I have been following current for a year or two, in general, without incident.

Anyway, after updating last night, I am unable to establish a ikev2 vpn with an
ios 10.3.2 device.  A OBSD6.1<->OBSD6.1 ikev2 vpn is working fine.

I am hoping that someone could shove me in a direction.

I have been using iked with iOS for about a year without a problem.

However, after the update, I noticed that all iOS vpn attempts were failing.

Running # iked -dvvv and trying to connect showed:

...
ca_setauth: auth length 510
ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
ikev2_resp_recv: failed to send auth response
sa_state: AUTH_REQUEST -> CLOSED from xxx.yyy.1.254:64252 to xxx.yyy.1.20:4500
policy 'ios_vpn'
ikev2_recv: closing SA
sa_free: ispi 0xcd95648ffb47ac65 rspi 0x86e6b00a7646172e
config_free_proposals: free 0x13f816f06500
config_free_proposals: free 0x13f8e4f63580
ca_setauth: auth length 528
ca_validate_pubkey: could not open public key pubkeys/fqdn/ios.ikev2.myfqdn.com
ca_x509_subjectaltname: FQDN/ios.ikev2.myfqdn.com
ca_validate_cert: /C=US/ST=Illinois... ok
ikev2_getimsgdata: imsg 24 rspi 0x86e6b00a7646172e ispi 0xcd95648ffb47ac65
initiator 0 sa invalid type 14 data length 528
ikev2_dispatch_cert: invalid auth reply


I found a suggestion that placing an RSA public certificate on the local OBSD
machine could help.

So, I used:

# openssl rsa -in private.key -pubout >
/etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com

Now, running # iked -dvvv shows:

set_policy_auth_method: using rsa for peer
/etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com
set_policy: found pubkey for /etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.com
ikev2 "ios_vpn" passive esp inet from 0.0.0.0/0 to xxx.yyy.15.0/24 local
xxx.yyy.1.20 peer any ikesa enc aes-256,aes-192,aes-128,3des prf
hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group
modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth
hmac-sha2-256,hmac-sha1 srcid ikesync.myfqdn.com dstid ios.ikev2.myfqdn.com
ikelifetime 1800 lifetime 1800 bytes 536870912 rsa config address xxx.yyy.15.131
config netmask 255.255.255.0 config name-server xxx.yyy.1.128 config name-server
xxx.yyy.1.129 config netbios-server xxx.yyy.2.99
ca_privkey_serialize: type RSA_KEY length 2349
ca_pubkey_serialize: type RSA_KEY length 526
ca_privkey_to_method: type RSA_KEY method RSA_SIG
config_getpolicy: received policy
ca_getkey: received private key type RSA_KEY length 2349
ca_getkey: received public key type RSA_KEY length 526
ca_dispatch_parent: config reset
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
config_getpolicy: received policy
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
ca_reload: loaded ca file ca.crt
ca_reload: /C=US/ST=Illinois...
ca_reload: loaded 1 ca certificate
ca_reload: loaded cert file local.myfqdn.com.crt
ca_reload: loaded cert file ikesync.myfqdn.com.crt
ca_validate_cert: /C=US/ST=Illinois... ok
ca_validate_cert: /C=US/ST=Illinois... ok
ca_reload: local cert type X509_CERT
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_recv: IKE_SA_INIT request from initiator xxx.yyy.1.254:55008 to
xxx.yyy.1.20:500 policy 'jacqueline_iphone_vpn' id 0, 432 bytes
ikev2_recv: ispi 0xd14315b81593285a rspi 0x
ikev2_policy2id: srcid FQDN/ikesync.myfqdn.com length 27
ikev2_pld_parse: header ispi 0xd14315b81593285a rspi 0x
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 432
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 48
ikev2_pld_sa: more 0 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_payloads: payload KE nextpayload NONCE critical 0x00 length 264
ikev2_pld_ke: dh group MODP_2048 reserved 0
ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 20
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 8
ikev2_pld_notify: protoid NONE spisize 0 type REDIRECT_SUPPORTED
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
ikev2_nat_detection: peer source 0xd14315b81593285a 0x

Re: netsnmpd Fails to Start on Current [Solved]

[Theodore Wynnychenko]

On 2016-10-04, Theodore Wynnychenko  wrote:
> # /usr/local/sbin/snmpd -L e
> kvm_openfiles: Operation not permitted
> kvm_openfiles: /dev/mem: Operation not permitted

On 2016-10-06, Stuart Henderson wrote:

> Kernel virtual memory access is no longer permitted by the kernel on a
> On 2016-10-04, normally running system.  The relevant parts of net-snmp will
need to be
> disabled or rewritten.


Thank you (again) for the reply.
Even though I had previously read the (net)snmpd manpage, I went through it
again, and found (apparently, missed it before):

 -r  Do not require root access to run the daemon.  Specifically, do
 not exit if files only accessible to root (such as /dev/kmem
 etc.) cannot be opened.

So, I added 'netsnmpd_flags="-r -u _netsnmp -I -ipv6"' to /etc/rc.conf.local,
and netsmtpd now starts without as expected.

# rcctl start netsnmpd
netsnmpd(ok)

Thanks again

netsnmpd Fails to Start on Current

[Theodore Wynnychenko]

Hello

I updated to the Oct 2 AMD64 snapshot yesterday.
I then updated to the Oct 3 AMD64 snapshot today.

After updating to the Oct 2 snapshot, I noticed that netsnmpd (from packages)
was "failed" on reboot.

I updated all the packages (pkg_add -vui), but had a failure ("bad minor" or
something like that), so then updated to the Oct 3 snapshot today.

# uname -prsv
OpenBSD 6.0 GENERIC.MP#2525 amd64


This time, updating of net-snmp was successful, but "rcctl start netsnmpd" still
returns "failed."

# pkg_info | grep net-snmp
net-snmp-5.7.3p9extendable SNMP implementation

But,

# rcctl -d start netsnmpd
doing _rc_parse_conf
doing _rc_quirks
netsnmpd_flags empty, using default >-u _netsnmp -I -ipv6<
doing _rc_parse_conf /var/run/rc.d/netsnmpd
doing _rc_quirks
doing rc_check
netsnmpd
doing rc_start
doing _rc_rm_runfile
(failed)


# /usr/local/sbin/snmpd -L e
kvm_openfiles: Operation not permitted
kvm_openfiles: /dev/mem: Operation not permitted


I found openbsd-rcd-EuroBSDcon2016.pdf under
https://www.openbsd.org/events.html, and I added a login class for netsnmpd to
/etc/login.conf
---
netsnmpd:\
:openfiles-cur=512:\
:tc=daemon:
---

I didn't think this login.conf change would make a difference, but I did not
think it would hurt either.

I have added "wxallowed" to /usr/local in fstab.

I have no idea what the "kvm_openfiles" errors mean; let alone how to address
it/them.

I would appreciate any advice on how to proceed.

Thanks
Ted

Using isc-dhcp-client as alternate dhclient

[Theodore Wynnychenko]

Hello
I would like to get the isc-dhcp-client working as a replacement for the base
dhclient.

The primary reason for this is so that I can assign an alias to the interface.

But, I can't seem to figure out how to get this done.  I have two issues.

First, I can't get the isc-dhcp-client to assign an alias to the interface,
despite the documentation that states it should.

I have created an /etc/isc-dhclient.conf file:
---
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
script "/usr/local/sbin/dhclient-script";

supersede domain-name "domain.com";
supersede domain-name-servers d.n.s.1,d.n.s.2;

request subnet-mask, broadcast-address, time-offset, routers;

alias {
  interface "em0";
  fixed-address fi.xed.ip.addr;
  option subnet-mask 255.255.255.0;
}
---

But, after killing the running dhclient process (from base), removing the leases
at /var/db/dhclient.leases* and starting isc-dhcp-client with:

# /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0

the isc client is able to get a an offer from the dhcp server, but it does _not_
assign the alias address to the interface.  The only address is the dynamically
assigned one.

I can find no guidance on what I am doing wrong, and why the isc-dhcp-client is
not assigning the alias.

Second, I (apparently) don't understand how to replace the base dhclient with
the isc dhclient at boot.

I tried modifying /etc/hostname.em0 from:
---
dhcp NONE NONE NONE description "Uplink"
---

To:
---
! /usr/local/sbin/dhclient -cf /etc/isc-dhclient.conf em0
---

But this did not work.  I now see in the hostname.if manpage that the command
needs to be available in the single-user environment (/bin or /sbin), but it
seems to me that if I was doing this "right," I shouldn't need to move the isc
client from the location that the package installed it in.  So, before I start
moving things around, I wanted to check if this is the way to do it, or if I
have missed something more appropriate.

Thanks for any advice.

Ted

Does a softraid partition require an fdisk partition

[Theodore Wynnychenko]

Hello
I recently changed disks in an openbsd system.
Everything went smoothly, as expected.

I dumped the old filesystems; installed the new disks; created "fdisk
partitions" on the physical drives; made "disklabel partitions" on the physical
drives; setup a softraid0; created the "disklabel partitions" on the softraid;
and restored the filesystems.

The machine booted up like nothing had happened.

But, I just realized that I did NOT create a "fdisk partition" (MBR) within the
softraid.  When I look at the fdisk partition table of the "softraid" it is
completely blank; no OpenBSD partition, no offsets, etc.

Everything seems to be working fine.  But I don't know if this is "wrong" and
will result in problems down the road.  It wouldn't be a big deal to recreate
the raid and re-restore the filesystems if necessary; but I would rather not
waste the time if it isn't necessary.

Since the softraid volume doesn't have the base OS installed on it, and will
never be used as a "boot device," I think I am ok, but am not sure.

So, are things ok with no partition table in the "MBR" of the softraid, or
should I fix that before the system has trouble?

Thank
Ted

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Adding chunk to softraid volume with bioctl - required chunk size

[Theodore Wynnychenko]

Hello

I have a question about RAID 1 volumes set up with bioctl.

When I originally set up the softraid, I created a RAID partition that
(essentially) took up the entire drive.  However, the disklabel INSIDE the
softraid does NOT use the all the space available (e.g.  The chunks making up
the RAID partition are 120GB, but the disklabel within the RAID only currently
uses 60GB of space; so, 60 GB of space have not/will not have any data on them).

My question is, if I want to add a new chunk to this array, does it have to be
120GB; or, since I am only using 60GB within the RAID, can I add a new chunk
that is only 60GB?  And, if so, is there anything special I need to do when
adding the smaller chunk?

With the falling price of SSD's, I am thinking of replacing the spinning disks
with SSD's.  It seems I will never need the additional space in the RAID, and it
would be cheaper to buy smaller SSD's.

Thanks
Ted

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: Trying to get squid with ssl bump working

[Theodore Wynnychenko]

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart
Henderson
Sent: Friday, January 29, 2016 6:31 PM
To: misc@openbsd.org
Subject: Re: Trying to get squid with ssl bump working

...

I didn't include this line but I believe it's the default anyway

I also explicitly set "sslproxy_cert_sign signTrusted", I think that's
the default but I may be wrong

...


Thank you so much!

According to squid-cache.org there is no default for "sslproxy_cert_sign"

I added "sslproxy_cert_sign signTrusted" to squid.conf and the https proxy
sprang to life.

I also changed login.conf as you suggest.

Thanks again

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: ypldap.conf help - was: Samba4 and OpenBSD

[Theodore Wynnychenko]

Oh, my mistake.
Needed to change:

binddn"WYNNYCHENKO\Administrator"

to

binddn"WYNNYCHENKO\\Administrator"

also.

Now, when I start ypldap:

# ypldap -dv
...
startup [debug mode]
configuration starting
applying configuration
connecting to directories
starting directory update
searching password entries
searching group entries
updates are over, cleaning up trees now
flattening trees
---

So, at least I seem to be moving forward.
Thanks


-Original Message-
From: Theodore Wynnychenko [mailto:t...@uchicago.edu]
Sent: Monday, January 11, 2016 9:21 AM
To: 'misc'
Subject: RE: ypldap.conf help - was: Samba4 and OpenBSD


On Mon, Jan 11, 2016 at 9:37 AM, Stuart Henderson  wrote:
> On 2016-01-11, Theodore Wynnychenko  wrote:
>> directory "ldap://DC1.samba.domain.com:389"; {
>
> afaik this just takes a hostname, not a URL.

Confirmed.

And see also:

http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client

Ciao!
David
-- 


Thanks for the advice.

So, replacing the 'H "ldap://DC1.samba.domain.com:389";' with '-h
"DC1.samba.domain.com"' in ldapsearch works.

e.g.:  ldapsearch -x -h "DC1.samba.domain.com" -D "DOMAIN\Administrator" -w
"password" -b "dc=samba,dc=domain,dc=com" "(objectClass=group)"

...
# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 4
# numReferences: 3
-

ldapsearch also works if I use '-h "localhost"' or '-h "127.0.0.1"' or '-h
"xxx.yyy.zzz.aaa"'.

But, when I replace the directory line in ypldap.conf to:

directory "DC1.samba.domain.com"

or "localhost" or "127.0.0.1" or the IP address; and start ypldap -dv, I get:

# ypldap -dv
startup [debug mode]
configuration starting
applying configuration
connecting to directories
starting directory update
searching password entries
directory DC1.samba.domain.com errored out in search

and it hangs; after a manual break:

ldap client exiting
dns engine exiting
---

The "errored out in search" line changes based on the directory value from
ypldap.conf.

I was wondering if there might be something "different" about the ldap server
included with samba4; but 'man ldapsearch' confirms that it is not anything
"special" from samba, but comes from OpenLDAP:

man ldapsearch
...
ACKNOWLEDGEMENTS
   OpenLDAP Software is developed and maintained by The OpenLDAP Project
   <http://www.openldap.org/>.  OpenLDAP Software is derived from
   University of Michigan LDAP 3.3 Release.

OpenLDAP 2.4.43   2015/11/30 LDAPSEARCH(1)


Therefore, it seems to me that if "this" ldapsearch can get information out of 
the
samba ldap server, than ypldap should be able to as well.  Right?

A search for the error message above doesn't really lead me anywhere.  Any ideas
what the error means?

Thanks again



cat ypldap.conf
...
# Global settings
domain   "samba.domain.com"
interval 3600

# Specify the maps that ypldap should provide
provide map  "passwd.byname"
provide map  "passwd.byuid"
provide map  "group.byname"

# Directory declaration
directory "DC1.samba.domain.com" {
binddn"DOMAIN\Administrator"
bindcred  "password"
basedn"dc=samba,dc=domain,dc=com"

# passwd maps configuration
passwd filter "(objectClass=posixAccount)"

attribute name maps to "uid"
fixed attribute passwd "*"
attribute uid maps to "uidNumber"
attribute gid maps to "gidNumber"
attribute home maps to "homeDirectory"
attribute gecos maps to "gecos"
# LDAP users are not interactive system users
fixed attribute shell "/sbin/nologin"
fixed attribute change "0"
fixed attribute expire "0"
fixed attribute class "default"

# group maps configuration
group filter "(objectClass=group)"

attribute groupname maps to "cn"
fixed attribute grouppasswd "*"
fixed attribute groupgid "*"
list groupmembers maps to "member"
}

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: ypldap.conf help - was: Samba4 and OpenBSD

[Theodore Wynnychenko]

On Mon, Jan 11, 2016 at 9:37 AM, Stuart Henderson  wrote:
> On 2016-01-11, Theodore Wynnychenko  wrote:
>> directory "ldap://DC1.samba.domain.com:389"; {
>
> afaik this just takes a hostname, not a URL.

Confirmed.

And see also:

http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client

Ciao!
David
-- 


Thanks for the advice.

So, replacing the 'H "ldap://DC1.samba.domain.com:389";' with '-h 
"DC1.samba.domain.com"' in ldapsearch works.

e.g.:  ldapsearch -x -h "DC1.samba.domain.com" -D "DOMAIN\Administrator" -w 
"password" -b "dc=samba,dc=domain,dc=com" "(objectClass=group)"

...
# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 4
# numReferences: 3
-

ldapsearch also works if I use '-h "localhost"' or '-h "127.0.0.1"' or '-h 
"xxx.yyy.zzz.aaa"'.

But, when I replace the directory line in ypldap.conf to:

directory "DC1.samba.domain.com"

or "localhost" or "127.0.0.1" or the IP address; and start ypldap -dv, I get:

# ypldap -dv
startup [debug mode]
configuration starting
applying configuration
connecting to directories
starting directory update
searching password entries
directory DC1.samba.domain.com errored out in search

and it hangs; after a manual break:

ldap client exiting
dns engine exiting
---

The "errored out in search" line changes based on the directory value from 
ypldap.conf.

I was wondering if there might be something "different" about the ldap server 
included with samba4; but 'man ldapsearch' confirms that it is not anything 
"special" from samba, but comes from OpenLDAP:

man ldapsearch
...
ACKNOWLEDGEMENTS
   OpenLDAP Software is developed and maintained by The OpenLDAP Project
   <http://www.openldap.org/>.  OpenLDAP Software is derived from
   University of Michigan LDAP 3.3 Release.

OpenLDAP 2.4.43   2015/11/30 LDAPSEARCH(1)


Therefore, it seems to me that if "this" ldapsearch can get information out of 
the 
samba ldap server, than ypldap should be able to as well.  Right?

A search for the error message above doesn't really lead me anywhere.  Any 
ideas 
what the error means?

Thanks again



cat ypldap.conf
...
# Global settings
domain   "samba.domain.com"
interval 3600

# Specify the maps that ypldap should provide
provide map  "passwd.byname"
provide map  "passwd.byuid"
provide map  "group.byname"

# Directory declaration
directory "DC1.samba.domain.com" {
binddn"DOMAIN\Administrator"
bindcred  "password"
basedn"dc=samba,dc=domain,dc=com"

# passwd maps configuration
passwd filter "(objectClass=posixAccount)"

attribute name maps to "uid"
fixed attribute passwd "*"
attribute uid maps to "uidNumber"
attribute gid maps to "gidNumber"
attribute home maps to "homeDirectory"
attribute gecos maps to "gecos"
# LDAP users are not interactive system users
fixed attribute shell "/sbin/nologin"
fixed attribute change "0"
fixed attribute expire "0"
fixed attribute class "default"

# group maps configuration
group filter "(objectClass=group)"

attribute groupname maps to "cn"
fixed attribute grouppasswd "*"
fixed attribute groupgid "*"
list groupmembers maps to "member"
}

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

ypldap.conf help - was: Samba4 and OpenBSD

[Theodore Wynnychenko]

Hello again:

First, I will try to document what I did to get samba up as an AD DC in the next
few days (I will note, as an older mail post stated, it takes a "LONG" time for
it to start up when the system boots).

But, I am hoping that someone can help me understand where my ypldap problem is.
As I said:

-
While it seems that I can get all the parts running, I am unable to pull account
information from samba's ldap server through ypldap (no domain accounts with
'getent passwd', only local accounts).  (I probably don't understand it well
enough to set up ypldap.conf correctly?)

-

So, all from one of the machines that is a DC (OpenBSD 5.9 GENERIC.MP#1783
amd640 with samba from packages (Version 4.1.22).

First, from the command line, I am able to get data from the ldap server
included with samba.  For example:

ldapsearch -x -H "ldap://DC1.samba.domain.com:389"; -D "DOMAIN\Administrator" -w
"password" -b "dc=samba,dc=domain,dc=com" "(objectClass=posixAccount)"

spits out a list of users to the terminal:
...
# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 4
# numReferences: 3

---

And:

ldapsearch -x -H "ldap://DC1.samba.domain.com:389"; -D "DOMAIN\Administrator" -w
"password" -b "dc=samba,dc=domain,dc=com" "(objectClass=group)"

gives me:
...
# search result
search: 2
result: 0 Success

# numResponses: 42
# numEntries: 38
# numReferences: 3

---

Using this, I tried to setup ypldap.conf like this:

# Global settings
domain   "samba.domain.com"
interval 3600

# Specify the maps that ypldap should provide
provide map  "passwd.byname"
provide map  "passwd.byuid"
provide map  "group.byname"

# Directory declaration
directory "ldap://DC1.samba.domain.com:389"; {
binddn"DOMAIN\Administrator"
bindcred  "password"
basedn"dc=samba,dc=domain,dc=com"

# passwd maps configuration
passwd filter "(objectClass=posixAccount)"

attribute name maps to "uid"
fixed attribute passwd "*"
attribute uid maps to "uidNumber"
attribute gid maps to "gidNumber"
attribute home maps to "homeDirectory"
attribute gecos maps to "gecos"
# LDAP users are not interactive system users
fixed attribute shell "/sbin/nologin"
fixed attribute change "0"
fixed attribute expire "0"
fixed attribute class "default"

# group maps configuration
group filter "(objectClass=group)"

attribute groupname maps to "cn"
fixed attribute grouppasswd "*"
fixed attribute groupgid "*"
list groupmembers maps to "member"
}


ypldap -n says the configuration is OK.

But, when I try to run it (after "domainname samba.domain.com" and "ypinit -m
samba.domain.com" and starting portmap):

# ypldap -dv

I get:
---
startup [debug mode]
configuration starting
applying configuration
connecting to directories
starting directory update
---
and the terminal hangs for longer than it took me to write this email
when I manually break it, I get:
---
ldap client exiting
dns engine exiting
---

It seems to me that I am doing something wrong in setting up ypldap.conf; but,
after spending most of the day (on and off) trying various configuration
changes, nothing has changed.  I did change of the group map configuration since
it appears (to me) that the samba ldap database does not provide GID for "group"
entries; but, I don't think that's the problem, is it?

Any ideas would be appreciated.

Thanks

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Samba4 and OpenBSD

[Theodore Wynnychenko]

Hello:
I am just wondering if anyone has any experience with Samba4 on OpenBSD.

I noticed that the package is available, and the included smb.conf file is set
up for a standalone server.

I have been tinkering with it, and have been able to get 2 separate machines
(OpenBSD) set up as AD DC's.

I have been able to "join" other machines (Windows 7 and a Mac) to the domain.

I was also able to set up, and join, another OpenBSD machine as a domain member
fileserver.

But this is where I am stuck.  While I can "see" the OpenBSD domain member from
the Windows machine, I cannot access anything on it.  The same is also true with
the 2 DC's.  When trying to access their shares, I get either RPC errors, or
user not authorized type errors.  Also, the one time I tried to login to the
domain on the windows machine, it seemed unable to create the roaming profile
(but this is just my faulty memory saying that).

I think (and now I am talking way beyond my understanding) that the issue is how
samba accounts interact (or don't) with local machine accounts.  It appears that
samba relies on winbind and nsswitch (which is unavailable in OpenBSD).

But, samba now runs its own ldap server, and I was trying to get that working
with ypldap (loosely from the advice at
http://www.kernel-panic.it/openbsd/pdc/pdc4.html#pdc-4.3 and
http://puffysecurity.com/wiki/ypldap.html).

While it seems that I can get all the parts running, I am unable to pull account
information from samba's ldap server through ypldap (no domain accounts with
'getent passwd', only local accounts).  (I probably don't understand it well
enough to set up ypldap.conf correctly?)

So, I am just wondering, before I waste any more time, is this even possible?
Or am I totally confused?

Thanks

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Error in package courier-imap-4.16.2 current Jan 1 amd64

[Theodore Wynnychenko]

Hello
I am not sure if this is the correct list, but...

I recently installed courier from packages.
After installing courier-imap; I tried to start it with "rcctl start
courier_imap", and it seemed to hang.
So, I tried running /usr/local/libexec/imapd.rc directly, and saw an endless
loop of "-".
Eventually, found in /usr/local/bin/makedat, near the end, it had:

get_access | docidr | yes - "$tmpfile" "$dstfile" || exit 1

I was confused by the "yes"; looked up the man page, and saw it was the
offending command.
It seems, the line should be:

get_access | docidr | /usr/local/libexec/makedatprog - "$tmpfile"
"$dstfile" || exit 1

or something like that.

I don't really know exactly "how" to submit a diff (I was barely able to
discover the problem); but I wanted to point this out.

Thanks
Ted

Ipsec tunnel not starting after update to recent snapshot

[Theodore Wynnychenko]

Hello

I recently updated to the 11-9 amd64 snapshot.
I had started following current, and, in general, seem to be doing fine.

But, after this last update, an IPSEC tunnel that I have been using
for months/years all of a sudden is not coming up with a system reboot.

I have not changed the ipsec.conf files in a really long time.  So, I
did not included them, but can if necessary.  The important point (I
think) is that I am using some FQDN with dynamic ip's.

What I have noticed is that the "dynamic" side of the tunnel seems to
be trying to connect, but the "passive" side refuses to accept the
connection.

On the passive side, I get this:
...
Nov 10 10:21:46 xxx isakmpd[12622]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Nov 10 10:21:46 xxx isakmpd[12622]: message_negotiate_sa: no
compatible proposal found
Nov 10 10:21:46 xxx isakmpd[12622]: dropped message from a.b.c.d port
500 due to notification type NO_PROPOSAL_CHOSEN
...
So, I understand this is because isakmpd is "falling back" to a
default 3DES setting, and the AES proposal from the dynamic side of
the tunnel is being rejected.

This led me to the dmesg on the passive host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 40: could not
parse host specification
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 41: could not
parse host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 42: could not
parse host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 43: could not
parse host specification
ipsecctl: Syntax error in config file: ipsec rules not loaded
...

So, I reload the ipsec.conf file manually - "ipsecctl -f
/etc/ipsec.conf" - and the tunnel goes up.

Now, on the dynamic host, there is no issue loading ipsec at boot -
dmesg for the dynamic host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
starting RPC daemons:.
...

As I said, no changes to ipsec.conf, and it was working last week
before the current snapshot.
I don't see anything in 'following current' about changes to ipsec
configuration.

Also, both ends of the tunnel point to the same resolver (openDNS)
during the boot up process.  If it was an issue with the resolver, I
would have expected a problem on both ends of the tunnel.

The confusing thing to me is why a line like: "ike passive esp from
$local_ip to $remote_gw srcid $local_id dstid $remote_id"
is failing during boot with "could not parse host specification."

But, a line like: "ike dynamic esp from $local_ip to $remote_gw srcid
$local_id dstid $remote_id"
works without an issue.

So, am I missing something, or is this a bug?  And, if so, what should I do?

Thanks
Ted W.

Ipsec tunnel not starting after update to recent snapshot

[Theodore Wynnychenko]

(( I have been trying to send this message all day - this is my third attempt --
I am sorry if it appears multiple times suddenly, but not sure why it is not
posting to the list... ))

Hello

I recently updated to the 11-9 amd64 snapshot.
I had started following current, and, in general, seem to be doing fine.

But, after this last update, an IPSEC tunnel that I have been using for
months/years all of a sudden is not coming up with a system reboot.

I have not changed the ipsec.conf files in a really long time.  So, I did not
included them, but can if necessary.  The important point (I think) is that I am
using some FQDN with dynamic ip's.

What I have noticed is that the "dynamic" side of the tunnel seems to be trying
to connect, but the "passive" side refuses to accept the connection.

On the passive side, I get this:
...
Nov 10 10:21:46 xxx isakmpd[12622]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Nov 10 10:21:46 xxx isakmpd[12622]: message_negotiate_sa: no compatible proposal
found
Nov 10 10:21:46 xxx isakmpd[12622]: dropped message from a.b.c.d port 500 due to
notification type NO_PROPOSAL_CHOSEN
...
So, I understand this is because isakmpd is "falling back" to a default 3DES
setting, and the AES proposal from the dynamic side of the tunnel is being
rejected.

This led me to the dmesg on the passive host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 40: could not parse
host specification
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 41: could not parse
host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 42: could not parse
host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 43: could not parse
host specification
ipsecctl: Syntax error in config file: ipsec rules not loaded
...

So, I reload the ipsec.conf file manually - "ipsecctl -f /etc/ipsec.conf" - and
the tunnel goes up.

Now, on the dynamic host, there is no issue loading ipsec at boot - dmesg for
the dynamic host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
starting RPC daemons:.
...

As I said, no changes to ipsec.conf, and it was working last week before the
current snapshot.
I don't see anything in 'following current' about changes to ipsec
configuration.

Also, both ends of the tunnel point to the same resolver (openDNS) during the
boot up process.  If it was an issue with the resolver, I would have expected a
problem on both ends of the tunnel.

The confusing thing to me is why a line like: "ike passive esp from $local_ip to
$remote_gw srcid $local_id dstid $remote_id"
is failing during boot with "could not parse host specification."

But, a line like: "ike dynamic esp from $local_ip to $remote_gw srcid $local_id
dstid $remote_id"
works without an issue.

So, am I missing something, or is this a bug?  And, if so, what should I do?

Thanks
Ted W.

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: httpd stops accepting connections after a few hours on current

[Theodore Wynnychenko]

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Edgar
Pettijohn
Sent: Friday, July 10, 2015 7:32 PM
To: misc@openbsd.org
Subject: Re: httpd stops accepting connections after a few hours on current

On 07/08/15 22:04, Theodore Wynnychenko wrote:
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Edgar
> Pettijohn
> Sent: Wednesday, July 08, 2015 8:52 PM
> To: misc@openbsd.org
> Subject: Re: httpd stops accepting connections after a few hours on current
>
> On 07/08/15 12:15, Henrik Friedrichsen wrote:
>> I have encountered the same problem as has the guy in [1]. Maybe it is
>> worth a bug report?
>>
>> Could this be related to FastCGI and exhaustion of some ressource?
>>
>> [1]: https://www.facebook.com/groups/2210554563/permalink/10153383131319564/
>>
> Have you run in debug mode?
>
> # httpd -dvvv
>
> --
>
> Hello
> Earlier today, I started it in debug mode.
> What I noticed is that for the first few hours there is nothing much of
> interest.
> A bunch of:
>
> http://server3.tldn.com 10.0.28.254 - - [08/Jul/2015:14:38:31 -0500] "POST
> /rpc/ClientApi HTTP/1.1" 301 0
> server http://server3.tldn.com, client 1552 (36 active), 10.0.28.254:65357 ->
> 10.0.28.131, https://server3.tldn.com/index.html (301 Moved Permanently)
>
> But, then I noticed (and I actually did notice this in the logs the other day,
> but was too stupid to understand that it was - I think now - important):
>
> server https://server2.tldn.com, client 2067 (63 active), 10.0.28.254:60330 ->
> 10.0.28.130:443, buffer event error
> server https://server2.tldn.com, client 1756 (72 active), 10.0.28.254:56005 ->
> 10.0.28.130:443, buffer event error
> server https://server2.tldn.com, client 1521 (58 active), 10.0.28.254:56066 ->
> 10.0.28.130:443, buffer event error
> server https://server2.tldn.com, client 2068 (63 active), 10.0.28.254:52350 ->
> 10.0.28.130:443, buffer event error

The httpd.conf you supplied doesn't show this server serving fastcgi is 
that true?  I'm testing a similiar config to see if I can duplicate the 
error.
>
> It appears that the "buffer event error"s aren't there for a few hours, then
> start, then increase, and eventually there is no more logging, and httpd is
not
> responsive.
>

Correct.  Only "server1" utilizes fastcgi.
"server2" and "server3" only have static content.

Re: httpd stops accepting connections after a few hours on current

[Theodore Wynnychenko]

From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Edgar
Pettijohn
Sent: Wednesday, July 08, 2015 8:52 PM
To: misc@openbsd.org
Subject: Re: httpd stops accepting connections after a few hours on current

On 07/08/15 12:15, Henrik Friedrichsen wrote:
> I have encountered the same problem as has the guy in [1]. Maybe it is
> worth a bug report?
>
> Could this be related to FastCGI and exhaustion of some ressource?
>
> [1]: https://www.facebook.com/groups/2210554563/permalink/10153383131319564/
>
Have you run in debug mode?

# httpd -dvvv

--

Hello
Earlier today, I started it in debug mode.
What I noticed is that for the first few hours there is nothing much of
interest.
A bunch of:

http://server3.tldn.com 10.0.28.254 - - [08/Jul/2015:14:38:31 -0500] "POST
/rpc/ClientApi HTTP/1.1" 301 0
server http://server3.tldn.com, client 1552 (36 active), 10.0.28.254:65357 ->
10.0.28.131, https://server3.tldn.com/index.html (301 Moved Permanently)

But, then I noticed (and I actually did notice this in the logs the other day,
but was too stupid to understand that it was - I think now - important):

server https://server2.tldn.com, client 2067 (63 active), 10.0.28.254:60330 ->
10.0.28.130:443, buffer event error
server https://server2.tldn.com, client 1756 (72 active), 10.0.28.254:56005 ->
10.0.28.130:443, buffer event error
server https://server2.tldn.com, client 1521 (58 active), 10.0.28.254:56066 ->
10.0.28.130:443, buffer event error
server https://server2.tldn.com, client 2068 (63 active), 10.0.28.254:52350 ->
10.0.28.130:443, buffer event error

It appears that the "buffer event error"s aren't there for a few hours, then
start, then increase, and eventually there is no more logging, and httpd is not
responsive.

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

httpd stops accepting connections after a few hours on current

[Theodore Wynnychenko]

Hello

On current:
OpenBSD 5.8-beta (GENERIC.MP) #1125: Fri Jul  3 20:54:45 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

System using 2 aliases on one interface:
ifconfig em0
em0: flags=8843 mtu 1500
lladdr 00:25:90:de:f8:67
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 10.0.28.129 netmask 0xff00 broadcast 10.0.28.255
inet 10.0.28.130 netmask 0x
inet 10.0.28.131 netmask 0x


HTTPD listening on all three IP's with different content:
cat /etc/httpd.conf

http_ip="10.0.28.129"

types {
include "/usr/share/misc/mime.types"
}

server "server1.tldn.com" {
listen on $http_ip port 80
connection max requests 100
root "/htdocs"
directory index index.html
block return 301 "https://server1.tldn.com$REQUEST_URI";
}

server "server1.tldn.com" {
listen on $http_ip tls port 443
tls certificate "/etc/ssl/server-129.crt"
tls key "/etc/ssl/private/server-129.key"
connection max requests 100
root "/htdocs"
directory index index.html
location "/cgi-bin/*" {
fastcgi
root "/"
}
}

server "server2.tldn.com" {
listen on 10.0.28.130 port 80
connection max requests 100
root "/htdocs-130"
directory index index.html
block return 301 "https://server2.tldn.com/default.html";
}

server "server2.tldn.com" {
listen on 10.0.28.130 tls port 443
tls certificate "/etc/ssl/server-130.crt"
tls key "/etc/ssl/private/server-130.key"
connection max requests 100
root "/htdocs-130"
directory index index.html
}

server "server3.tldn.com" {
listen on 10.0.28.131 port 80
connection max requests 100
root "/htdocs-131"
directory index index.html
block return 301 "https://server3.tldn.com/index.html";
}

server "server3.tldn.com" {
listen on 10.0.28.131 tls port 443
tls certificate "/etc/ssl/server-131.crt"
tls key "/etc/ssl/private/server-131.key"
connection max requests 100
root "/htdocs-131"
directory index index.html
}


The httpd daemon starts up without an issue and runs without a problem for a few
hours (I have not actually timed it, but it goes for about 6-8 hours), and then
just stops responding.
This is true on all three of the ip's that it is listening on; and whether or
not the original connection is to port 80 or 443.

The access log show all connections until (I presume) the daemon stops answering
connections.

I have tried combining all the ssl certs into one (with a lot of alternative
names), but that did not make a difference.

A simple "rcctl restart httpd" brings the server back up for a few hours.

I would be happy to investigate this more, but I don't know where to go.
Similarly, I don't know what other information I could provide to help diagnose
the problem.

Any help would be great.

Thanks - ted

Mount point for ntfs_3g mounted drive "missing" after failed umount

[Theodore Wynnychenko]

Hello

I have been trying to use the ntfs_3g fuse package to get write access to an
ntfs drive.

While I have had no issues mounting the drive and writing to it, occasionally I
have problems when trying to unmount the drive.

Basically, I want to make a more "portable" copy of my data.  I have an external
eSata drive.  The drive is NOT mounted during boot.

I have a cron job that runs a script and makes a copy of my data to the external
drive.  The script is simple:

---
#!/bin/sh
/usr/local/bin/ntfs-3g /dev/sd2i /home/backup
/usr/local/bin/rsync --recursive --archive --delete /home/data/
/home/backup/data
/sbin/umount /home/backup
---

It appears that when there aren't many new or changed files, everything is fine.
However, if there is a "lot" of new data to copy, the umount command at the end
returns an error, and the mount point for the drive is "missing."  Running the
commands manual produces the same error.  E.g.:

# /usr/local/bin/ntfs-3g /dev/sd2i /home/backup
<< no errors >>
# /usr/local/bin/rsync --recursive --archive --delete /home/data/
/home/backup/data
<< no errors >>
# /sbin/umount /home/backup
umount: /home/backup: Device busy

But, if I check with df, the "fusefs" mounted as /home/backup is gone.
And:
# ls /home/backup/
ls: /home/backup/: No such file or directory

But:
# mkdir /home/backup
mkdir: /home/backup: File exists

Reboot the system, and the missing mount point (/home/backup) reappears.

I was thinking that maybe this has something to do with the writing of data to
the ntfs volume not being complete when the umount command is executed.  So, I
did add a "sleep 600" into the shell script; and it seemed to unmount cleanly
(although, I am not sure if it was the time delay, or just a lack of new data
for rsync to copy).

However, that doesn't address the underlying issue.
Also I don't understand why the mount point being used by ntfs_3g would be
missing with "ls" but exists with "mkdir".
I have gone through the package's man pages and could find nothing that appears
relevant.

I would appreciate any ideas on how to proceed.

Thanks

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

Hello
I guess I was a bit remiss in posting a conclusion to the thread I started.
Sorry about that.

In any case, Joel S (jsing@) and I corresponded about this issue, and I did get
a resolution.

Here is a copy of the final message:

---

From: Joel Sing
Sent: Sunday, March 29, 2015 5:13 AM
Subject: Re: httpd tls - what am i missing?

Okay, I've at least tracked down the source of the problem - your server.pem 
file contains the text version of the certificate followed by the PEM encoded 
version. The combined size seems to be triggering an issue in httpd - 
removing the text version and starting with the BEGIN CERTIFICATE line makes 
the certificate/key work... now to find out what is actually happening!

---

And, that's exactly what I did.  I can't speak intelligently on this, but it
seems that (at least, in my case) the size of the certificate (text included)
was too large, and led to some sort of problem within httpd.

By removing the text parts of the certificate file, and leaving only the actual
certificate in the file, lets httpd start up with https enabled; and it works
just fine.

For me, this is totally fine.  Coupled with the simple block/return option and
the $REQUEST_URI variable, I can pretty seamlessly redirect all http connections
to https.

Ted


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Henrik
Friedrichsen
Sent: Monday, May 11, 2015 8:30 AM
To: misc@openbsd.org
Subject: Re: httpd tls - what am i missing?

I've got the same problem OP has with a freshly generated key and signed
cert from wosign.com on OpenBSD 5.7-stable.

The cert/key work fine with nginx, but with httpd the client simply
times out when trying to open a session with the server.

OpenSSL s_client stops right after connecting to the server:

% openssl s_client -connect $host:443
CONNECTED(0003)

Anything else we can give you for debugging?

Thanks
Henrik

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

> And, finally:
> 
> 4. they DO NOT work when loaded by httpd
> 
> I will be the first to admit that I don't really "know" much about
> public key cryptography and how openssl implements things.  But, being
> simple, it seems to me that there are really only two possibilities.
> 
> Either apache, pound, and openssl s_server are all flawed and are
> incorrectly using an invalid certificate/key pair for encryption; or
> there is a problem in httpd and how it deals with certificates and
> https.
> 
> I will try things again tomorrow (later today) and see if I can get
> any info with tcpdump.
> 
> If there is anything else to try, please let me know.

Please try 's_client' as I had suggested in an earlier email - it's not
the certificates themselves you should be testing (i.e. with 's_server'
and a web browser) but certificates/keys *with* httpd and a client which
will give you meaningful output ('s_client').

Like I had also mentioned earlier - I had generated a new certificate
and a key and tested it on one of my machines and it all works just
fine.

Last, but not least - if you hadn't done so already,please make sure you
are running the latest snapshot.

Regards,

Raf

--

First, I installed the most recent snapshot:

OpenBSD 5.7-current (GENERIC.MP) #896: Thu Mar 26 14:56:12 MDT 2015
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

(sorry about the other dmesg snip - I pulled the snip off the top, and I was 
not aware that on this system the message buffer
survives a reboot)

First, I started httpd as "httpd -d -v -v -v -v -v -v -v":
The terminal spits back:
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
server_tls_load_keypair: using certificate /etc/ssl/server.crt
server_tls_load_keypair: using private key /etc/ssl/private/server.key
socket_rlimit: max open files 1024
server_privinit: adding server default
server_privinit: adding server default
server_launch: running server default
server_launch: running server default
server_launch: running server default

then, on an second terminal, I tried connecting with:  openssl s_client 
-connect 127.0.0.1:443

on the second (s_client) terminal, I get:
CONNECTED(0003)

And that's it.

On the first (httpd) terminal, there is no output of any kind.
So, I waited about 10 seconds, nothing happened, and I shut down httpd.  The 
terminal says:
^C
logger exiting, pid 14644
server exiting, pid 21849
server exiting, pid 18400
server exiting, pid 10463
parent terminating, pid 9974

Then, I opened a s_server instance:  openssl s_server -accept 443 -www -cert 
/etc/ssl/server.crt -key /etc/ssl/private/server.key
It gives me:
Using auto DH parameters
Using default temp ECDH parameters
ACCEPT

And on the second terminal I try s_client again:  openssl s_client -connect 
127.0.0.1:443
And it connects.  Here is the output (I XXX'ed some of the certificate info):

openssl s_client -connect 127.0.0.1:443
CONNECTED(0003)
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
   i:/C=US/ST=XXX/L=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
Server certificate
-BEGIN CERTIFICATE-
MIIH6zCCBdOgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBljELMAkGA1UEBhMCVVMx
ETAPBgNVBAgMCElsbGlub2lzMREwDwYDVQQHDAhXaW5uZXRrYTEUMBIGA1UECgwL

<... more certificate block ...>

6RUcfqhZ211+IvAnJVYAsz+1hzLGL57Ppct6HHf41xl36WakU+J3jlpVpIaA8jHh
5ThHy8QM1jeo90XENClcYD2W1OHD75Hchn5pEbA8BfpKJpvTwsosIFdZazWvHHO8
CU8P6Syj53sEw0MeooEt
-END CERTIFICATE-
subject=/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
issuer=/C=US/ST=XXX/L=XX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
No client certificate CA names sent
---
SSL handshake has read 2933 bytes and written 438 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-CHACHA20-POLY1305
Session-ID: FC424D25B814891FD0F881B1E20C6367547803E189FF2EB1D337201491CB078A
Session-ID-ctx:
Master-Key: 
ADB4316898847559BAF6EE1188F1FCFAB0D741D36A73226D023458247CE26523F74EABE327755A7A12CFB9242AAA9413
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 8c 5f 29 1e 1e a2 9f e3-f8 3e 62 1f 9f 10 ad 5c   ._)..>b\
0010 - be 8c 47 51 98 4c 93 66-bb a9 51 70 93 37 b3 4e   ..GQ.L.f..Qp.7.N
0020 - 16 fc 38 fa f6 ea 37 73-9c d4 82 e9 1a 30 f9 44   ..8...7s.0.D
0030 - eb 5e 4b 4f b2

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

> And, finally:
> 
> 4. they DO NOT work when loaded by httpd
> 
> I will be the first to admit that I don't really "know" much about
> public key cryptography and how openssl implements things.  But, being
> simple, it seems to me that there are really only two possibilities.
> 
> Either apache, pound, and openssl s_server are all flawed and are
> incorrectly using an invalid certificate/key pair for encryption; or
> there is a problem in httpd and how it deals with certificates and
> https.
> 
> I will try things again tomorrow (later today) and see if I can get
> any info with tcpdump.
> 
> If there is anything else to try, please let me know.

Please try 's_client' as I had suggested in an earlier email - it's not
the certificates themselves you should be testing (i.e. with 's_server'
and a web browser) but certificates/keys *with* httpd and a client which
will give you meaningful output ('s_client').

Like I had also mentioned earlier - I had generated a new certificate
and a key and tested it on one of my machines and it all works just
fine.

Last, but not least - if you hadn't done so already,please make sure you
are running the latest snapshot.

Regards,

Raf

--

First, I installed the most recent snapshot:

OpenBSD 5.7-current (GENERIC.MP) #896: Thu Mar 26 14:56:12 MDT 2015
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

(sorry about the other dmesg snip - I pulled the snip off the top, and I was 
not aware that on this system the message buffer
survives a reboot)

First, I started httpd as "httpd -d -v -v -v -v -v -v -v":
The terminal spits back:
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
server_tls_load_keypair: using certificate /etc/ssl/server.crt
server_tls_load_keypair: using private key /etc/ssl/private/server.key
socket_rlimit: max open files 1024
server_privinit: adding server default
server_privinit: adding server default
server_launch: running server default
server_launch: running server default
server_launch: running server default

then, on an second terminal, I tried connecting with:  openssl s_client 
-connect 127.0.0.1:443

on the second (s_client) terminal, I get:
CONNECTED(0003)

And that's it.

On the first (httpd) terminal, there is no output of any kind.
So, I waited about 10 seconds, nothing happened, and I shut down httpd.  The 
terminal says:
^C
logger exiting, pid 14644
server exiting, pid 21849
server exiting, pid 18400
server exiting, pid 10463
parent terminating, pid 9974

Then, I opened a s_server instance:  openssl s_server -accept 443 -www -cert 
/etc/ssl/server.crt -key /etc/ssl/private/server.key
It gives me:
Using auto DH parameters
Using default temp ECDH parameters
ACCEPT

And on the second terminal I try s_client again:  openssl s_client -connect 
127.0.0.1:443
And it connects.  Here is the output (I XXX'ed some of the certificate info):

openssl s_client -connect 127.0.0.1:443
CONNECTED(0003)
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = XXX, O = XXX, OU = XXX, L = XXX, CN = XXX, emailAddress = 
XXX
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
   i:/C=US/ST=XXX/L=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
Server certificate
-BEGIN CERTIFICATE-
MIIH6zCCBdOgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBljELMAkGA1UEBhMCVVMx
ETAPBgNVBAgMCElsbGlub2lzMREwDwYDVQQHDAhXaW5uZXRrYTEUMBIGA1UECgwL

<... more certificate block ...>

6RUcfqhZ211+IvAnJVYAsz+1hzLGL57Ppct6HHf41xl36WakU+J3jlpVpIaA8jHh
5ThHy8QM1jeo90XENClcYD2W1OHD75Hchn5pEbA8BfpKJpvTwsosIFdZazWvHHO8
CU8P6Syj53sEw0MeooEt
-END CERTIFICATE-
subject=/C=US/ST=XXX/O=XXX/OU=XXX/L=XXX/CN=XXX/emailAddress=XXX
issuer=/C=US/ST=XXX/L=XX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX
---
No client certificate CA names sent
---
SSL handshake has read 2933 bytes and written 438 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-CHACHA20-POLY1305
Session-ID: FC424D25B814891FD0F881B1E20C6367547803E189FF2EB1D337201491CB078A
Session-ID-ctx:
Master-Key: 
ADB4316898847559BAF6EE1188F1FCFAB0D741D36A73226D023458247CE26523F74EABE327755A7A12CFB9242AAA9413
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 8c 5f 29 1e 1e a2 9f e3-f8 3e 62 1f 9f 10 ad 5c   ._)..>b\
0010 - be 8c 47 51 98 4c 93 66-bb a9 51 70 93 37 b3 4e   ..GQ.L.f..Qp.7.N
0020 - 16 fc 38 fa f6 ea 37 73-9c d4 82 e9 1a 30 f9 44   ..8...7s.0.D
0030 - eb 5e 4b 4f b2

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

> On Thu, 26 Mar 2015 08:30:23 +0100
> mxb wrote:
>
>> >
>> > Thank you for the suggestion.  I was not aware of "pound."
>>
>> I?d rather go for relayd. Which is out of the box. No need to install ?yet
>> another port and make sure it is up2date?.
>
> httpd is based on relayd code which would reduce the scope of the test
> (a cluestick).
>
>>> When I try "https://10.0.128.67/index.html"; - I get a nice message from
>>> firefox asking me to accept a problem certificate (this was expected,
>>> the certificate is the "correct" one), and when I do accept the
>>> certificate, I get the index page.
>
>>> So, I am not sure what is wrong, but it appears httpd is not responding
>>> to https requests, even with the "listen on tls" line in the
>>> configuration file.
>
>>> Is there anything for me to look at/consider in trying to correct this?
>
> I don't understand what you are saying by '"correct" one' but to me this
> suggests you have issues even with pound and perhaps I would try
> another browser or firefox on another client and try another
> certificate perhaps from another CA or install a newer snapshot or
> re-install a release before wondering if there is an issue with httpd
> or libressl whilst monitoring the list to see if anyone else has an
> issue?
>
> Thankfully re-install on OpenBSD is super quick but you do have to
> follow www.openbsd.org/current.html for snapshots and I think
> www.openbsd.org/plus.html for release upgrades (4.5 -> 4.6 etc.)
>
>

Hello:

I started httpd as:  httpd -d -v -v -v -v -v -v -v
And I see:

startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
server_tls_load_keypair: using certificate /etc/ssl/server.crt
server_tls_load_keypair: using private key /etc/ssl/private/server.key
socket_rlimit: max open files 1024
server_privinit: adding server default
server_privinit: adding server default
server_launch: running server default
server_launch: running server default
server_launch: running server default

but, if I try to connect using https, there is no output on the terminal 
indicating that httpd is doing anything at all.
Ctrl-c to kill the server gives:

^C
logger exiting, pid 28447
server exiting, pid 23445
server exiting, pid 20653
server exiting, pid 12690
parent terminating, pid 29581


So, it seems that httpd does, in fact, see the cert and key, but does nothing 
with them.
(the cert is PEM encoded)

So, I also tried:

openssl s_server -accept 443 -www -cert /etc/ssl/server.crt -key 
/etc/ssl/private/server.key

and then connected to the machine with a browser.

This connection works without an issue.

The output to the browser from openssl s_server is:


s_server -accept 443 -www -cert /etc/ssl/server.crt -key 
/etc/ssl/private/server.key 
Secure Renegotiation IS supported
Ciphers supported in s_server binary
TLSv1/SSLv3:ECDHE-ECDSA-CHACHA20-POLY1305TLSv1/SSLv3:ECDHE-RSA-CHACHA20-POLY1305
TLSv1/SSLv3:DHE-RSA-CHACHA20-POLY1305TLSv1/SSLv3:ECDHE-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDHE-ECDSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDHE-RSA-AES256-SHA384  
TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA384TLSv1/SSLv3:ECDHE-RSA-AES256-SHA 
TLSv1/SSLv3:ECDHE-ECDSA-AES256-SHA   TLSv1/SSLv3:DHE-DSS-AES256-GCM-SHA384
TLSv1/SSLv3:DHE-RSA-AES256-GCM-SHA384TLSv1/SSLv3:DHE-RSA-AES256-SHA256
TLSv1/SSLv3:DHE-DSS-AES256-SHA256TLSv1/SSLv3:DHE-RSA-AES256-SHA   
TLSv1/SSLv3:DHE-DSS-AES256-SHA   TLSv1/SSLv3:GOST2012256-GOST89-GOST89
TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA256TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA256
TLSv1/SSLv3:DHE-RSA-CAMELLIA256-SHA  TLSv1/SSLv3:DHE-DSS-CAMELLIA256-SHA  
TLSv1/SSLv3:GOST2001-GOST89-GOST89   TLSv1/SSLv3:ECDH-RSA-AES256-GCM-SHA384
TLSv1/SSLv3:ECDH-ECDSA-AES256-GCM-SHA384TLSv1/SSLv3:ECDH-RSA-AES256-SHA384   
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHA384 TLSv1/SSLv3:ECDH-RSA-AES256-SHA  
TLSv1/SSLv3:ECDH-ECDSA-AES256-SHATLSv1/SSLv3:AES256-GCM-SHA384
TLSv1/SSLv3:AES256-SHA256TLSv1/SSLv3:AES256-SHA   
TLSv1/SSLv3:CAMELLIA256-SHA256   TLSv1/SSLv3:CAMELLIA256-SHA  
TLSv1/SSLv3:ECDHE-RSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDHE-ECDSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA256  TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA256
TLSv1/SSLv3:ECDHE-RSA-AES128-SHA TLSv1/SSLv3:ECDHE-ECDSA-AES128-SHA   
TLSv1/SSLv3:DHE-DSS-AES128-GCM-SHA256TLSv1/SSLv3:DHE-RSA-AES128-GCM-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-SHA256TLSv1/SSLv3:DHE-DSS-AES128-SHA256
TLSv1/SSLv3:DHE-RSA-AES128-SHA   TLSv1/SSLv3:DHE-DSS-AES128-SHA   
TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA256TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA256
TLSv1/SSLv3:DHE-RSA-CAMELLIA128-SHA  TLSv1/SSLv3:DHE-DSS-CAMELLIA128-SHA  
TLSv1/SSLv3:ECDH-RSA-AES128-GCM-SHA256TLSv1/SSLv3:ECDH-ECDSA-AES128-GCM-SHA256
TLSv1/SSLv3:ECDH-RSA-AES128-SHA256   TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA256 
TLSv1/SSLv3:ECDH-RSA-AES128-SHA  TLSv1/SSLv3:ECDH-ECDSA-AES128-SHA
TLSv1/SSLv3:AES128-GCM-SHA256TLSv1/SSLv3:AES128-SHA256
TLSv1/SSLv3:AES128-SHA   TLSv1/SSLv3:

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

Quoting Kevin Chadwick :


On Thu, 26 Mar 2015 08:30:23 +0100
mxb wrote:


>
> Thank you for the suggestion.  I was not aware of "pound."

I?d rather go for relayd. Which is out of the box. No need to install ?yet
another port and make sure it is up2date?.


httpd is based on relayd code which would reduce the scope of the test
(a cluestick).


When I try "https://10.0.128.67/index.html"; - I get a nice message from
firefox asking me to accept a problem certificate (this was expected,
the certificate is the "correct" one), and when I do accept the
certificate, I get the index page.



So, I am not sure what is wrong, but it appears httpd is not responding
to https requests, even with the "listen on tls" line in the
configuration file.



Is there anything for me to look at/consider in trying to correct this?


I don't understand what you are saying by '"correct" one' but to me this
suggests you have issues even with pound and perhaps I would try
another browser or firefox on another client and try another
certificate perhaps from another CA or install a newer snapshot or
re-install a release before wondering if there is an issue with httpd
or libressl whilst monitoring the list to see if anyone else has an
issue?

Thankfully re-install on OpenBSD is super quick but you do have to
follow www.openbsd.org/current.html for snapshots and I think
www.openbsd.org/plus.html for release upgrades (4.5 -> 4.6 etc.)




Hello:
I am sorry, I have been unable to try some of the suggestions today as
of yet.  I am a bit busy at work, and probably won't be able to look
at this until tomorrow.
However, I wanted to clarify my comment.
When I said "correct" one in regards to the certificate working with
https and pound, my comment was intended only to imply that any
"issues" were purposefully induced ones.

As I said, the new machine with the httpd issue is going to replace
another machine.  To make my like easy going forward, I installed a
certificate for the machine as it will be in the future, not as it is
now.
So, when firefox connects with https to the machine, it is connecting
to 10.0.128.67, but gets a certificate back saying 10.0.128.100; and
warns me of the inconsistency.  This is a completely expected issue,
and I do verify that the "10.0.128.100" certificate is being presented
form the "10.0.128.67" machine.

There was NO other problem using pound.  With pound, as well as a
https connection to the "old" machine with the "new" certificate, the
browser opens the https connection with no problems.  Also, as I noted
yesterday, the browser's hanging behaivor stops the second afer I kill
the httpd process.

I have also tried to connect with IE from a windows machine, and get
the same results (http is ok, https hangs).

I missed the "-d -v" flags for httpd (i feel a bit stupid, it's right
there in the man page), and was going to fire up httpd and see what
happens when the secure connection is initiated.  Hopefully, tomorrow.

Thanks
Ted

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

Subject: Re: httpd tls - what am i missing?

On 3/25/15, Theodore Wynnychenko  wrote:
>
> Is there anything for me to look at/consider in trying to correct this?
>
> Thanks
> Ted
>
>

Here is a working example from my server.  Note that I don't bother
with port 80. You might want to try without the port 80 listen line to
rule out some config parsing issue.  Also the tls options are in a {}
block and make sure your cert and key have secure permissions.

server "mydomain.com" {
listen on $ext_addr tls port 443
alias "www.mydomain.com"

tls {
certificate "/etc/ssl/mydomain.com.crt"
key "/etc/ssl/private/mydomain.com.key"
}

# Set max upload size to 513M (in bytes)
connection max request body 537919488

root "/htdocs"
directory index index.html

}



I tried modifying my httpd.conf to only include the only the https server (and 
changed the tls options as shown above); but this did
not allow me to connect with https.

The permissions on the cert is 644 root.wheel, and the key is 400 root.wheel.

I did notice that when I try to connect, and firefox is "hanging" (little 
spinning wheel going round and round), if I kill the httpd
parent process on the server, then firefox (within a second or so) drops into 
an "unable to connect" page.

It seems to me that something odd is happening within httpd - like it starts to 
process the request, but refuses to complete it.

Are there any restrictions on the key size or certificate properties (like 
alternative names) for use with httpd? (I don't see
anything in the man pages)

Is there any way to get more verbose logs of what httpd is doing/waiting for? 
(I don't see anything in the man pages)

Thanks again
Ted

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

On Wed, 25 Mar 2015 12:40:11 -0500

>> I took the server.key and server.crt files to an older machine (actually, 
>> the one I am trying to replace) that is running 4.9 (I
>> think) and apache.
>
> On Wednesday, March 25, 2015 1:52 PM:
>
>Why not see if you can get it working with pound from packages/ports
>(very quick) on the new machine and that will help you work out if it's
>related to httpd or something else?

Thank you for the suggestion.  I was not aware of "pound."

Now I am.  So, I installed pound.
Setup a basic pound config.
--- 
User "_pound"
Group "_pound"
RootJail "/var/empty"

# 0=none, 1=normal, 2=extended, 3=CLF, etc.
LogLevel 1

ListenHTTPS
Address 10.0.128.67
Port443
Cert"/etc/ssl/server.crt.pound"
Service
BackEnd
Address 127.0.0.1
Port 80
End
End
End


Then, I combined the server.crt and server.key files into one ->  
server.crt.pound (pound requires the key and cert in the same
file, I figured that out pretty quick).

Removed the "listen on * tls port 443" line from httpd.conf
Stopped httpd.
Started pound.
Restarted httpd.

And...

When I try "http://10.0.128.67/index.html"; - I get the index page.
When I try "https://10.0.128.67/index.html"; - I get a nice message from firefox 
asking me to accept a problem certificate (this was
expected, the certificate is the "correct" one), and when I do accept the 
certificate, I get the index page.

So, I am not sure what is wrong, but it appears httpd is not responding to 
https requests, even with the "listen on tls" line in the
configuration file.

Is there anything for me to look at/consider in trying to correct this?

Thanks
Ted

Re: httpd tls - what am i missing?

[Theodore Wynnychenko]

Hello again:
I am still having no luck with https and the new httpd server.
I am sorry if this is something stupid, but I would really appreciate a whack 
with the clue stick.

As I said originally, http connections work fine with openbsd-current, but 
https connections never connect.

I have tried a number of things.

First, I changed my httpd.conf to explicitly point to the server crt and key.

types {
include "/usr/share/misc/mime.types"
}

server "default" {
listen on * port 80
listen on * tls port 443
tls certificate "/etc/ssl/server.crt"
tls key "/etc/ssl/private/server.key"
connection max requests 100
root "/htdocs"
directory no index
}
-

No difference:  http connects, https browser just waiting.

I removed the "tls" from the conf file, so:  "listen on * port 443"

When I do that, and try using https to connect, Firefox gives me a 
"ssl_error_rx_record_too_long" response (but, at least it's not
hanging).  Also, the access.log file does record the "failed" https attempt:
---
default 10.0.128.10 - - [25/Mar/2015:12:18:58 -0500] " " 400 0
---
As I noted before, with tls enabled, there are no records in either access.log 
or error.log files.

So, I checked the certificate:
openssl x509 -text -noout -in /etc/ssl/server.crt

and I get:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption


All seems fine.

I took the server.key and server.crt files to an older machine (actually, the 
one I am trying to replace) that is running 4.9 (I
think) and apache.  Put the "new" certificate and key in the proper places, and 
was able to open an https connection to that
machine, and was able to confirm that the new certificate was the one being 
presented and works.

So, I don't know what the issue may be.
I would really appreciate some (small amount of) direction.

After all, this is an openbsd only kind of question, I don't even know where 
else I could ask.
If there is any other information that is needed, please let me know.

Thanks again;
Ted


-
>On Mar 22, 2015
>
>Hello
>I think I missing something very obvious, but I have been struggling with this 
>for a while, and hope that someone will point out my oversight.
>
>
>Running current:
>OpenBSD 5.7-current (RAMDISK_CD) #818: Wed Mar 18 18:59:52 MDT 2015
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>
>httpd up and running:
>
>ps ax:
>1235 ??  Is  0:00.01 httpd: parent (httpd)
> 1598 ??  I   0:00.00 httpd: logger (httpd)
>27922 ??  I   0:00.01 httpd: server (httpd)
> 2020 ??  I   0:00.01 httpd: server (httpd)
>19391 ??  I   0:00.01 httpd: server (httpd)
>
>Using this configuration file - httpd.conf:
>
>http_ip="10.0.128.67"
>
>types {
>include "/usr/share/misc/mime.types"
>}
>
>server "defualt" {
>listen on $http_ip port 80
>listen on $http_ip tls port 443
>connection max requests 100
>root "/htdocs"
>directory no index
>}
>
>
>When I try to connect using firefox to: http://10.0.128.67/index.html - 
>everything is fine.
>When I try to connect using firefox to: https://10.0.128.67/index.html - 
>firefox just hangs/waiting.
>
>Certificate and key installed in default locations:
>ls -lah /etc/ssl/private/server.key:
>-rw---  1 root  wheel   3.2K Feb 16 19:57 /etc/ssl/private/server.key
>
>ls -lah /etc/ssl/server.crt:
>-rw-r--r--  1 root  wheel   8.5K Mar 12 12:04 /etc/ssl/server.crt
>
>No error messages in the logs for httpd.
>No error messages in /var/www/logs/error.log
>No record of connections when https connection requested in 
>/var/www/logs/access.log
>
>I must be missing something obvious; but at this point I think I have been 
>staring at the trees so long I can't see the forest.
>
>Thanks
>Ted

httpd tls - what am i missing?

[Theodore Wynnychenko]

Hello
I think I missing something very obvious, but I have been struggling with this 
for a while, and hope that someone will point out my
oversight.

Running current:
OpenBSD 5.7-current (RAMDISK_CD) #818: Wed Mar 18 18:59:52 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

httpd up and running:

ps ax:
1235 ??  Is  0:00.01 httpd: parent (httpd)
 1598 ??  I   0:00.00 httpd: logger (httpd)
27922 ??  I   0:00.01 httpd: server (httpd)
 2020 ??  I   0:00.01 httpd: server (httpd)
19391 ??  I   0:00.01 httpd: server (httpd)

Using this configuration file - httpd.conf:

http_ip="10.0.128.67"

types {
include "/usr/share/misc/mime.types"
}

server "defualt" {
listen on $http_ip port 80
listen on $http_ip tls port 443
connection max requests 100
root "/htdocs"
directory no index
}


When I try to connect using firefox to: http://10.0.128.67/index.html - 
everything is fine.
When I try to connect using firefox to: https://10.0.128.67/index.html - 
firefox just hangs/waiting.

Certificate and key installed in default locations:
ls -lah /etc/ssl/private/server.key:
-rw---  1 root  wheel   3.2K Feb 16 19:57 /etc/ssl/private/server.key

ls -lah /etc/ssl/server.crt:
-rw-r--r--  1 root  wheel   8.5K Mar 12 12:04 /etc/ssl/server.crt

No error messages in the logs for httpd.
No error messages in /var/www/logs/error.log
No record of connections when https connection requested in 
/var/www/logs/access.log

I must be missing something obvious; but at this point I think I have been 
staring at the trees so long I can't see the forest.

Thanks
Ted

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

HTTPD - HTTP->HTTPS redirection?

[Theodore Wynnychenko]

Hello
Recently, there was a thread entitled "Best way forward w.r.t.
apache/nginx/httpd?"

My needs for an http server are pretty low; and I was planning on using the
new in-house httpd included in current.

The only "fancy" thing I like is having http requests redirect to https.
This is actually completely unnecessary for my uses, but, I would like to
have it if I can.

I see a note in the change log from 5.5 to 5.6
(http://www.openbsd.org/plus56.html) which states:  "Redirect httpd(8) to
https:// if SSL/TLS is enabled."  However, I do not see any other reference
to this behavior in the man pages.

I am not sure exactly what that note means.   Does it mean that a connection
to port 80 (e.g. "listen on * port 80") will be automatically redirected to
https on port 443 if a complementary listen statement exists (e.g. "listen
on * tls port 443")?  Does it mean something different?

I guess, I just don't know, and would like to understand what will happen
before moving to the new httpd.

Thanks
Ted

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]

Basic question about following current

[Theodore Wynnychenko]

Hello

I am thinking of taking the plunge and following current.
It all seems straightforward.
I have looked at the FAQ's and other sources.
I understand that it goes like this (simplistically):

Get a new snapshot from mirror
Sysmerge etc/xetc
Cp bsd.rd to /
Boot into bsd.rd
Follow upgrade
Reboot
Sysmerge again to be sure
Update packages (pkg_add -ui)

So far, got it.
But, I am confused about ports.
If I have something build from ports, I would want to update that as well,
right?

I see that there is a "ports.tar.gz" in the snapshot directory.  But, in the
FAQ it says: "You must make sure your kernel, 'userland' (the supporting
utilities and files) and ports tree are all in sync."

There is no src, sys, or xenocara in the snapshot directory (I saw the
explanation in the FAQ or somewhere, and it makes total sense).

Therefore, my question is: if I am trying to update a port (using "make
update" from a local ports tree), should I use the "ports.tar.gz" that is in
the snapshot directory by uncompressing it over the top of the ports tree I
already have?  Or, should I download the current source and ports trees
using anoncvs, and do the "make update" from the most current ports tree in
anoncvs?  Or, is either choice ok?

I guess this comes down to a fundamental not understanding of exactly
whether or not the local ports tree needs access to the current source tree
or not, when trying to build or update a port.

Thanks
Ted

Problem with dhclient and resolv.conf

[Theodore Wynnychenko]

Hello:

Using 4.6 (updating to 4.7 is my next project), I have set up two
machines at
two separate sites to that create an ipsec tunnel between them.

Both machines get a dynamic ip address for their internet connection from
the
ISP (comcast at one end, AT+T at the other).

Both machines have the /etc/dhclient.conf file modified to include:

request subnet-mask, broadcast-address, time-offset, routers;

The line above is the ONLY line that is not a comment in either
dhclient.conf
file.

Both machines have /etc/hostname.sk0 (the world facing interface) set up
as:

dhcp NONE NONE NONE

(i think i don't need the "NONE"s, but that's the way I originally did it
several months ago)

I also have a "resolv.conf.tail" file, although given the fact that I
have
excluded "domain-name" and "domain-name-servers", I shouldn't need it.

I have set up resolv.conf on each machine as I want it.

BUT, one machine (the comcast one) works like I would expect. It gets a
dynamic ip address and does not change the resolv.conf file. When i look
at
/var/db/dhclient.leases.sk0, I see that no information exists regarding
dns
servers or domain names.

ON the other machine (the AT+T one) things are different. It gets a
dynamic
ip address, but also updates the resolv.conf with a domain name and dns
server
from the dhcp server. It also, as expected, then appends the contents of
resolv.conf.tail to the new resolv.conf file, and also creates a
resolv.conf.save file. Also, the data in /var/db/dhclient.leases.sk0
shows
that the dhcp client received dns server and domain name info from the
dchp
server:

 option domain-name-servers 192.168.1.254;
 option domain-name "gateway.2wire.net";

(despite the dhclient.conf file specifically excluding that information
from
the request line)

I can (sort of), make it do what i want by using supersede lines in the
dhclient.conf file; but I don't understand what I have done different
between
the two machines. As I said, both hostname.sk0 and dhclient.conf files
are
identical. I have tried (on the problem machine) deleting
resolv.conf.save
and /var/db/dhclient.leases.sk0, and then rebooting (starting with a
clean
slate, I was thinking), but that does nothing.

What am I missing?

Thanks
bye - ted

OT: Interupted system call/broken pipe with squid & squidguard

[Theodore Wynnychenko]

Hello:
I recently installed squid Version 2.7.STABLE6 and SquidGuard: 1.4 Berkeley
DB 4.6.21 on OpenBSD 4.5.
At this point, I am still setting things up, so it is not proxying much of
anything, except for testing, but I have been getting this error every
morning at 7:00AM local time:

Feb  3 07:01:01 server squid[12276]: The url_rewriter helpers are crashing
too rapidly, need help! 
Feb  3 07:01:01 server squid[7601]: Squid Parent: child process 12276 exited
due to signal 6
Feb  3 07:01:04 server squid[7601]: Squid Parent: child process 29122
started

I have no idea why this happens.  After squid shuts down, it restarts
without an issue, and runs fine until 7AM the next day.
I am using newsyslog to manage the log files, and I send a squid -k
reconfigure after the logs are rotated for squidguard; and a squid -k rotate
after the squid logs rotate. But that happens at 3AM.
I thought maybe there was some sort of problem with the file descriptors
running out (I don't know what that means) after squid/squidguard was
running for 24 hours, but I ran a script to shutdown and restart
squid/squidguard at 3:32 AM, but the same errors occurred at 7AM.
The ONLY thing that I can think of is that 7AM is the start of "dayhours" in
my squidguard.conf.  But I have no idea why that would be causing these
errors.
In any case, other than the fact that it all dies and then is reborn at 7AM
every day, it is all good.  It bothers me to have this issue. Any ideas to
correct this would be welcome.
Below I have included the output of (in this order): 
/var/squid/logs/cache.log
/var/log/squidguard/squidGuard.log

As well as my squidGuard.conf.

Thanks for any advice
Bye - ted

-
/var/squid/logs/cache.log

2010/02/03 07:00:00| WARNING: url_rewriter #1 (FD 9) exited
2010/02/03 07:00:00| WARNING: url_rewriter #3 (FD 11) exited
2010/02/03 07:00:00| WARNING: url_rewriter #2 (FD 10) exited
2010/02/03 07:00:00| Too few url_rewriter processes are running
2010/02/03 07:00:00| Starting new helpers
2010/02/03 07:00:00| helperOpenServers: Starting 5 'squidGuard' processes
2010/02/03 07:00:00| WARNING: url_rewriter #4 (FD 12) exited
2010/02/03 07:00:00| WARNING: url_rewriter #5 (FD 13) exited
2010/02/03 07:00:30| WARNING: url_rewriter #5 (FD 29) exited
2010/02/03 07:00:30| WARNING: url_rewriter #1 (FD 9) exited
2010/02/03 07:00:30| WARNING: url_rewriter #4 (FD 26) exited
2010/02/03 07:00:30| Too few url_rewriter processes are running
2010/02/03 07:00:30| Starting new helpers
2010/02/03 07:00:30| helperOpenServers: Starting 5 'squidGuard' processes
2010/02/03 07:00:30| ipcCreate: PARENT: hello read test failed
2010/02/03 07:00:30| --> read: (4) Interrupted system call
2010/02/03 07:00:30| WARNING: Cannot run '/usr/local/bin/squidGuard'
process.
2010/02/03 07:00:30| write FD 12: (32) Broken pipe
2010/02/03 07:00:30| ipcCreate: CHILD: hello write test failed
2010/02/03 07:00:31| WARNING: url_rewriter #3 (FD 25) exited
2010/02/03 07:00:31| WARNING: url_rewriter #2 (FD 11) exited
2010/02/03 07:01:01| WARNING: url_rewriter #4 (FD 12) exited
2010/02/03 07:01:01| WARNING: url_rewriter #1 (FD 9) exited
2010/02/03 07:01:01| Too few url_rewriter processes are running
2010/02/03 07:01:01| Starting new helpers
2010/02/03 07:01:01| helperOpenServers: Starting 5 'squidGuard' processes
2010/02/03 07:01:01| ipcCreate: PARENT: hello read test failed
2010/02/03 07:01:01| --> read: (4) Interrupted system call
2010/02/03 07:01:01| WARNING: Cannot run '/usr/local/bin/squidGuard'
process.
2010/02/03 07:01:01| ipcCreate: PARENT: hello read test failed
2010/02/03 07:01:01| --> read: (4) Interrupted system call
2010/02/03 07:01:01| WARNING: Cannot run '/usr/local/bin/squidGuard'
process.
2010/02/03 07:01:01| write FD 25: (32) Broken pipe
2010/02/03 07:01:01| ipcCreate: CHILD: hello write test failed
2010/02/03 07:01:01| ipcCreate: PARENT: hello read test failed
2010/02/03 07:01:01| --> read: (4) Interrupted system call
2010/02/03 07:01:01| WARNING: Cannot run '/usr/local/bin/squidGuard'
process.
2010/02/03 07:01:01| write FD 25: (32) Broken pipe
2010/02/03 07:01:01| ipcCreate: CHILD: hello write test failed
2010/02/03 07:01:01| ipcCreate: PARENT: hello read test failed
2010/02/03 07:01:01| --> read: (4) Interrupted system call
2010/02/03 07:01:01| WARNING: Cannot run '/usr/local/bin/squidGuard'
process.
2010/02/03 07:01:01| WARNING: url_rewriter #3 (FD 10) exited
2010/02/03 07:01:01| Too few url_rewriter processes are running
2010/02/03 07:01:01| storeDirWriteCleanLogs: Starting...
2010/02/03 07:01:01| write FD 25: (32) Broken pipe
2010/02/03 07:01:01| ipcCreate: CHILD: hello write test failed
2010/02/03 07:01:01| write FD 25: (32) Broken pipe
2010/02/03 07:01:01| ipcCreate: CHILD: hello write test failed
2010/02/03 07:01:01|   Finished.  Wrote 1020 entries.
2010/02/03 07:01:01|   Took 0.1 seconds (15190.8 entries/sec).
FATAL: The url_rewriter helpers are crashing too rapidly, need help!

Squid Cache (Version 2.7.

PCMCIA serial port not working

[Theodore Wynnychenko]

Hello:

I want to be able to use a laptop as a serial console from time to time.  My
current laptop does not have a RS232 serial port, so, I found a PCMCIA card
with a serial port.

It appears to be recognized fine by the OS on boot (dmesg below).  However,
when I try to use minicom on that line (/dev/cua03), it does not work.  I
cannot establish a connection to the "server" from the minicom console.
Also, even though minicom appears to come up ok, when I try to exit from
minicom, I get the "reseting" message, the screen clears, but then the
terminal window hangs.  I can see that the minicom process is still up.  I
can kill it (pkill -9 minicom), and then I get a prompt back in the terminal
window that was previously frozen.

If I try to shutdown with the "hung" minicom process, shutdown eventually
gives me "some processes would not die; ps axl advised."  This would seem to
indicate I have a problem with the crappy pcmcia card.

Also, if I use a usb serial adapter I have (which is in use elsewhere - and
change /dev/cua03 to /dev/ttyU0 in minicom), minicom works.

So, is there anything I can do, or is this a hardware problem?  How can I
find out for sure?

Thanks for any advice.
Ted


DMESG follows (pcmcia and com3 lines are near the end):

OpenBSD 4.6 (GENERIC) #58: Thu Jul  9 21:24:42 MDT 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel"
686-class) 1.99 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS
,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 266891264 (254MB)
avail mem = 249249792 (237MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/22/03, BIOS32 rev. 0 @ 0xfd891,
SMBIOS rev. 2.31 @ 0xd8010 (15 entries)
bios0: vendor Phoenix Technologies LTD version "R0202B3" date 04/22/03
bios0: Sony Corporation PCG-V505BC(UC)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP BOOT SSDT SSDT
acpi0: wakeup devices PWRB(S5) CRD0(S3) LAN_(S3) USB1(S3) USB2(S3) USB3(S3)
EC0_(S5) MODE(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (HUB_)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, C1, FVS, 2000, 1200 MHz
acpitz0 at acpi0: critical temperature 90 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWRB
acpibat0 at acpi0: BAT1 type LION oem "Sony Corp."
acpiac0 at acpi0: AC unit online
bios0: ROM list: 0xc/0x1 0xd8000/0x4000! 0xdc000/0x4000!
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845 Host" rev 0x04
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xec00, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82845 AGP" rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M6" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 9
drm0 at radeondrm0
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x42
pci2 at ppb1 bus 2
cbb0 at pci2 dev 5 function 0 "Ricoh 5C475 CardBus" rev 0xb8: couldn't map
interrupt
"Ricoh 5C551 Firewire" rev 0x00 at pci2 dev 5 function 1 not configured
ohci0 at pci2 dev 7 function 0 "NEC USB" rev 0x43: irq 9, version 1.0,
legacy support
ohci1 at pci2 dev 7 function 1 "NEC USB" rev 0x43: couldn't map interrupt
ehci0 at pci2 dev 7 function 2 "NEC USB" rev 0x04: couldn't map interrupt
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x42: couldn't map
interrupt
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "NEC OHCI root hub" rev 1.00/1.00 addr 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CAM LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801CAM IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
ichiic0 at pci0 dev 31 function 3 "Intel 82801CA/CAM SMBus" rev 0x02:
polling
iic0 at ichiic0
spdmem0 at iic0 addr 0x54: 256MB DDR SDRAM non-parity PC2300CL2.5
auich0 at pci0 dev 31 function 5 "Intel 82801CA/CAM AC97" rev 0x02"Intel
82801CA/CAM Modem" rev 0x02 at pci0 dev 31 function 6 not configured
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pcic0 at isa0 port 0x3e0/2 iomem 0xd/16384
pcic0 controller 0:  has socket A only
pcmcia0 at pcic0 control

Re: How to redirect output from /etc/rc.shutdown

[Theodore Wynnychenko]

(OPPS, I mean to send this to the list last night.)

Hello:

Thanks.

>> Anyway, I would like to have the system confirm a shutdown or reboot
>> before actually doing it.

>Why?
>And who will be allowed to initiate a shutdown that way?

>Without knowing that, it's hard to suggest a sane approach.

I was just thinking about the possibility of having more than one SSH
session open, and mistakenly shutting down the wrong one.  I agree that this
should be unlikely to occur, but I wanted to see if I could devise a simply
second step to help prevent it.

>> I could do something like rename the shutdown/reboot/halt commands,

>Do not fiddle with system commands, you are asking for trouble.

Yep, I was thinking the same thing.  Hence, the rc.shutdown question.

>>[...]
>> seems like the cleanest solution would be to run a script
>> from rc.shutdown to ask for conformation.
>>[...]
>> What am I missing?

>When init(8) is in the middle of dying,
>  fork(2) & execl(3) & waitpid(2)  /bin/sh /etc/rc shutdown
>is the very last thing it does before starting to kill off its
>remaining children, i.e. all remaining userland processes.
>At that point during init(8)'s death, most userland processes
>are already dead, including all getty(8) terminal sessions,
>so no user is logged in any more.

I am not so sure about this.  It appears that rc.shutdown is the first thing
to run (if something is there) during the shutdown/halt/reboot process.
This is based on empirical observations.
For example, I make a simple script:
#!/bin/sh
Echo blah
Sleep 10
Put this somewhere, point to it from /etc/rc.shutdown and enter "halt" from
a SSH session.

On the SSH terminal, nothing happens, but the connection is not immediately
dropped either.
If I go over and look and the console, I see:
"/ect/rc.shutdown in progress ...
blah"

And then, 10 seconds later:
"/etc/rc.shutdown complete."

At that point, the ssh connection is dropped, and the machine goes down.

Now, if I do this again from the ssh terminal, but this time, after entering
"halt," but within 10 seconds, enter "ctrl-C" in the SSH terminal, I get a
shell prompt back, and the machine does not go down (the ssh connection
stays up).

On the console, the same messages appear, including the "rc.shutdown
complete," but the rest of the shutdown process is aborted (the system stays
up).

If I modify the script to include "echo blah > /dev/ttyp0" (or whatever the
user is connected to), then, when I enter "halt" the "/etc/rc.shutdown in
progress" and "rc.shutdown complete" still go to the console, but "blah"
comes up in the ssh terminal window.

So, it seems to me that rc.shutdown could be used in this way, as long as I
could reliably figure out a way to redirect input/output to whatever
terminal was used to start the shutdown process.  I can think of a pretty
messy way to do this by parsing through the output of ps, but thought there
must be a better way.

Thanks
Bye - ted

PS: I am the only useless staff here.

How to redirect output from /etc/rc.shutdown

[Theodore Wynnychenko]

Hello:

I have been unable to discover this answer for myself.  If I missed this
somewhere, sorry for bothering the list.

Anyway, I would like to have the system confirm a shutdown or reboot before
actually doing it.

I could do something like rename the shutdown/reboot/halt commands, and then
write a script to ask for conformation before shutting down/etc; but, I
seems like the cleanest solution would be to run a script from rc.shutdown
to ask for conformation.

However, I can't figure out how to direct output/input from a script run in
rc.shutdown to the user's terminal (ssh connection, xterm, console) that
started the shutdown/reboot/halt process.  Anything I put in rc.shutdown is
displayed directly to the console.

I also don't see an obvious environment variable that I can use to reliably
redirect output.

What am I missing?

Thanks

Re: Hardware versus Software RAID

[Theodore Wynnychenko]

On Sat, 21 Nov 2009 21:43:30, Marco Peereboom wrote:

When possible use hardware RAID.
...
ami is ok but has some issues.

-

So, since I have hardware RAID, let's stick with it.  Now, what if it fails.

-

On Sat, 21 Nov 2009 22:54:58, Nick Holland wrote:

There is more to RAID1 than duping the data to two drives and keeping them
the same.  All HW RAID systems that I have seen use some kind of signature
to mark the drives as part of a RAID set
...
The signature that helps resolve the above has to be somewhere on the
disk.  Some systems try to hide it some place the OS would never notice
(I believe I read some tech notes on one system that stuck it on the
very last sector of the disk, with the assumption that very few OSs ever
put anything there, I've seen one other RAID system that seemed to do
that, as the drives COULD be removed from the RAID system and used
directly on a standard controller), but others just plop it at the
front of the physical disk, and create the array in the remaining
space.

-

Thanks for the insight.  So, I decided I would look more closely at this
situation, and see if there was a way to recover one of the RAID disks when
it was attached to a regular SATA controller.  In my particular case, this
turned out to be easier than I expected, for reasons that I really don't
understand, mostly because my last email was inaccurate.

Anyway, in short.  I again disconnected one of the drives from the RAID
array, and connected it directly to one of the motherboard's SATA
controllers.  As before, when I tried to boot the system, I would get a "No
O/S" message from the BIOS when it would try to boot from the hard disk.  It
appears, on this machine, that when the SATA controller is on with a disk
connected, that's the drive it tries to boot, and does not try the IDE drive
that is connected with the O/S on it.

So, I booted up with the 4.6 Install CD, and used the shell provided.  As I
said before, fsck did not work.  Also fdisk and disklabel returned "device
not configured."  I had assumed that this was because the RAID disk attached
to the SATA controller was not readable.  But then I noticed that fdisk and
disklabel were able to read both the main openbsd system disk (wd0), and the
degraded raid array (sd0), but not the SATA attached RAID disk (wd2) OR the
secondary IDE disk present (wd1).  This was odd, since both wd0 and wd1 are
fine when the system boots from the installed IDE hard disk.  (BTW, I could
find no indication in the man pages or elsewhere to suggest that disklabel
or fdisk work differently in the shell provide by the install CD - this is
the part I don't understand.)

Therefore, I rebooted, this time using the CD to start the boot process, but
then pointed it at the installed system on wd0.  When it came up, I was able
to log in, and the SATA connected RAID disk was there.  I could see the
disklabel; the filesystem was clean; and all the files were there when I
mounted it. (It appears the signature is somewhere where it does not
interfere with the OS for the MegaRaid controller.)

As I said, I don't know why the install CD did not work.  But, I really want
to say thanks for all the insight that I got from everyone.  I had not even
thought about the controller failing, and, if it had, I would have probably
been mighty annoyed, and may have decided my data was gone for good (this
would have probably also annoyed my user base -> wife).

But now, I know that in this situation (with this controller and a RAID1
array), if the controller ever dies, I can recover the data by connecting
the disk to a regular SATA controller; and I know the steps I would need to
take.  I still don't understand why it does not work directly from the 4.6
Install CD, however.

Thanks again
Bye - ted

PS: And I still have the off-site backup in case the house burns down.

Re: Hardware versus Software RAID

[Theodore Wynnychenko]

From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Marco Peereboom

right but with no knowledge whatsoever about its content.

On Sat, Nov 21, 2009 at 04:09:55PM -0701, Jeff Ross wrote:
> 
> In my scenario, in a 1U server with 2 enclosures I do not have a hot spare
> online but I still have a good drive and a failed drive.  Replacing the
failed
> drive, even with the exact same hard disk, has to result in copying the
> good drive to the new drive, right?
> 
> Jeff

On Fri, Nov 20, 2009 at 12:08:33PM -0700, Jeff Ross wrote:
> I shutdown that server, removed the failed drive and inserted it into 
> another identical SuperMicro.  System booted, noted an unclean shutdown, 
> ran fsck and   was at login in short order.

-

I have been following this thread with some interest.

I have just been putting together an older system that I was going to use as
a home fileserver.  Somewhere in the past, I acquired a LSI Megaraid 150-6
PCI card (it is supported by ami).   I also had a matched pair of SATA
drives, and was planning on using hardware raid to mirror them (this is not
for backup, I do that frequently enough for me with a couple of USB drives
stored elsewhere), but more so to avoid an annoyance if either of the older
SATA drives fail (the raid array was only for my data, I installed the OS on
another drive).

Anyway, I had not considered the possibility of a controller failure.  I
also wondered if it was possible to remove a drive from the mirrored
hardware array, and see if it is recognized by a plain old SATA controller.
So, I did this by shutting the system down, enabling the motherboard's SATA
controller, and moving one of the drive cables to this standard SATA
controller.

Unfortunately, while the array comes up and is accessible, even though it is
degraded; I cannot access the drive now attached to the standard SATA
controller.  If I try to fsck it, I get an "unknown special file or file
system" message.

So, it seems, with ami and this megaraid card, I will not be able to recover
from a controller failure by hooking a drive up to a standard SATA
controller.  The motherboard does have 2 standard SATA connectors I can use
(instead of the LSI Megaraid card - currently disabled in BIOS and not
visible in the dmesg below).

So, my question:  How likely is a raid controller failure (with the LSI
Megaraid PCI cards), and would I be better off just chucking the Megaraid
card and using software raid with the drives connected via the standard SATA
controllers?  I figure there must be some performance loss, but I can't
imagine I will ever notice it looking at old pictures.

Finally, I am wondering.  I had assumed that the hardware controller really
didn't do that much when in RAID1, and just passed the writes/reads to/from
both of the disks, resulting in 2 (basically) normal drives.  Obviously, I
was wrong.  I am wondering why/how the raid controller needs to modify the
disk's file system when it's only mirroring 2 drives? (I really could not
find anything by google-ing around on this.)

I hope I don't sound too clueless for asking.

Bye - ted


---
OpenBSD 4.6 (GENERIC) #58: Thu Jul  9 21:24:42 MDT 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 1072742400 (1023MB)
avail mem = 1028481024 (980MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/19/03, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.3 @ 0xf0450 (66 entries)
bios0: vendor Dell Computer Corporation version "A03" date 09/19/2003
bios0: Dell Computer Corporation Dimension XPS
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT APIC BOOT
acpi0: wakeup devices VBTN(S4) PCI0(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
PCI1(S5) MOU_(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
acpicpu0 at acpi0
acpibtn0 at acpi0: VBTN
bios0: ROM list: 0xc/0xd000 0xcd000/0x800 0xcd800/0x800 0xce000/0x800!
0xce800/0x1800!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82875P Host" rev 0x02
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe800, size 0x800
ppb0 at pci0 dev 1 function 0 "Intel 82875P AGP" rev 0x02
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce2 MX" rev 0xb2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 1 int
16 (irq 11)
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0

Re: "couldn't map interrupt" for fxp / "intel PRO/100 VE" after upgrade to 4.6 (or 4.5)

[Theodore Wynnychenko]

THANK YOU!
I disabled acpi at the boot prompt of the currently installed 4.5, and the
network card is now recognized.
Again, thanks a lot for pointing me in this direction.
Bye - ted

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Anathae E. Townsend
Sent: Tuesday, October 20, 2009 9:12 PM
To: misc@openbsd.org
Subject: Re: "couldn't map interrupt" for fxp / "intel PRO/100 VE" after
upgrade to 4.6 (or 4.5)

The one difference on your machine between 4.4 and 4.5/4.6 is apm vs acpi

If you used the boot prompt to disable acpi, do you have access to the 
network card again?

Anathae

p.s. taking a wild shot in the dark.

"couldn't map interrupt" for fxp / "intel PRO/100 VE" after upgrade to 4.6 (or 4.5)

[Theodore Wynnychenko]

Hello:
I am just wondering if anyone has any idea about this.
I originally installed 4.4 on a Sony laptop, all was good.
With the 4.5 release, the built in nic stopped working.  I tried multiple
snapshots, and, now, the current 4.6 release.
I was wondering if there was anything I could do to make it work?
Please, I am not "demanding" anything.  I don't have the anywhere near the
knowledge to figure this out, and I just want to know if there is anything I
can do to make it work for me?
If not, is there any idea if this will work again in the future? (again, not
a demand, I just would like to know if there are any plans to get it working
- if not, I understand that, and it's not a problem.)

Thanks for your time, and all of it.

Here are the dmesg from the 4.4, 4.5, and 4.6 releases (in that order):
--
4.4 dmesg:

OpenBSD 4.4 (RAMDISK_CD) #857: Tue Aug 12 17:31:49 MDT 2008
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel"
686-class) 1.99 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS
,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 267415552 (255MB)
avail mem = 251977728 (240MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/22/03, BIOS32 rev. 0 @ 0xfd891,
SMBIOS rev. 2.31 @ 0xd8010 (15 entries)
bios0: vendor Phoenix Technologies LTD version "R0202B3" date 04/22/03
bios0: Sony Corporation PCG-V505BC(UC)
apm0 at bios0: Power Management spec V1.2
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xfd890/0x770
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf50/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0x1 0xd8000/0x4000! 0xdc000/0x4000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845 Host" rev 0x04
ppb0 at pci0 dev 1 function 0 "Intel 82845 AGP" rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M6 LY" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x42
pci2 at ppb1 bus 2
cbb0 at pci2 dev 5 function 0 "Ricoh 5C475 CardBus" rev 0xb8: irq 3
"Ricoh 5C551 Firewire" rev 0x00 at pci2 dev 5 function 1 not configured
ohci0 at pci2 dev 7 function 0 "NEC USB" rev 0x43: irq 9, version 1.0,
legacy support
ohci1 at pci2 dev 7 function 1 "NEC USB" rev 0x43: irq 10, version 1.0,
legacy support
ehci0 at pci2 dev 7 function 2 "NEC USB" rev 0x04: irq 3
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x42, i82562: irq 10,
address 08:00:46:ad:9e:c5
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "NEC OHCI root hub" rev 1.00/1.00 addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CAM LPC" rev 0x02: 24-bit
timer at 3579545Hz
pciide0 at pci0 dev 31 function 1 "Intel 82801CAM IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets, initiator 7
cd0 at scsibus0 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
"Intel 82801CA/CAM SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
"Intel 82801CA/CAM AC97" rev 0x02 at pci0 dev 31 function 5 not configured
"Intel 82801CA/CAM Modem" rev 0x02 at pci0 dev 31 function 6 not configured
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
biomask fffd netmask fffd ttymask 
rd0: fixed, 3800 blocks
umass0 at uhub0 port 1 configuration 1 interface 0 "PNY USB 2.0 FD" rev
2.00/2.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0:  SCSI0 0/direct
removable
sd0: 3835MB, 489 cyl, 255 head, 63 sec, 512 bytes/sec, 7856127 sec total
umass1 at uhub2 port 2 configuration 1 interface 0 "Sony USB Memory Stick
Slot" rev 1.10/1.90 addr 2
umass1: using ATAPI over CBI with CCI
scsibus2 at umass1: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0:  ATAPI 0/direct removable
sd1: drive offline
softraid0 at root
root on rd0a swap on rd0b dump on rd0b



4.5 dmesg:

OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
dera...@i386.

"couldn't map interrupt" for fxp / "intel PRO/100 VE" after upgrade to 4.5

[Theodore Wynnychenko]

Hello:
I have been working with OpenBSD since 4.4 came out, trying to learn things
as I go.
I decided to have a go with the upgrade process. So, I booted off the 4.5CD,
and followed the steps to upgrade (I did not pay attention to the dmesg as
it scrolled by when booting from the 4.5 CD).  So, I completed the steps for
upgrade from the console (a Sony Vaio model PCG-672R) and got to the point
of trying to upgrade the packages when I realized I couldn't connect through
the built in Ethernet port. Then I noticed that ifconfig did not display the
adapter, and then I saw, in dmesg:
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x42: couldn't
map interrupt
(this occurs when booting with the 4.5CD and, now, the upgraded system)
I took a look at the bios configuration, to see if there was some option
about interrupts, but, not surprisingly, there was not.

I am wondering what I should do next.  It worked flawlessly with 4.4.  I did
a little google searching about this, but couldn't find anything to point me
in any direction.

(right now, I can't easily get a copy of the dmesg off the laptop, but if
it's necessary, I will figure out some way to do it)

Thanks
Bye - ted

2 seperate questions: segmentation fault and powerdown issue

[Theodore Wynnychenko]

Hello:

I hope these questions are not off topic.  I have been working with the 4.4
release for the last few months (learning something new keeps brain cells
alive).  I got an old P2 or P3 (?) up and running as a firewall at home.  It
appears to be very stable, however, every 1 to 3 weeks or so, I get an email
from cron telling me that a script had a "segmentation fault" (I set up some
basic scripts, the one that seems to have this issue runs every 5 minutes,
scans authlog for failed ssh attempts, and enters those ip's into a
blacklist table for PF).  So, it's not a big deal, because 5 minutes later
it runs again, and is fine.
But, I was wondering, how concerned should I be about this?  I understand a
seg fault is pretty vague, and can mean any of a bunch of things (e.g.: a
corrupt memory cell).  So, this is not a "critical" system, but then again I
don't want to come home one day and spend time replacing it before I can get
my email.  Similarly, it doesn't happen often (once every 1-3 weeks), so, I
don't want to waste a bunch of time ripping the computer apart trying to
find the source of the error (if it's hardware), if the system is otherwise
stable, and this doesn't pose a substantial risk of failure.  Should I be
worried about this or not?

Second question:  Given my success with the first system, I started working
on another old computer (I don't know, maybe a fileserver).  While
installing and setting up 4.4, I added "powerdown=YES" to rc.shutdown, so it
would automatically powerdown on "halt."  However, when I have the system
halt, it shuts down cleanly, gets to the "powerdown" stage, I hear the disks
stop spinning, but, the power supply fan, and the CPU fan keep running.
Also, a video signal is still present (the monitor does not go to sleep).
So, I hit the power switch for a couple of seconds, and it powers off
completely.  APM is present and running.  This system is an old HP Pavilion
8580C (an ASUS motherboard, I guess).  I thought maybe there was a problem
with the power supply, so I replaced it with a different ATX power supply,
but same problem.  I would guess this is a problem with the motherboard's
APM, but I was wondering if there is any sort of workaround for this?

Thanks.

Bye - ted

PF setup with tun0 as backup external if

[Theodore Wynnychenko]

Hello:


I am trying to understand what approach I need to take.  I have tried
searching the lists, and have gone over the PF User's Guide/FAQ/Man pages,
but am not sure how to approach this.

I am trying to set up a firewall for a home network. The firewall is
connected to the outside with a cable modem, usually.   So, this I
understand, and can use pf for NAT and filtering.

However, since my ISP has issues, and since I have access to alternate
dialup provider, I would like to set up the firewall with a modem that can
be used to access the internet when the cable goes down.  Basically, if the
cable dies, I would like to tell the firewall to dial the alternate ISP, and
use PPP to set up a second route to the internet.

So, I am trying to understand the right way to do this.

Let's say: 

 

  mdm_if = "tun0"   # ppp interface

  ext_if = "sk0"# external NIC

  int_if = "sk1"# internal NIC

 

Obviously, on boot, both ext_if and int_if are up and running, so I can set
up pf to filter and nat without an issue.

However, what happens when I need to switch to the modem for internet
access.  Clearly, the tun0 interface is only created when I connect using
the modem  (ppp).

Am I able to define tun0 in pf.conf before it exists?  If I can, would
simply doing something like defining 2 NAT rules, like:



  nat on $mdm_if from !($mdm_if) -> ($mdm_if:0)

  nat on $ext_if from !($ext_if) -> ($ext_if:0)

 

and then using something like:

 

ext_con= "{ tun0, sk0 }"

 

as the macro in my filter rules work, so that, if the cable goes down, I can
make the firewall dialup, and then be able to connect/filter/NAT on tun0 .

Or, do I need to use anchors.  So, on boot, pf would load the NAT and filter
rules for $ext_if, and then, when I need to use the PPP connection, I would
use ppp.linkup and ppp.linkdown to load (and unload) NAT and filter rules
for the dialup connection?

Or, is there another, more appropriate, option?

 

Thanks

ted

Re: How do I setup OpenBSD to login automatically and lauch minicom?

[Theodore Wynnychenko]

>Here's a simple example of a script that just displays systat
>on a terminal that you could run in place of a getty:

>#!/bin/sh
>TERM=vt220 /usr/bin/sudo -u nobody /usr/bin/systat vmstat < /dev/$1 >
/dev/$1

>If you have problems, look at /var/log/authlog, if you see "getty
>repeating too quickly" message, the program exited straight away
>for some reason. In that case you might obtain clues by redirecting
>stdout/stderr to a file and looking for error messages.


Hello
Thanks for the suggestions.
As it turns out, I have gotten this to work (almost perfectly).
I wrote a small script:

#!/bin/sh
TERM=vt220 /usr/local/bin/minicom < /dev/ttyC0 > /dev/ttyC0

that I point to in /etc/ttys for the terminal ttyC0.

Now, even though it works, I have two questions.
First, when I was trying to make this work, at first, I got no output, but
also, I did not get any errors (when I redirected errors to a file), and,
even thought the terminal was "blank," I saw a running minicom process on
the system.  Not until I specifically added the input and output redirection
to ttyCO did the minicom session appear and work.  (and it works just like I
would expect - if I try to exit minicom, it is immediately restarted).  But,
any idea why I had to specify the input/output explicitly to get this to
work?
Second, the system will not shut down cleanly with the minicom terminal
running.  If I try to shut the system down, it seems to "hang" at the
"syncing disks" stage.  Eventually, if I power the system off and on, the
root file system is not clean.  I notice that during the shutdown, the
minicom "terminal" dose get a signal 15, and starts to close, but seems to
hang at "Reseting modem."  However, when I ran minicom directly in a
"standard" shell, it would shut down fine. I have now made the filesystems
read-only, and now turn the system off but hitting the power button, but it
bothers me that all is not "perfect."  Any ideas why the minicom session
won't close cleanly when launched via /etc/ttys?

Thanks again for the help.  The above 2 questions are more for
understanding, rather than actual practical need.

bye - ted

How do I setup OpenBSD to login automatically and lauch minicom?

[Theodore Wynnychenko]

Hello

I am trying to figure out how to modify the boot process to automatically
spawn a minicom session. (I know I have many other options for what I am
trying to do, but I thaught this would be a good way to learn someghing
about OpenBSD.)
Basically, I have an old laptop, and (partially as a way to learn something
about OpenBSD) I want to set it up as a serial console to use with other
systems.  Thus, I am not at all concerned about the security of the login
process (this laptop, once configured) will not connect to a network, and
will have (pretty much) all services disabled.  I was also going to convert
the filesystems to read-only, so, a hard shutdown won't disrupt the
filesystems.
In any case, here is my question(s).  I have been reading the man pages, and
(in summary) I see that that boot loads the kernel (bsd), pass control to
init which parses through rc, and then spawns the process getty (as defined
by ttys).  This results in the login prompt, which, when a username is
entered, calls login which authenticates (using login_passwd), and then sets
several enviormental variables, before spawning a shell.  I think this is
right?
So, I think the place for me to modify this process is by changing the
variable to execute getty in /etc/ttys to instead launch minicom?   I tried
this, but (i guess, obviously) it did not work.
I assume that I have to set enviormental variables before minicom is
started?  Do I need getty and login to spawn a shell before starting
minicom?  If I need to go through getty and login, is there a way to
automatically login without password (or any other authentication)?  Would a
simple script that sets the enviornemt variables and runs minicom work?
I noticed a statement in one of the entries on this mailing list that
indicated there was a way to do something like this (login automatically /
start a program automatically on login), and that this information was in
the FAQ's, however, I can't seem to find it.
Any help would be really appreciated.
thanks

FW: OpenBSD 4.2 - Netgear WG511 pcmcia wireless card - notrespondiing

[Theodore Wynnychenko]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Marcus Glocker
Sent: Monday, February 04, 2008 11:56 PM


Are you sure your CardBus WG511 device is a Taiwanese model as stated
in the man page (you will find this information on the back-side of
the device)?

 NETGEAR WG511 (Taiwanese, not Chinese) ISL3890CardBus

We saw this "not responding" issue exactly with the WG511 devices
produced in China.

Marcus



Hello:

Nope, that doesn't seem to be it.  I noted the "Taiwanese, not Chinese"
restriction in the man page.  While I can't find "ISL3890" anywhere on the
card; at the bottom, on the back, it says "Made in Taiwan."

Your info is interesting.  I notice that on the netgear site, they have a
"Firmware" update for this card (what they call 2.04.12.00).  Now, reading
the man page, I would assume that this "firmware" update (from netgear)
doesn't actually flash the card, but is only a software change.  Or does it
mean that the card's programing has been changed?  And, if so, should I try
to find a MSwindows laptop, and "install" an older version of netgear's
"firmware"?

Thanks for the advice.

Ted

Re: OpenBSD 4.2 - Netgear WG511 pcmcia wireless card - notrespondiing

[Theodore Wynnychenko]

Yes,
I installed the firmware as it directs in the pgt man page
(http://www.nazgul.ch/pgt/pgt-firmware-1.2.tgz - actually, the man page
links to the 1.1 version of the firmware, but there is a 1.2 version
available - which is what i used - i had the same problem (with the "not
responding" message) when i installed the 1.1 version of the firmware
earlier last week)

I posted my dmesg in a post last week (on 2/1)
thanks

-Original Message-
From: Julien Cabillot [mailto:[EMAIL PROTECTED]
Sent: Monday, February 04, 2008 3:32 PM
To: [EMAIL PROTECTED]
Subject: Re: OpenBSD 4.2 - Netgear WG511 pcmcia wireless card -
notrespondiing


Did you install the firmware ?
cf.
http://www.nabble.com/OpenBSD-4.2---Netgear-WG511-pcmcia-wireless-card---not
-respondiing-td15232095.html


On lun, 2008-02-04 at 15:21 -0600, Theodore Wynnychenko wrote:
> Hi:
> Last week I asked about the failure of OpenBSD to work with a wireless
> pcmcia network card (WG511).
> I hope the question is not too basic, but, is the misc list the wrong
place
> to ask the question?
> Does anyone have any advice for me about this?
> It seems the kernel correctly identifies the card on insertion, but then
the
> pgt firmware gives me a "not responding" message.  Is the card dead? Am I
> doing something wrong?  Did I miss something during the install?
> I have spent the better part of a week going through the man pages, the
> mailing list archive, the faq, and searching with google; but, am unable
to
> even come up with a direction to go.
> If anyone has any ideas, I would really appreciate it.  Is this the wrong
> place to ask my question?  If so, could someone let me know that is the
> case.
> Thanks again

Re: OpenBSD 4.2 - Netgear WG511 pcmcia wireless card - not respondiing

[Theodore Wynnychenko]

Hi:
Last week I asked about the failure of OpenBSD to work with a wireless
pcmcia network card (WG511).
I hope the question is not too basic, but, is the misc list the wrong place
to ask the question?
Does anyone have any advice for me about this?
It seems the kernel correctly identifies the card on insertion, but then the
pgt firmware gives me a "not responding" message.  Is the card dead? Am I
doing something wrong?  Did I miss something during the install?
I have spent the better part of a week going through the man pages, the
mailing list archive, the faq, and searching with google; but, am unable to
even come up with a direction to go.
If anyone has any ideas, I would really appreciate it.  Is this the wrong
place to ask my question?  If so, could someone let me know that is the
case.
Thanks again

OpenBSD 4.2 - Netgear WG511 pcmcia wireless card - not respondiing

[Theodore Wynnychenko]

Hello:

I recently decided to try OpenBSD.  I successfully installed on a Sony Vaio
PCG-672R laptop.  (Actually, I have successfully installed OpenBSD 3 or 4
times now, and X-windows, and (i think) KDE.  Practice makes perfect when I
am trying to learn something new.)
Anyway, I also have a Netgear WG511 (v1) pcmcia wireless network card.  I
have been unable to get this to work.  I have looked at the man page for
pgt, and done some searching over the last week on the web, but am unable to
figure this out.  The pcmcia card did work successfully in the past under
MSwindows 2k and XP.
So, after installing the system, downloading and "pkg_add" from
http://www.nazgul.ch/pgt/pgt-firmware-1.1.tgz (well actually, i used
http://www.nazgul.ch/pgt/pgt-firmware-1.2.tgz), i plug in the card and get:

Feb  1 11:10:11 sam /bsd: pgt0 at cardbus0 dev 0 function 0 "Intersil,
ISL3890, -": irq 3
Feb  1 11:10:12 sam /bsd: pgt0: not responding

So, the card is identified, but that's it.  I am not even sure if this is a
hardware error or a software error.

Any help or suggestions would be great.

dmesg is below

Thanks
bye - ted

OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel"
686-class) 1.99 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS
,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 267415552 (255MB)
avail mem = 250920960 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/22/03, BIOS32 rev. 0 @ 0xfd891,
SMBIOS rev. 2.31 @ 0xd8010 (15 entries)
bios0: vendor Phoenix Technologies LTD version "R0202B3" date 04/22/03
bios0: Sony Corporation PCG-V505BC(UC)
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd890/0x770
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf50/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0x1 0xd8000/0x4000! 0xdc000/0x4000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845 Host" rev 0x04
ppb0 at pci0 dev 1 function 0 "Intel 82845 AGP" rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M6 LY" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x42
pci2 at ppb1 bus 2
cbb0 at pci2 dev 5 function 0 "Ricoh 5C475 CardBus" rev 0xb8: irq 3
"Ricoh 5C551 Firewire" rev 0x00 at pci2 dev 5 function 1 not configured
ohci0 at pci2 dev 7 function 0 "NEC USB" rev 0x43: irq 9, version 1.0,
legacy support
ohci1 at pci2 dev 7 function 1 "NEC USB" rev 0x43: irq 10, version 1.0,
legacy support
ehci0 at pci2 dev 7 function 2 "NEC USB" rev 0x04: irq 3
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: NEC EHCI root hub, rev 2.00/1.00, addr 1
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x42, i82562: irq 10,
address 08:00:46:ad:9e:c5
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1: NEC OHCI root hub, rev 1.00/1.00, addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2: NEC OHCI root hub, rev 1.00/1.00, addr 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CAM LPC" rev 0x02: 24-bit
timer at 3579545Hz: SpeedStep
pciide0 at pci0 dev 31 function 1 "Intel 82801CAM IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
ichiic0 at pci0 dev 31 function 3 "Intel 82801CA/CAM SMBus" rev 0x02:
polling
iic0 at ichiic0
auich0 at pci0 dev 31 function 5 "Intel 82801CA/CAM AC97" rev 0x02: irq 9,
ICH3 AC97
ac97: codec id 0x594d4803 (Yamaha YMF753-S)
ac97: codec features 18 bit DAC, No 3D Stereo
audio0 at auich0
"Intel 82801CA/CAM Modem" rev 0x02 at pci0 dev 31 function 6 not configured
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
biomask effd netmask effd ttymask 
pctr: user-level cycle counter enabled
mtrr: Pentium Pro MTRR support
umass0 at uhub2 port 2 configura