5 Replies Latest reply on Oct 6, 2014 7:46 PM by alex.damosys_1740326

    The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo

    sam.lin

      My application uses wiced_tcp_server_start() to implement a tcp server.

      When test build with NetX/NetX_Duo, wiced_tcp_server_start() call in

      my tcp server always return WICED_ERROR.

      I found if I comment out the code to start http server, then my tcp server runs well.

      If I run my tcp server earlier, then http server will fail at wiced_tcp_server_start().

      The http server also use wiced_tcp_server_start(), so

      It looks like wiced_tcp_server_start() can only be called once on NetX/NetX_Duo.

       

      This issues does not happen on FreeRTOS+LwIP.

        • 1. Re: The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo
          grga

          Just want to confirm, this is being done on different ports?  Correct?

          • 2. Re: The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo
            sam.lin

            Yes, it's listen on different port ( port 23).

             

            I think it's very easy to test it by:

            1. download the test_server.c from http://community.broadcom.com/thread/2561?sr=stream&ru=2286

            2. Modify the test_server.c and add printing the return value of wiced_tcp_server_start()

               You might also want to print the return value of wiced_tcp_server_start() in http daemon.

            3. Add the test_server.c code to apps/snip/ping_webserver

            4. put start_test_server() before/after calling wiced_http_server_start().

               Then you can see either start_test_server() fails or wiced_http_server_start() fails

               at wiced_tcp_server_start() call. (depends on which one is called first.)

            • 3. Re: The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo
              sam.lin

              hi,

              Just want to know if this bug will be fixed in sdk-3.1.1?

               

              For NetX/NetX_Duo build:

              The bug is that the second wiced_tcp_server_start() call always fail.

              So I cannot use wiced_tcp_server_start() to implement tcp server because

              http server uses wiced_tcp_server_start() already.

              This is 100% reproducable.

               

              I found yet another issue with LwIP build:

              The second wiced_tcp_server_start() works in LwIP, so I have my tcp server

              running. However, I found if I use browser to connect to the web page, then

              my tcp server can only accept 1 client. the second client always fails.

               

              If I try to connect my tcp server first, I can have 5 clients.

              However, then http server has no response (and one of the client will be

              disconnected automatically , probably due to the http request).

              • 4. Re: The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo
                sam.lin

                 

                I found yet another issue with LwIP build:

                The second wiced_tcp_server_start() works in LwIP, so I have my tcp server

                running. However, I found if I use browser to connect to the web page, then

                my tcp server can only accept 1 client. the second client always fails.

                 

                If I try to connect my tcp server first, I can have 5 clients.

                However, then http server has no response (and one of the client will be

                disconnected automatically , probably due to the http request).

                My understanding of this problem is:

                The system has a limitation for the number of tcp socket can be created at

                the same time.

                A wiced_tcp_server_start() may create at most 5 tcp sockets at the same time.

                However, we don't know how many tcp sockets are created by a http server.

                While using wiced_tcp_server_start() for other tcp server, it may fail to

                to create socket because of reaching system limitation.

                So if my tcp server create 5 tcp socket and keep the connection alive, it's

                possible http_server always fails to create tcp socket and thus no response.

                 

                Currently the number of tcp socket can be created at the same time is a very

                small number. And I have asked a question that is this configurable, but still

                don't get a correct answer.

                I tried increase WICED_DEFAULT_TCP_LISTEN_QUEUE_SIZE,

                WICED_MAXIMUM_NUMBER_OF_ACCEPT_SOCKETS, and

                WICED_MAXIMUM_NUMBER_OF_SOCKETS_WITH_CALLBACKS, but it does not work.

                 

                Yet another issue I have reported is that once reach the maximum number of

                tcp socket can be created [1], I'm not able to create any tcp socket anymore.

                As a result, either my tcp server always fails or the http_server always no

                response.

                 

                Can someone help on this?

                 

                [1] http://community.broadcom.com/message/7080#7080

                • 5. Re: The second wiced_tcp_server_start() call always fails with NetX/NetX_Duo
                  alex.damosys_1740326

                  I also have similar issues. I am suing STA and AP interface and use TCP Server for each interface.

                   

                  1. In  demo.s2w-BCM943362WCD4_DAMOSYS NO_BUILD_BOOTLOADER=1 download run

                      it might be "ThredX + NetX"

                   

                    if I call "wiced_tcp_server_start" for STA interface then it works.

                  and another    call "wiced_tcp_server_start" for AO interface then it fails

                   

                   

                      But in FreeRTOS+LwIP ,    Both works fine.