On 07/30/17 11:14 PM, David Oberhollenzer wrote: > On 07/24/2017 11:10 PM, Dave Watson wrote: > > On 07/23/17 09:39 PM, David Oberhollenzer wrote: > >> After fixing the benchmark/test tool that the patch description > >> linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make > >> sure that the server and client actually *agree* on AES-128-GCM, > >> I simply ran the client program with the --verify-sendpage option. > >> > >> The handshake and setting up of the sockets appears to work but > >> the program complains that the sent and received page contents > >> do not match (sent is 0x12 repeated all over and received looks > >> pretty random). > > > > The --verify functions depend on the RX path as well, which has not > > been merged. Any programs / tests using OpenSSL + patches should work > > fine. > > > > If you want to use the tool, something like this should work, so that > > the receive path uses gnutls: > > > > ./server --no-echo > > > > ./client --server-port 12345 --sendfile some_file --server-host localhost > > > > Thanks! This appears to work as expected (output from the server matches the > input from the client and the pcap dumps look fine). > > From briefly browsing through the code of the test tool I was initially under > the impression that it would generate an error message and terminate if an > attempt was made at configuring ktls for the RX path. > > Anyway, I already read in the patch description that RX wasn't included yet, > still requires a few cleanups and would follow at some point. > > Is there currently a "not-so-clean" version of the RX patches floating around > somewhere that we could take a look at?
I dumped the current state here. Still plenty rough but at least passes --verify-transmission for me. https://github.com/ktls/net_next_ktls/tree/tls_recv_net_next and config changes to af_ktls-tool https://github.com/ktls/af_ktls-tool/tree/RX
