EHS6 Socket connection problem in North America | Telit Cinterion IoT Developer Community
June 9, 2017 - 10:27am, 3131 views
My java application on EHS6 open the server socket connection on the port 10000 and wait for the client. I can start the socket client from my PC and connect to EHS6 via IPsec-VPN and private IP address . In Germany it works every time correct (2G and 3G). In USA and Canada (almost only 3G) we have sometimes no socket connection, but the Ping to the EHS6 (private IP address) works good. The mobile provider can't help, he say: "The Ping works good, so is the EHS6 available." Any idea what it can be?
Hello,
The IP address should be public or you connect via VPN to the private network as I understand. So you probably are using the private APN service from the mobile network operator.
If the server on the module is never available while using the certain SIM card and APN it is probably the operator that blocks the incoming traffic - and this depends on the subscription that you have. It may happen the the operator gives you even public IP address but blocks the incoming traffic if you don't buy the special service.
If it happens only sometimes with the same subscription the problem is more complicated. If it's only sometimes and ping is working at the same time it still could be the MNO to blame. But some more investigation would be required and comparison if the two scenarios are really the same, if the same applications are working on the modules, what is needed to recover from that etc.
To be sure if the connection comes to the module it would be the best to trace the TCP traffic on the module but you can't do that. But if you are using the client software on your PC you could also trace there and at least verify if there's any reply coming back from the server on the module.
Regards,
Bartłomiej
Dear Bartlomiej,
thank You very much for quick answer. I traced the TCP traffic on PC side with following result.
For the correct connection the traffic looks like:
5.4 Second -> Sync packet from PC to EHS6
8.4 Second -> Resync packet from PC to EHS6
9.1 Second <- Acknowledge Sync packet from EHS6 to PC
9.1 Second -> Acknowledge packet from PC to EHS6
9.1 Second -> Acknowledge&Push packet from PC to EHS6 (PC is sending some data)
9.5 Second <- Acknowledge&Push packet from EHS6 to PC (EHS6 is sending some data)
.... And so on ...
For the wrong connection the traffic looks like:
5.4 Second -> Sync packet from PC to EHS6
8.4 Second -> Resync packet from PC to EHS6
9.1 Second <- Acknowledge Sync packet from EHS6 to PC
9.1 Second -> Acknowledge packet from PC to EHS6
9.1 Second -> Acknowledge&Push packet from PC to EHS6 (PC is sending some data)
9.5 Second <- Acknowledge&Reset packet from EHS6 to PC (EHS6 is aborting the connection)
Have You any idea?
With best regards,
Alexey.
Hello,
So now we can be sure that the connection comes to the module and is rejected.
But still we don't know why. Are there any differences between the contents of the packages, any timing differences?
Is the same firmware version used in both cases? Please check with ATI1 command.
But I'd start from the application. Is it exactly the same version used in both locations, same configuration, same load etc.? Have you already tried to debug the application? Maybe the connection is reset by the TCP layer because the application can't serve the incoming connection for some reason. What are the main functionalities of the app, especially the network ones? Is all the networking implemented with Java classes or are there AT commands used, what connections are used? Is the server on the module multithreaded?
Regards,
Bartłomiej
Hi, Bartłomiej.
Is the same firmware version used in both cases? Please check with ATI1 command. Firmware is the same: Rev.03.001 A-Rev.00.000.14
Is it exactly the same version used in both locations, same configuration, same load etc.? The Application-version ist the same, confuguration ist the same.
Have you already tried to debug the application? In North America I can't debug the application.
Maybe the connection is reset by the TCP layer because the application can't serve the incoming connection for some reason. Maybe. What is the possible reason for TCP layer to reset the connection? The application must be able everytime to serve the incoming connection, because in waiting-loop no other task is present.
What are the main functionalities of the app, especially the network ones? App is "Redirector TCP to COM-Port"
Is all the networking implemented with Java classes or are there AT commands used, what connections are used? At the initialization I'm using three direct AT-commands to hardware init. It has no influence to TCP-connection. In the main app-loop are all functions with Java classes implemented.
Is the server on the module multithreaded? No. Only one connection is possible.
With best regards
Alexey
Hello,
We know that the connection comes and is reset by the module.
So one of the reasons could be in the application which could not be closing the connections properly and could not be releasing the resources. And the number of sockets is certainly limited. So there might be a situation when there is no more free sockets. To be able to accept the incoming connection the acceptAndOpen() method must be called first which could not happen because of some application fault etc. On the other hand as there's no problem in Germany the application fault does not seem as very probable cause here.
If it's not the application it could be helpful to compare the TCP packets that are exchanged if there are any differences.
You have written that it's only sometimes - does it mean that for example another connection attempt may succeed and usually does; or the restart of the server socket connection or even the application is needed to recover form that?
Regards,
Bartłomiej