• Locked Locked
  • Replies 6 replies
  • Subscribers 40 subscribers
  • Views 709 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BUG in 1.11.1 firmware - closesocket takes 3.6 Seconds

david sidrane
Prodigy 160 points

 Firmware version is: 1.24 

In the scenario were I send data on the socket, perform the select loop for up to 30 seconds, and get a response from the server.

The closesocket call lasts 94 ms

A) send
B) enter a select loop
            } 30 Seconds
C) receive
D) Close
E) return from close 94 Ms later

In the scenario were I send data on the socket, perform the select  loop,  but before there is a response from the server. I close the socket.

Then the closesocket call lasts 3.6 Seconds (see trace and pcap) How can I reduce this time?

A) send
B) enter a select loop - abort it after 10-15 Seconds
C) Close 
D) return from close 3.6 Seconds later

Update:

The only work around that works is to do a dummy send of 1 byte right before the closesocket call.

TI, please respond!

  • in reply to david sidrane
    Prodigy 160 points

    More Bugs  in 1.11.1 AKA 1.24!

    In the quest to keep track of the "number" of profiles stored via smartConfig I discovered that the nvmem operations  are rather halfbaked.

    The docs say nvmem_read returns the length. The code does not return the length. More over the management of the data is bad. A read operation on an un-created file reruns data!

    Even after fixing the nvmem_read to return length, the data can be invalid if reading from an file that has not been created.

    signed long nvmem_read ( unsigned long  file_id,
    unsigned long  length,
    unsigned long  offset,
    unsigned char *  buff 
    )

    Reads data from the file referred by the ulFileId parameter. Reads data from file ulOffset till length. Err if the file can't be used, is invalid, or if the read is out of bounds.

    nvmem_read

    Parameters
    ulFileId nvmem file id:
    NVMEM_NVS_FILEID, NVMEM_NVS_SHADOW_FILEID, NVMEM_WLAN_CONFIG_FILEID, NVMEM_WLAN_CONFIG_SHADOW_FILEID, NVMEM_WLAN_DRIVER_SP_FILEID, NVMEM_WLAN_FW_SP_FILEID, NVMEM_MAC_FILEID, NVMEM_FRONTEND_VARS_FILEID, NVMEM_IP_CONFIG_FILEID, NVMEM_IP_CONFIG_SHADOW_FILEID, NVMEM_BOOTLOADER_SP_FILEID, NVMEM_RM_FILEID, and user files 12-15.
    ulLength number of bytes to read
    ulOffset ulOffset in file from where to read
    buff output buffer pointer
    Returns
    number of bytes read, otherwise error.
  • Prodigy 30 points

    I am experiencing a similar delay with v1.11

    I have two UDP sockets and a TCP socket, all of which regularly poll for data (the TCP socket uses nonblocking recv calls rather than select). When only one of the UDP sockets is open and polling, the call to closesocket on the TCP socket returns quickly. When both UDP sockets are open and polling, however, the call to closesocket on the TCP socket consistently returns after 3.6 seconds.

    closesocket is only called on the TCP socket after the module detects a remote close from the server. Performing a one-byte dummy send before calling closesocket, as described by the previous poster, does not make a difference. I'd appreciate any help with this issue.

  • in reply to Derek F
    TI__Mastermind 27095 points

    Hi David, Derek,

    This is how I understand this situation. Please correct me wherever necessary.

    1. From the air capture traces I can see that the we are sending a FIN,ACK to the remote device and the remote device responds with an ACK.
    2. At this point, CC3000 enters FIN-WAIT-2 state, waiting for the FIN,ACK from the remote device and thereafter close the connection.
    3. But CC3000 waits for some time only to learn that there was no FIN,ACK sent from the remote device(may be because of the CLOSE-WAIT on the remote) and then closes the connection on its side.

    May be this is why you see delay of few seconds on CC3000 side in certain cases. Are you not performing a closesocket on the remote side?

    Thanks & Regards,
    Raghavendra

  • in reply to Raghavendra Shenoy
    Prodigy 160 points

    Raghavendra,

    Thank you for the feedback! The remote side is Apache. The header was sent with Connection: close in both instances.

    The difference I pointed out is: if the connection is closed with having received data prior to the closes, it closes in 94 ms.

    Without sending receiving data, it takes 3.6 seconds. But if I sent 1 character, then do the close it will not wait.

    Furthermore it keep sending keep-alives on the closed socket.

    Perhaps a complete tcp-dump would help.

    David

  • in reply to david sidrane
    TI__Mastermind 27095 points

    Hi David,

    I understand. The complete logs would help. Also, please check if the Close sequece finishes completely (4 ways), in cases where you see this issue.

    Thanks & Regards,
    Raghavendra