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
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 118G
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
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 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
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
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 this
with SSHFP re
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 ocspcheck
ndays 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 wrote:
ocspcheck effectively treats a missing nextUpdate like an error, i.e., it
always provides a warning and no staplefile is wr
ndays 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 wrote:
ocspcheck effectively treats a missing nextUpdate like an error, i.e., it
always provides a warning and no staplefile is wr
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 in
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
After responding to a question on misc@ (
http://marc.info/?l=openbsd-misc&m=150280482525307&w=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 render
On 02/07/17 12:32, Joel Sing wrote:
On Monday 06 February 2017 20:18:48 Andreas Bartelt wrote:
Yes, right - thanks. I wasn't aware that this is actually a MUST
requirement from RFC 4492. I'm quite surprised that the "Supported
Elliptic Curves Extension" is also used in
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 ocs
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 n
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]: fails
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 "
regard to the negotiated curve
for ecdhe.
On Sat, Feb 4, 2017 at 09:13 Bob Beck wrote:
On Sat, Feb 4, 2017 at 07:51 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 f
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
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 reg
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
r
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
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
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 32768
index 8 priority
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. However, I found
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
On 08/27/16 12:32, Guenther Niess wrote:
...
Or do you think we should change
+ .algo_strength = SSL_HIGH,
to
+ .algo_strength = SSL_MEDIUM,
this matter seems to be highly subjective. I personally don't like and
don't make use of the LOW/MEDIUM/HIGH keywords for c
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
On 08/21/16 20:25, 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 with regard to its usage. However, such a
semantic change woul
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 enabl
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
proficient
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
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 2
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 regar
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=8843 mtu 1500
hwfeatures=36
lladdr X:X:X:X:X:X
priority: 0
groups: egress
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: flags=8b43
mtu 1500
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" ha scritto:
Unfortunately, I have no clue where to go from there. I'd like to
connect to vodafone in Ger
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
Con
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 s
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
===
RCS
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!
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 reada
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
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 set
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 used
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
sr_startw
On 12/20/10 17:11, Mark Kettenis wrote:
Date: Mon, 20 Dec 2010 16:12:24 +0100
From: Claudio Jeker
With the change in rev. 1.99 of subr_pool() changing the limit
will no longer set the high watermark as well.
This causes i386 to stop forwading packets on very busy systems because
the pool thread
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 alwa
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 softr
Hello,
I've noticed that the size of softraid(4) disks is one sector too large.
In the following description, the native disk is sd4c (which is of type
RAID), and the corresponding virtual softraid(4) disk will be sd5. I
will assume that sd5 is of discipline CRYPTO, but the problem should be
t
51 matches
Mail list logo
