On 1/6/22 5:58 AM, Gaurav Jain wrote:
Hi
-Original Message-
From: John Baldwin
Sent: Thursday, January 6, 2022 12:26 AM
To: Gaurav Jain ; bor...@mellanox.com; openssl-
us...@openssl.org
Cc: Varun Sethi ; Pankaj Gupta
Subject: [EXT] Re: KTLS with openssl 3.0 fail with error ENOTCONN
n socket since ktls_enable() is called when sockets are created
by libssl.
For KTLS to work on the server side on Linux what you need to find out is when
ktls_enable() is invoked on the socket returned by accept() and why that is
failing.
--
John Baldwin
an internal buffer in libc?
--
John Baldwin
BIOs to and then manually
read/wrote their contents on its tunnel socket).
--
John Baldwin
On 8/18/20 9:49 AM, Matt Caswell wrote:
>
>
> On 17/08/2020 18:55, John Baldwin wrote:
>> 1) Is 'auth_level' supposed to work for this? The CHANGES.md change
>>references SSL_CTX_set_security_level and openssl(1) claims that
>>'-auth_level
7; server requires an explicit -cipher as well).
So I guess two questions:
1) Is 'auth_level' supposed to work for this? The CHANGES.md change
references SSL_CTX_set_security_level and openssl(1) claims that
'-auth_level' changes this? Is the CHANGES.md entry wrong and only
SECLEVEL=0 for the ciphers work by design?
2) The hang when using a 'master' client seems like a regression?
--
John Baldwin
On 6/10/20 3:48 PM, John Baldwin wrote:
> On 6/8/20 4:12 AM, Kurt Roeckx wrote:
>> On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
>>> At the moment there are 3 open PRs related to Kernel TLS offload
>>> support that I'm aware of:
>>>
&
On 6/8/20 4:12 AM, Kurt Roeckx wrote:
> On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
>> At the moment there are 3 open PRs related to Kernel TLS offload
>> support that I'm aware of:
>>
>> - 11589 adds TLS1.3 for Linux, has one approval from Matt Ca
ports tree, but it would be
really nice if 3.0 did not require additional patches out of the
box.
Thanks!
--
John Baldwin
fic case of s_client/s_server this actually uncovered a bug
> in s_server, which is why you see the problem there.
>
> Matt
>
> On 24/03/2020 23:35, John Baldwin wrote:
>> I replied to the original commit on GH but haven't seen any responses so
>> thought I would foll
BSD, and I
thought it was a bug in my changes until I finally narrowed it back to this
commit. It seems a bit odd for a normal close to trigger an error instead of
a clean EOF back from SSL_read().
--
John Baldwin
question is whether
>> there is assembler support. This is the hard part in terms of
>> effort. We currently have no such thing at all for RISC-V, and I
>> haven't seen any attempts to start such an effort... PRs would
>> certainly be welcome, but anyone who tries this will have to be
>> prepared for it to take a while to get into the main source.
>>
>> Cheers,
>> Richard
>>
>> --
>> Richard Levitte levi...@openssl.org
>> OpenSSL Project http://www.openssl.org/~levitte/
>> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.openssl.org%2f~levitte%2f&c=E,1,X0wuSd-kz2nVhT_NOTOEEEyCfRQ3PVlEpzPg7qMVOE18vBdtM4EJjJ0PDdArARBsvQZdWJpbcy94bbUgzuKmj9jsBIiAzT87yPNJQ_aU-tOjP9VR4huaxBYl6g,,&typo=1>
>>
>>
>
--
John Baldwin
SSL_sendfile()). One
could perhaps have a SSL_writev() that did a single system call for KTLS
and fell back to a loop of SSL_write() calls otherwise. However, you
wouldn't have a SSL_readv() equivalent which might feel odd from an API
perspective.
--
John Baldwin
On 12/14/19 2:09 AM, Matt Caswell wrote:
>
>
> On 13/12/2019 23:52, John Baldwin wrote:
>> I've recently been working on adding support for kernel TLS offload
>> to FreeBSD and have some patches merged into master already along
>> with a couple of open reviews (an
ends" is the answer then I can come
up with a candidate patch series.
--
John Baldwin
15 matches
Mail list logo
