BG95-M3 AT+QICLOSE response/timeout issue

IoT Modules LPWA Module
#1

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.

[2021-03-12 14:54:26:353_R:] Quectel
[2021-03-12 14:54:26:353_R:] BG95-M3
[2021-03-12 14:54:26:353_R:] Revision: BG95M3LAR02A03

TIA!

#2

Yes ， the default value is 10 seconds . it is expected

image
image777×167 14.5 KB

#3

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.

1 Like
#4

Hi @swiftlabs, I agree. We are observing the same behavior.
Have you learned anything new about this?

#5

I worked around this by explicitly setting the timeout to 0.
AT+QICLOSE=connectID,timeout

1 Like
#6

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”.