8 Replies Latest reply on Jun 18, 2018 11:05 PM by grsr

    TLS failure, ERROR_INVALID_RECORD (5007) , only occurs on certain wifi

    user_108962310

      I am having an issue with an old version of the SDK, 3.1.2, with devices that are presently in the field. I am having an unexplained issue wherein I get return 5007 from `wiced_tcp_stream_read`, indicating an invalid TLS record.


      The TCP+TLS stream is being read in a mechanism whereby a file is downloaded by manually opening a socket, setting up a TLS context, creating a stream, constructing an HTTP request, sending it to the stream, parsing the HTTP header response, and then grabbing the binary body 1024 bytes at a time until the end.

       

      The particularly odd thing is that this code works fine on 95% of wifi AP's, but on a mobile hotspot wifi (including an iPhone 6S), it will hit this error at the same point through the download. The file is ~300KB, and the error will happen at ~80K, repeatably, always in the same length through stream.

       

      I am running on a platform that is *somewhat* resource constrained, with 128KB of RAM. However, again: it works fine on some WiFi AP's, and not on others.

       

      I have tested this with an nginx server that uses both 16KB TLS records and 2KB TLS records, per the `ssl_buffer_size` parameter, and the problem exists for both cases.

      I am running it on hardware with a debug build, but no debug or malloc-related breakpoints or hardfaults are being hit.

       

      As far as I can tell, the failure is in `wiced_tls_receive_packet`, line 750, on the call to :
      result = tls_get_next_record( context, &record, timeout, TLS_RECEIVE_PACKET_IF_NEEDED );

       

      Unfortunately, I can't go deeper than that, since BESL in 3.1.2 is a binary.

      I don't quite know enough about TLS at the moment to try and do debugging around the results within `wiced_tls_receive_packet`.

       

      Any ideas as to why this is happening?