CC3220: Problem with sl_Close - no ACK from device

Shamil Farsiev

Part Number: CC3220

Hi again, everyone!

I have a VERY BIG problem and this is a key issue to make a decision - use cc3220sf to start produce more than 10k devices or not?

i include a .pcap file with tcp dump.
192.168.20.100 is our server
192.168.20.102 is cc3220sf.

UPD: i am f**ked up
192.168.20.102 is our server
192.168.20.100 is cc3220sf.
IS CORRECT

a problem is: no ACK packet transmitting when the cc3220sf is close a socket.

in dump:

Socket connection is good - cc3220 SYN -> server SYN ACK -> cc3220 ACK

data exchange is good to.

BUT! close connection is not full - cc3220 SYN -> server SYN ACK -> NO cc3220 ACK -> server SYN ACK -> server SYN ACK -> server SYN ACK and etc.

how i have coded:

int32_t tcp_socket_close_and_wifistop(void)
{
    int32_t status = sl_Close(appData.sockID);
    ASSERT_ON_ERROR(status);
    UART_PRINT("    Socket close \n\r");
    int32_t status = sl_Stop(5000);
    ASSERT_ON_ERROR(status);
    return status;
}

int32_t status = sl_Stop(5000); with another time more than 5000 msecs doesn't help

I took it from power measure example.

here the picture:

why it is a PROBLEM:
my prototype wakes up every 180 sec and init a SECURED data exchange. and when the server send FIN ACK except DATA packet - cc3220 is freeze.

here the .pcap dump. open it in wireshark

cc3220sf_dump.pcap.zip

over 5 years ago

0 Benjamin Moore over 5 years ago

TI__Mastermind 29085 points

Hi Shamil,

I think I may need a bit of clarification. So these observations occur when your server closes the connection before the CC3220 attempts to close the connection with an sl_Close() call?

Best Regards,
Ben M

0 Shamil Farsiev over 5 years ago in reply to Benjamin Moore

Expert 1515 points

No. cc3220sf initiate close connection. Always.By sl_Close() call

I have this problem since march 2018 and i wrote about it. You said(or another TI forum guy) that I had wrote wrong procedure. But everything is correct. But NO ACK FROM CC3220SF

0 Jan D over 5 years ago in reply to Shamil Farsiev

Guru 73315 points

Hi,

Just a comment. At your Wireshark log you have first FIN request from 192.168.20.100 (=your server) not from 192.168.20.102 (=CC3220).

Jan

0 Shamil Farsiev over 5 years ago in reply to Jan D

Expert 1515 points

sorry! i have a mistake
192.168.20.102 is our server
192.168.20.100 is cc3220sf.

0 Shamil Farsiev over 5 years ago in reply to Jan D

Expert 1515 points

The problem is still relevant. Wait for your help.

0 Hnz over 5 years ago in reply to Shamil Farsiev

Guru 39650 points

Hi,

I don't know solution for this, but I have a few questions:
- What SDK version and ServicePack do you use?
- Can you simulate a issue in case of disabling secure connection, that means with normal TCP socket?
- Can you add small delay (lets say 1sec) before you call sl_Stop() just for a testing purpose.
- Can you retest with enabled SL_WLAN_ALWAYS_ON_POLICY power policy?

(note: I will be on-line only today before my 14 days vacation)

Jan

0 Shamil Farsiev over 5 years ago in reply to Hnz

Expert 1515 points

i'll retest and write at monday. luanchpad and my custom board are at work. but i did everything you said before.
1) i downloaded sdk at december 2017 and haven't update it still
2)i use tcp non-secured connection only.
3) i tested with very loooong delay - more than 120 secs. problem was.
4) SL_WLAN_ALWAYS_ON_POLICY - problem was.

and! i think you will ask about sl_Task(null);
i am use non_rtos with ccs compiler. semaphores and flags - state machine in main cycle. and sl_Task stay at top and call in every step of state machine.

upd:my friend check power_measure example - same problem.

0 Hnz over 5 years ago in reply to Shamil Farsiev

Guru 39650 points

Hi,

At point 3) I means this. Did you tried it?

sl_Close();
delay(1sec); // make sure that you call sl_Task() during this sleep
sl_Stop();

I use very complex RTOS application at CC3220SF and I haven't seen similar problem with ACK before.Suspicious number one for me is a calling sl_Stop(). It looks that NWP is disabled before is able send back ACK. But this should prevent timeout in sl_Stop(). I don't understand that behaviours. Maybe I will have a time test it with power_measurement example today, but without guarantee. It was used non-modified SDK demo nonrtos power_measurement?

Jan

0 Shamil Farsiev over 5 years ago in reply to Hnz

Expert 1515 points

did.

and did it again - delay was 180 seconds!

example is: nonos, ti compiler.

tomorrow check other combinations of examples + os + compiler

0 Shamil Farsiev over 5 years ago in reply to Hnz

Expert 1515 points

>> It was used non-modified SDK demo nonrtos power_measurement?
yes.

I would have to UP this thread until the problem is.

0 Shamil Farsiev over 5 years ago in reply to Hnz

Expert 1515 points

ok. i read docs a lot an do this

        SlSocklinger_t linger;
        linger.l_onoff = 1;
        linger.l_linger = 5;

        status = sl_SetSockOpt(sid, SL_SOL_SOCKET, SL_SO_LINGER, &linger, sizeof(linger));

and write usleep(5000) before sl_stop(5000)

and it help

0 Hnz over 5 years ago in reply to Shamil Farsiev

Guru 39650 points

Hi,

Great! Thank you for a sharing your solution.

Jan

Wi-Fi

Wi-Fi forum

CC3220: Problem with sl_Close - no ACK from device