revision 1.201 of sys/conf/GENERIC (enable mpath, rdac and sym) breaks suspend on Thinkpad X200s

Hi, with this patch enabled on a Thinkpad X200s, the system doesn't wake up anymore after being suspended via apm -z. This problem is reproducible. dmesg before and after this patch is attached to this mail. Best Regards Andreas OpenBSD 5.4-current (GENERIC.MP) #0: Mon Sep 30 22:21:24 CEST

typo in icmp6(4)

Hello, I've noticed a typo in the icmp6(4) man page regarding icmp6 type 4 code 2. Diff is attached. According to the (informational) RFC 4890 this kind of icmp6 message must not be dropped for the correct functioning of IPv6. Is there a key word planned for this icmp6 code which could be

Re: ifconfig(8) tunnel and address families

Hello Stuart, On 05/16/11 12:59, Stuart Henderson wrote: Re http://permalink.gmane.org/gmane.os.openbsd.misc/185629 To set IPv6 tunnel endpoints for gif/gre, you have to use syntax like ifconfig gif0 inet6 tunnel 1::1 2::2 rather than just ifconfig gif0 tunnel 1::1 2::2. This is because

nc(1), GNU netcat and FIN segments after all data has been sent

Hello, I've noticed that there's a difference in behavior between nc(1) and GNU netcat when they talk to some daemon via TCP. The commands in the following example are basically the same: GNU netcat: netcat host 1234 infile nc(1): nc host 1234 infile nc(1) sends a FIN segment after all

Re: nc(1), GNU netcat and FIN segments after all data has been sent

Hi Theo, On 06/23/11 18:30, Theo de Raadt wrote: ... I've noticed that some daemons behave differently because of this, i.e., they won't return any data although they are still allowed to send data. Yes, those daemons are broken. Their select/poll loops are unaware that writeability and

Re: nc(1), GNU netcat and FIN segments after all data has been sent

On 06/23/11 21:05, Christopher Zimmermann wrote: ... Maybe you can force nc(1) not to send a FIN segment by using something like this: cat infile - |nc host 1234 This works. Thanks!

Huawei E303

Hi, I've got a Huawei E303 UMTS stick which doesn't work out of the box in current. After adding the following patch, the E303 seems to be recognized: # cvs diff -u usbdevs usbdevs.h usbdevs_data.h umsm.c Index: usbdevs ===

Re: Huawei E303

On 07/15/12 16:53, Paul Irofti wrote: Unfortunately, I have no clue where to go from there. I'd like to connect to vodafone in Germany via UMTS, but I didn't find a /etc/ppp/peers/ and a corresponding chat script configuration in the archives which works for me. Is anybody else using a similar

Re: Huawei E303

On 07/16/12 09:09, David Coppa wrote: ... Please report back if you have (at least) a port responding to AT commands: I'd like to commit your diff. the stick seems to recognize the correct PIN, i.e., in case my SIM card PIN would be 1234, I would get the following output: # cu -l cuaU0

Re: Huawei E303

On 07/16/12 14:54, Stuart Henderson wrote: On 2012/07/15 19:00, Paul Irofti wrote: On Sun, Jul 15, 2012 at 05:40:03PM +0200, David Coppa wrote: Il giorno 15/lug/2012 16:56, Paul Irofti p...@irofti.net ha scritto: Unfortunately, I have no clue where to go from there. I'd like to connect to

Re: em(4): enable TCP/UDP checksum offload

looks good: # dmesg |grep ^em em0 at pci9 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06: apic 0 int 8, address X:X:X:X:X:X em1 at pci9 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06: apic 0 int 18, address X:X:X:X:X:X # ifconfig em hwfeatures em0:

Re: em(4): enable TCP/UDP checksum offload

and these also look good: dmesg|grep ^em em0 at pci3 dev 0 function 0 Intel PRO/1000 PT (82572EI) rev 0x06: apic 2 int 17, address X:X:X:X:X:X ifconfig em hwfeatures em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500

jumbos for bnx(4) (again)

Hello, last year, a patch regarding bnx(4) jumbos was provided and refined by dlg@, kettenis@ and brad@. I've tested the diff for if_bnx.c against current and setting MTUs 1500 works in principle. However, with this diff enabled on current, there's quickly deteriorating packet loss

Re: softraid(4) disks are of wrong size

On 12/19/10 17:15, Marco Peereboom wrote: I could swear we had the sizes right but I'll have another look at this. What raid type did you test this with? I've only tested CRYPTO, but sr_meta_native_probe() seems to be used by all disciplines. Try newfs /dev/rsdXc where X is a virtual

Re: softraid(4) disks are of wrong size

On 12/19/10 22:28, Kenneth R Westerback wrote: ... You should NEVER use 'c' partition. Amoung other things, it is always set by the kernel to encompass the whole disk, everytime the disklabel is read. If you restore to a different sized disk interesting things might happen. I thought we also

Re: softraid(4) disks are of wrong size

On 12/20/10 18:26, Kenneth R Westerback wrote: ... Can you provide the details on the exact panic you saw? Just to make sure when an issue is reproduced we know we are working on the same problem. Debugger panic sr_crypto_finish_io sr_crypto_intr sdstrategy spec_strategy VOP_STRATEGY

nc(1) - fix use of certificates for TLS

Hello, the use of certificates for TLS didn't work with nc(1). Fix is attached. Best regards Andreas Index: netcat.c === RCS file: /cvs/src/usr.bin/nc/netcat.c,v retrieving revision 1.149 diff -u -p -u -r1.149 netcat.c --- netcat.c

starttls support for nc(1)

Hello, I've written some code which basically allows to emulate the behavior of starttls-enabled clients and servers via nc(1). I mainly use it for debugging purposes since it is more generic than openssl s_client -starttls. However, the solution is probably ugly since I'm not very

specify curves via ecdhe statement in httpd.conf

Hello, after reading the LibreSSL accouncement from today, I assumed that specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 and P-384 on current. I've noticed that "auto" enables only curves x25519 and P-256 (which is what I'd want to use - but somehow unexpected with

Re: specify curves via ecdhe statement in httpd.conf

On 02/05/17 11:13, Andreas Bartelt wrote: ... The following combinations were tested: server httpd with ecdhe "secp384r1" & server nginx with ssl_ecdh_curve secp384r1; (identical results) connect via openssl [secp384r1]: fails connect via eopenssl [secp384r1]: fa

Re: specify curves via ecdhe statement in httpd.conf

On 02/05/17 07:41, Joel Sing wrote: On Saturday 04 February 2017 15:51:02 Andreas Bartelt wrote: On 02/04/17 05:26, Joel Sing wrote: On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: Hello, after reading the LibreSSL accouncement from today, I assumed that specifying ecdhe "

Re: specify curves via ecdhe statement in httpd.conf

On 02/06/17 14:44, Joel Sing wrote: On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote: - What type of public certificate are you using (RSA or ECDSA)? ECDSA with P-256. Certificate signed by letsencrypt (via RSA). Must-staple is enabled - that's why I'm also using the ocsp line

Re: specify curves via ecdhe statement in httpd.conf

On 02/05/17 15:41, Joel Sing wrote: On Sunday 05 February 2017 11:13:16 Andreas Bartelt wrote: On 02/05/17 07:41, Joel Sing wrote: You can just specify X25519 as a group - it will not appear in `openssl ecparam -list_curves' since it is not a standard EC curve. thanks - I didn't notice

Re: specify curves via ecdhe statement in httpd.conf

On 02/04/17 05:26, Joel Sing wrote: On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: Hello, after reading the LibreSSL accouncement from today, I assumed that specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 and P-384 on current. This is corre

Re: specify curves via ecdhe statement in httpd.conf

rd to the negotiated curve for ecdhe. On Sat, Feb 4, 2017 at 09:13 Bob Beck <b...@obtuse.com> wrote: On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt <o...@bartula.de> wrote: On 02/04/17 05:26, Joel Sing wrote: On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: He

add option for disabling TLS session tickets to libttls

Hello, LibreSSL enables the use of the TLS session ticket extension [RFC 5077, or, according to comments in source code its older version 4507] by default, and libtls currently doesn't provide an API call for disabling this feature. Consequently, OpenBSD's httpd has TLS session tickets

Re: Enable Camellia ciphers with SHA-2 family HMAC

On 08/25/16 15:58, Brent Cook wrote: No objection here. Anyone else? in general, I personally would only add further cryptographic primitives to a TLS configuration in case they provide sufficiently distinctive advantages over the already available primitives. I don't see this for Camellia

Re: Default softraid crypto PBKDF2 rounds

On 09/07/16 09:16, Damien Miller wrote: On Tue, 6 Sep 2016, David Coppa wrote: Il 6 settembre 2016 14:56:32 CEST, Filippo Valsorda ha scritto: Hello, I recently had the occasion to dive into the softraid crypto code [1] and was quite pleased with the cleanliness of it all.

Re: add option for disabling TLS session tickets to libttls

On 08/22/16 08:17, Claudio Jeker wrote: On Sun, Aug 21, 2016 at 02:25:15PM -0400, Ted Unangst wrote: Andreas Bartelt wrote: Since the use of TLS session tickets potentially interferes with forward secrecy on a per-session basis, I'd personally prefer an opt-in in libtls as well as in httpd

Re: Problems with rdomain and net/if.c v1.455

On 11/09/16 16:43, Martin Pieuchot wrote: On 09/11/16(Wed) 16:29, Andreas Bartelt wrote: On 11/09/16 15:11, Martin Pieuchot wrote: ... Fair point. What about adding backward compatible goo to help people doing the transition: # ifconfig lo1 create # ifconfig vether0 rdomain 1 warning: lo1

Re: Problems with rdomain and net/if.c v1.455

On 11/09/16 15:11, Martin Pieuchot wrote: ... Fair point. What about adding backward compatible goo to help people doing the transition: # ifconfig lo1 create # ifconfig vether0 rdomain 1 warning: lo1 cannot be used for rdomain 1 # ifconfig lo lo0: flags=8049 mtu

Re: Problems with rdomain and net/if.c v1.455

On 11/09/16 11:55, Martin Pieuchot wrote: ... I'm going to commit this fixed diff unless somebody has something to add. I've tested this - it works for me. Best regards Andreas

Re: Problems with rdomain and net/if.c v1.455

On 11/10/16 20:36, Andreas Bartelt wrote: On 11/09/16 11:55, Martin Pieuchot wrote: ... I'm going to commit this fixed diff unless somebody has something to add. I've tested this - it works for me. Sorry, I probably was too fast - I've observed a problem with smtpd in rdomain 0 (which

Default TLS configuration of httpd / libtls

After responding to a question on misc@ ( http://marc.info/?l=openbsd-misc=150280482525307=2 ), I've noticed that the part of my response with regard to default-enabled TLS cipher suites on current was wrong. I was testing with an ECDSA-based instead of an RSA-based certificate which renders

[patch] make cipher list preference configurable in httpd

The following patch makes the TLS cipher list preference (server vs. client) configurable in httpd (like in relayd): Index: src/usr.sbin/httpd/config.c === RCS file: /cvs/src/usr.sbin/httpd/config.c,v retrieving revision 1.53 diff

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

argument is optional. If these arguments are not explicitly provided, the next update field will not be set. On Sat, Sep 2, 2017 at 11:28 AM, Andreas Bartelt <o...@bartula.de> wrote: ocspcheck effectively treats a missing nextUpdate like an error, i.e., it always provides a w

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

argument is optional. If these arguments are not explicitly provided, the next update field will not be set. On Sat, Sep 2, 2017 at 11:28 AM, Andreas Bartelt <o...@bartula.de> wrote: ocspcheck effectively treats a missing nextUpdate like an error, i.e., it always provides a w

Re: SSHFP with EDNS0/DNSSEC

On 07/12/17 18:49, Jeremie Courreges-Anglas wrote: Eric Faurot writes: On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote: Hi, earlier this year, jca@ worked on support for DNSSEC and the EDNS0 extension [1] and committed this work at [2] (thanks!). I tried

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

On 09/06/17 16:24, Bob Beck wrote: effectivelyu providing a limitless OCSP staple is kind of stupid - you may as well simply *not staple* I guess a stapled response without the next_update field set would be treated as valid until the client considers this_update to be too old (for

[patch] ocspcheck: nextUpdate is optional according to RFC 6960

ocspcheck effectively treats a missing nextUpdate like an error, i.e., it always provides a warning and no staplefile is written out. According to RFC 6960, the nextUpdate field is optional. The following patch should handle this case more gracefully and include a suitable debug message only

Re: Add Intel Optane P1600X to pcidevs

Hi, forgot to include the corresponding dmesg output: nvme1 at pci20 dev 0 function 0 "Intel P1600X" rev 0x00: msix, NVMe 1.1 nvme1: INTEL SSDPEK1A118GA, firmware U5110550, serial BTOC14120X9P118B Could this please be committed? Best regards Andreas On 8/20/23 14:00, Andreas Bar

Add Intel Optane P1600X to pcidevs

Hi, Intel Optane P1600X Series SSDs are not yet identified in CURRENT (e.g., https://www.intel.com/content/www/us/en/products/sku/211867/intel-optane-ssd-p1600x-series-118gb-m-2-80mm-pcie-3-0-x4-3d-xpoint/specifications.html ). The following patch adds a suitable description (tested with

Add Intel Optane 900P/905P NVMe

Hi, Intel Optane 905p NVMe devices were not yet recognized in CURRENT (e.g., https://ark.intel.com/content/www/us/en/ark/products/148607/intel-optane-ssd-905p-series-380gb-m-2-110mm-pcie-x4-20nm-3d-xpoint.html ). I've managed to get it working with the following diff: Index: pcidevs

Re: Add Intel Optane 900P/905P NVMe

On 8/16/22 05:22, Jonathan Gray wrote: On Sun, Aug 14, 2022 at 04:03:59PM +0200, Andreas Bartelt wrote: Hi, Intel Optane 905p NVMe devices were not yet recognized in CURRENT (e.g., https://ark.intel.com/content/www/us/en/ark/products/148607/intel-optane-ssd-905p-series-380gb-m-2-110mm-pcie-x4

Re: Add Intel Optane DC to pcidevs

On 12/2/22 04:54, Jonathan Gray wrote: On Sun, Nov 27, 2022 at 03:21:45PM +0100, Andreas Bartelt wrote: Hi, Intel Optane DC SSDs are not yet identified in CURRENT (e.g., https://ark.intel.com/content/www/us/en/ark/products/201861/intel-optane-ssd-dc-p5800x-series-400gb-2-5in-pcie-x4-3d

Add Intel Optane DC to pcidevs

Hi, Intel Optane DC SSDs are not yet identified in CURRENT (e.g., https://ark.intel.com/content/www/us/en/ark/products/201861/intel-optane-ssd-dc-p5800x-series-400gb-2-5in-pcie-x4-3d-xpoint.html ). The following patch gets rid of the "unknown product 0x4140" output of the corresponding