network.framework handshaking failure occasionally

Question

Created Apr ’22

Replies 4

Boosts 0

Participants 1

I have an application, it was using OpenSSL + Socket, recently I migrated the client to use Network.framework, basically it is running well, but occasionally it encounter the handshaking problem:

default	11:54:01.757515-0600	caphost	boringssl_context_info_handler(2028) [C80:1][0x7f8e2413ad90] Client handshake started
        default	11:54:01.757546-0600	caphost	boringssl_context_info_handler(2045) [C80:1][0x7f8e2413ad90] Client handshake state: TLS client enter_early_data
        default	11:54:01.757643-0600	caphost	boringssl_context_info_handler(2045) [C80:1][0x7f8e2413ad90] Client handshake state: TLS client read_server_hello
        default	11:54:01.786245-0600	caphost	boringssl_context_info_handler(2045) [C80:1][0x7f8e2413ad90] Client handshake state: TLS client read_server_certificate
        default	11:54:01.786361-0600	caphost	boringssl_context_info_handler(2045) [C80:1][0x7f8e2413ad90] Client handshake state: TLS client read_certificate_status
        default	11:54:01.786386-0600	caphost	boringssl_context_info_handler(2045) [C80:1][0x7f8e2413ad90] Client handshake state: TLS client verify_server_certificate
        default	11:54:01.786588-0600	caphost	boringssl_context_evaluate_trust_async(1635) [C80:1][0x7f8e2413ad90] Performing local trust evaluation
        default	11:54:01.786619-0600	caphost	boringssl_context_evaluate_trust_async_internal(1508) [C80:1][0x7f8e2413ad90] Asyncing for internal verify block
        default	11:54:01.788428-0600	caphost	Trust evaluate failure: [leaf AnchorTrusted SSLHostname]
        default	11:54:01.788604-0600	caphost	boringssl_context_evaluate_trust_async_internal_block_invoke_2(1481) [C80:1][0x7f8e2413ad90] Returning from internal verify 
            block with result: false (Error Domain=NSOSStatusErrorDomain Code=-67843 "“Vodde” certificate is not trusted" 
            UserInfo={NSLocalizedDescription=“Solstice” certificate is not trusted, NSUnderlyingError=0x600001ffbc00 {Error Domain=NSOSStatusErrorDomain Code=-67843 
            "Certificate 0 “Vodde” has errors: SSL hostname does not match name(s) in certificate, Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 
            “Vodde” has errors: SSL hostname does not match name(s) in certificate, Root is not trusted;}}})

when this problem happens, I use old OpenSSL+Socket client to connect to it, it will be successful and grab the video stream w/o problem.

This problem happens about 1 in 10, I supposed if this happen, it shall always happen, don't get why it is not consistent, is it the bug of Network.framework? my system is Monterey 12.3.1 on 2018 Mac mini.

Thanks :)

Boost

Answer 1

stang OP

Apr ’22

BTW, if we call

 auto sec_options = nw_tls_copy_sec_protocol_options(tls_options);

Do we need nw_release(sec_options) after using sec_options?

0

Answer 2

stang OP

Apr ’22

Also, this problem

nw_protocol_boringssl_signal_connected(724) [C7:1][0x7f793592b300] TLS connected [version(0x0303) ciphersuite(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) group(0x0017) signature_alg(0x0401) alpn(nil) resumed(0) offered_ticket(0) false_started(0) ocsp_received(0) sct_received(0) connect_time(96ms) flight_time(88ms) rtt(77ms) write_stalls(0) read_stalls(4)]

0

Answer 3

stang OP

Apr ’22

Apple says network.framework is better than OpenSSL+Socket, I have problem in proving that, anyone has official way of receiving the data?

 void handleIncomingVideo( void* caller, nw_connection_t connection = nullptr )
  {
  // init processing
  ...
  //handle incoming data
 nw_connection_receive(
        connection,
        1,
        bufLen,
        ^( dispatch_data_t   content,
          nw_content_context_t context,
          bool         is_complete,
          nw_error_t      receive_error ) {
          auto isBufferBeginWithStartCode = []( const char* frame ) -> bool {
            return ( frame[0] == 0x00 && frame[1] == 0x00 && frame[2] == 0x00 && frame[3] == 0x01 );
          };

          if ( content != nullptr )
          {
            // handle received data here
            ....
            // 2. schedule next incoming video recv
            nw_retain( connection );
            handleIncomingVideo( caller, connection );
          }
          else
          {
            // Context is nullptr, schedule the next recv
            if ( receive_error == nullptr )
            {
              nw_retain( connection );
              handleIncomingVideo( caller, connection );
            }
          }
        } );

The video (H264 stream) quality is not as good as my old openssl + socket, and sometime cannot no video data come in, while old openssl+socket doesn't have this issue. Am I using it correct?

0

Answer 4

stang OP

Apr ’22

{Looks bad in comment, put it here}

Apple says network.framework is better than OpenSSL+Socket, I have problem in proving that, anyone has official way of receiving the data?

 void handleIncomingVideo( void* caller, nw_connection_t connection = nullptr )
  {
  // init processing
  ...
  //handle incoming data
 nw_connection_receive(
        connection,
        1,
        bufLen,
        ^( dispatch_data_t   content,
          nw_content_context_t context,
          bool         is_complete,
          nw_error_t      receive_error ) {
          auto isBufferBeginWithStartCode = []( const char* frame ) -> bool {
            return ( frame[0] == 0x00 && frame[1] == 0x00 && frame[2] == 0x00 && frame[3] == 0x01 );
          };
          if (is_complete && content == nil) {
            loggerEx(LOG_INFO, "Receiver done with video data!");
            return;
          }
          if ( content != nullptr )
          {
            // handle received data here
            ....
            // 2. schedule next incoming video recv
            nw_retain( connection );
            handleIncomingVideo( caller, connection );
          }
          else
          {
            // Context is nullptr, schedule the next recv
            if ( receive_error == nullptr )
            {
              nw_retain( connection );
              handleIncomingVideo( caller, connection );
            }
          }
        } );

The video quality is not as stable as my old openssl + socket client, the same video(H264 stream) server, mostly the video quality is as expected, but sometime the video is blocky(missing data, not network issue since never happen with openssl+socket client), and sometime there is no video data come in, while old openssl+socket doesn't have this issue.

Am I using it correct?

0