BG96 does not send FIN ACK upon closing TCP connection

From what I can tell, the BG96 does not send a FIN ACK upon calling AT+QICLOSE, when it is acting as a TCP client. This is causing my server to not properly terminate the connection with the BG96 client. Is there some configuration that I missed?

The server properly receives the data from the BG96 client, so I know the connection is established correctly.

Using activated PDP context 1, I set up the BG96 in direct push mode with the following:

AT+QIOPEN=1,0,“TCP”,"[server ip address]",8000,0,1

I then send some data with:

AT+QISEND=0
[type some data]ctrl+z

And then close the connection with:
AT+QICLOSE=0

All the data is received by the server. I expect the BG96 to properly close the TCP connection with a FIN ACK after calling qiclose, but it doesn’t appear to be doing so. I am using wireshark to observe every packet that is coming in to my server. Any recommendations?

pls collect the Qwinlog to us , we will help you analysis it

to download Qwinlog tools ,pls kindly open the below link;

https://cnquectel-my.sharepoint.com/:f:/g/personal/america-fae_quectel_com/EkQcdJ_eJqFBkrXkHqqbvMoB3YR8JJJyjF3pxhu6RotFxg?e=PPffdy

I am not using Windows, so I cannot use that program.

Can you answer my question? Is the BG96 supposed to send a FIN ACK after calling AT+QICLOSE?

Here are the commands that I issued on the terminal:

atz
OK
at+qistate
OK
at+qiopen=1,0,"TCP","24.10.145.0",9000,0,0
OK

+QIOPEN: 0,0
at+qistate
+QISTATE: 0,"TCP","24.10.145.0",9000,16519,2,1,0,0,"uart1"

OK
at+qisend=0
> hello
SEND OK
at+qistate
+QISTATE: 0,"TCP","24.10.145.0",9000,16519,2,1,0,0,"uart1"

OK
at+qiclose=0
OK
at+qistate
OK

Attached is the wireshark capture resulting from those commands. You can see the SYN (#259), the SYN ACK (#260), and the data packet sending the text “hello” (#402), which is acknowledged by the server (#405).

Afterwards I call AT+QICLOSE, and the BG96 sends no TCP closing packets, although a call to AT+QISTATE shows that the connection is closed. There are no packets after #405.