2 Replies Latest reply on Jul 16, 2018 4:43 AM by NiMc_1688136

    tcp abort erorr returned from wiced_tcp_connect ??


      SDK 6.2

      OS: FreeRTOS

      LwIP: 6.0.3


      Has anyone ran into an issue where wiced_tcp_connect returns WICED_ABORT?


      My custom application uses a 3rd party mqtt library where i wrote a sockets layer to wrap the wiced networking calls. I am using TLS. In wireshark I see my board resolve the server address and attempt to send the SYN packet, but it does not receive a response. My board attempts several re-transmissions until the error is returned. I am guessing this error means max retries reached.


      I have ran the code with TCP logs enabled for LwIP, but and i could see where nothing responds to the message and retries reached but there were no other clues.


      I have elimintated the server/connection as an issue by using a mqtt client on my PC and also openssl and both can connect. I even changed the server to a generic public one hosted by mosquitto.


      Additionally, If i run the httpbin_org demo, tcp + tls works fine, so it does not seem to be a LwIP stack issue.


      I have ran this code before with SDK 6.1, but I have since updated to 6.2.


      Any pointers on how to debug this as the problem seems to be on my end.

        • 1. Re: tcp abort erorr returned from wiced_tcp_connect ??

          First disable TLS and check if TCP connection is possible. Based on the description, are you trying to establish MQTT connection? You will need to check the interface between your custom sockets layer and LwIP layer to understand if there is any issue with how your sockets layer interacts with the LwIP layer. You can compare it with how WICED has implemented the interface by default.

          1 of 1 people found this helpful
          • 2. Re: tcp abort erorr returned from wiced_tcp_connect ??

            I finally found the issue.

            The TCP_ABORT message corresponds to retry limit reached, which is very confusing to track down. Eventually, I found out that a htons implementation in the 3rd party library was not being compiled correctly due to a broken define and the default behavior of the preprocessor. An incorrect htons function reverses the byte order of the server port, resulting in the server not responding to my connection attempt.

            1 of 1 people found this helpful