I am observing that closing a TCP connection with AT+QICLOSE=0 that it always takes the default timeout of 10 seconds before receiving OK response. Now if a timeout is specified AT+QICLOSE=0,15 it takes the given timeout time receive the OK response. Is this expected behaviour?
Note that specifying a timeout of 0 AT+QICLOSE,0,0 seems to allow the BG95 to produce a response immediately.
Is it expected that it will always take 10 seconds to get a response? I don’t see that closing a TCP connection ever provides a response < 10 seconds. I’d expect 10 seconds worst case if there was an issue sending/receiving the fin/ack TCP packets.
Hi, bumping an old topic but I’m seeing exactly the same on BG96MA and I’m also wondering if it’s normal behaviour? I’ve set the timeout to 0 using “AT+QICLOSE=0,0”.
Everything is working but what is the purpose of the timeout if it always expires regardless of the value?
Is there any danger in having it set to 0?
I would expect that if the default 10s was kept the “OK” response would usually arrive sooner than the 10s, i.e. then the module receives the “FIN ACK of the other peer”.
—Hello. The same issue! Modem BG95-M3. It looks like modem waits for expire of the timeout anyway ( I tried different values of timeout , and the same situation that had topicstarter (OK after timeout only).
Why modem doesn’t close socket in case of FIN ACK of the other peer is recieved before expire the Timeout ?
It is critical for battery powered products what go into sleep mode after TCP closing… old generation M95 hadn’t timeout in AT+QICLOSE and we didn’t had this issue …
