• State Verified Answer
  • Replies 16 replies
  • Subscribers 87 subscribers
  • Views 4549 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 277075
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Calling socket connect() triggers errno=95

Loren Rogers

Hello,

I am offloading sockets in config.  I instantiate a socket, set the send/recv timeouts, and then call connect().  It's returning a 95 which is EOPNOTSUPP.  I was able to step via debug all the way down to a nrf_connect().  But that was it.

Anyone have any ideas of what I'm doing wrong?

/Loren

Parents
  • 0

    Hi Loren,

    Is this a customize board? Did you test with a TLS connection? If the connection is lost during data transmission, there can be an error thrown (for TLS, it is normally -95). Could you check if the signal strength (via AT+CESQ) is good when this occurs?

    If the problem still exists, could you provide your current modem firmware version and a modem trace when the failure happens? 

    Best regards,

    Charlie

  • 0 in reply to Charlie

    Hi Charlie,

    It is the standard nrf9160 dk board.  I'm not going to lie.  I am totally lost and pretty overwhelmed.  Especially when it comes to what CONFIG options I need.  All I want is an application that will create and connect to a TLS socket (443) to ANY server I choose (not just nRF Cloud) and be able to call the http_client_req() method with my particular REST method and an url.  I come from the iOS/Android world where there are libraries that do this automatically.  Could you please let me know what CONFIG options I need and some source code on how to set this up?

    The other thing that I find infuriating is that I can't seem to reliably debug this thing.  I'll tap 'step over' and it jumps to some other place I have no clue about.  And I believe I've set the NO_OPTIMIZATIONS configuration but I still can't see some local variables.

    Thanks!

    /Loren

  • 0 in reply to Loren Rogers

    Hi Loren,

    I just test with Trace Collector V2 preview v0..0.11, PCAP seems not to work, please use RAW and convert the log data later.

    Also, remember to try with a different serial port if it still does not work.

    Best regards,

    Charlie

  • 0 in reply to Charlie

    Hi Charlie,

    I seem to be able to now capture.  But every time I try to convert to pcap I get:

    2021-09-29T13:22:58.931Z ERROR Failed conversion to pcap: end of file reached while searching db uid plugin path: C:\Users\lrogers\.nrfconnect-apps\node_modules\pc-nrfconnect-tracecollector-preview\node_modules\nrf-monitor-lib-js\Release\win32-ia32\nrfml-insight-source.nrfml
    2021-09-29T13:22:58.931Z DEBUG Full error: {"error_code":100,"message":"end of file reached while searching db uid plugin path: C:\\Users\\lrogers\\.nrfconnect-apps\\node_modules\\pc-nrfconnect-tracecollector-preview\\node_modules\\nrf-monitor-lib-js\\Release\\win32-ia32\\nrfml-insight-source.nrfml","origin":"Error when running nrfml operation worker."}

    I really wish Nordic's stuff worked reliably.  This is frustrating.

  • 0 in reply to Loren Rogers

    What about the size of your trace bin file? Can you share it with me?

    I suggest you recording raw format with Trace Collector and monitoring the log through the serial terminal at the same time, this can make sure the whole process is recorded.

    Trace Collector V2 preview is still under preview, so do not expect to hight to it now.

    Best regards,

    Charlie

  • 0 in reply to Loren Rogers

    I just found something interesting that could be a problem: I ran Postman on 2 separate servers.  Both servers use TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 for the cipher.  I noticed that Nordic does not support this.  It does support TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384. (CBC vs. GCM).  Would this cause what I am seeing? Also could we add our own 'TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384' encryption somehow?


Reply
  • 0 in reply to Loren Rogers

    I just found something interesting that could be a problem: I ran Postman on 2 separate servers.  Both servers use TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 for the cipher.  I noticed that Nordic does not support this.  It does support TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384. (CBC vs. GCM).  Would this cause what I am seeing? Also could we add our own 'TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384' encryption somehow?


Children
Related
Terms of service