we have the GE864-QUAD-AUTOMOTIVE-V2 in version 10.0.0.36. To establish IP connections we use the pppd under linux. To be able to simultaneously read GPRS status informations we are using MUX-mode.
Now my questions:In what cases / in which situations does the GE864-V2 change the DCD status? If AT+CGREG says that module has no GPRS connection the DCD status pin does not directly change to status ‘no connection’. For this case we have established a timeout. When stopping the pppd then DCD status changes correctly to status ‘no connection’. Restarting pppd changes DCD statusback to ‘connection established’. What are the external events caused by the mobile service provider that could lead to a change of DCD status pin? We have sometimes had the effect that DCD status pin changed but pppd did not complain about a lost connection.
DCD follows data mode, ie if connection layer is active, regardless the lower GPRS level being inactive, DCD is asserted – and connection will resume when GPRS becomes available again.
We have a situation where TCP connection is lost but DCD remains asserted. Is that something that can happen an needs to be considered?
Right now it seems that Telit does not handle TCP connection timeouts.
Can you detail please? How connection is done, how do you observe is lost etc.
We open TCP SSL connection by the standard sequence (activate context, enable SSL, #SSLD). The connection in theory is “endless” – so we need to detect any exceptional failures. Most of the cases Telit module can detect connection failures and report it by DCD level. Sometimes, it seems, it is unable to detect TCP connection failure – DCD inticates active connection but from the server side everything is dead and timed out long time ago. Looks like if Telit doesn’t check TCP sending timeout.
So my question is, does Telit check if TCP send is succeeded and time out if not response is got?
So your situation is the Telit client sends a packet, you see it at the server which send back the ACK (also positive seen as departed) that never arrives at the client, and the failure remains unnoticed. Correct?
You can check with AT#SI, <ack_waiting> parameter if indeed the data isn’t yet acknowledged – maybe it is, ACK arriving at the module, so other problem should be looked for.
Basically yes, either the data is received by the server or not, there will be no response nor ACK because server has considered that connection closed for long time ago, but Telit still keps trying. AT#SI is an interesting thought, haven’t noticed that before. But does that mean that there is no predefined limit for un-acknowledged data nor a timeout for last ACK receivd? And Telit will keep trying sending data through TCP for a long time before considering the connection being lost?
Along checking <ack_waiting> can you investigate how the server closes the socket?
It’s a bit difficult to test all that because it may take more than a week to reproduce it and needs a lot of preparing.
But let’s ask theoretically – most probably the connection is died out because of temporary network coverage issues (antenna is inside an iron cabinet – sorry:). Server will consider the connection being dead (ater a timeout) and closes it, but most probably FIN segment doesn’t reach Telit. What then? Telit will keep trying to send the data until…? I tested with SMS ATRun that te Telit module is actually responding and is onnected to mobile network. But when I go and check on site, I see that DCD signal is kept high for days.
OK I’ll pass to my colleagues in R&D to investigate.
The situation is a little bit more complex. When one party closes a TCP connection it must indicate it with a FIN control signal, so the other party also know that the connection is closed.
However, the connection may end up in a state called “half-open” (defined in RFC793) and I think that you ended up in this situation.
In mobile networks, one possible cause for a half-open TCP connection is network coverage. The mobile device can be temporary out of coverage and the other party is unable to notify it that the connection is closed.
The second common cause are firewalls. A firewall on the traffic path may have a session timeout value smaller than that of the server (or of the client) and drops this session. Both parties may think that the session is still up, but they are unable to exchange data over this session (unable to notify that the connection is closed).
In any case, the module close the connection eventually. If you send something over a half-open TCP connection, the module will send the data but won’t receive an ACK back. After a tenth retry it will consider the connection as closed.
Thank you, this is what I wanted to know that there is a finite number of TCP retry attempts and Telit will close the connection after that. In that case it’s a bit strange that I have seen situations where DCD pin stays asserted for a very long time.
Should the DCD pin always change it’s state if “half-open” connectiong is closed after atimeout?
When the connection is closed, the DCD changes its state. The module performs a lot of send retrials and it also increments the time it waits between every retrial.
My suggestion is to monitor the “ACK_waiting” counter of AT#SI command and close the connection manually, if this counter doesn’t fall to 0 in a reasonable time.
Hit enter to search or ESC to close
Knowledge Base & Download Zone