BGS5T ServerSocketConnection Bug - Connection won't close when sending less than 24 Bytes | Thales IoT Developer Community
June 1, 2015 - 1:11pm, 2805 views
I'm showing a typical socket server code. Basically (with some things removed for better readability) I'm doing this in Java:
listener = (ServerSocketConnection) Connector.open("socket://:" + port);
System.out.println("Local Address: " + listener.getLocalAddress());
while (true) {
sc = (SocketConnection) listener.acceptAndOpen();
in = new InputStreamReader(sc.openInputStream());
// ... processing Input, preparing Output...
out = new PrintStream(sc.openOutputStream());
out.print(response);
out.close(); in.close(); sc.close();
}
Now the buggy part is, if string response is less than 24 bytes long, the connection won't close, even though out.close(), in.close() and sc.close() are called; they don't throw an exception. **
I tested with netcat, where I can clearly see that the BGS5T closes the connection, when more or eqal than 24 bytes are sent, and that the connection hangs, when less than 24 bytes are sent. When it hangs, I can exit netcat only with CTRL+C.
I've tried all combinations of arrangement of out.close(), in.close(), sc.close(), with no luck. I've tried also .flush(), and also closing the underlying sockets (the ones opened with sc.openInputStream() and sc.openOutputStream()), with no luck. When less than 24 bytes are sent, the connections remains open.
I consider this behaviour as a bug. Is this behaviour also present in the EHSx models?
Kind regards,
Helmut
------------------------
** To add even more confusion, when testing with Local Debug Connection, this bug doesn't show up. It only shows with GPRS connection.
Hello,
Interesting situation.
How have you run into this problem? Is there any other impact of this situation?
To be sure that I have understood everything correctly.
The server on the module receives some data and sends the reply.
After sending the reply the connection is being closed on the module side and no exception is thrown, the application seems to have closed the connection.
Is that reply received by the netcat program each time (even if shorter than 24 bytes)?
Is it possible to connect to the application then and establish the new connection?
When the connection seems to be closed on the module's side the netcat program still considers this connection as open.
Between the module and PC application we have a backbone networks of different kinds.
The question is how we can be sure that the connection is really not closed on the module (or is closed but the notification is not sent to the other party).
Have you tried to verify this with other device to check if there is no problem in netcat or network?
So far I can't find any records about such a behaviour fro EHSx.
Can you provide the ATI1 response?
Best regards,
Bartłomiej
Hi Bartłomiej, here my answers:
How have you run into this problem? Is there any other impact of this situation?
I’ve implemented a rudimentary REST service for getting / setting application configuration data. The impact is that: for very short responses, the REST client cant use the service.
To be sure that I have understood everything correctly.
The server on the module receives some data and sends the reply.
Correct. It’s a minimal HTTP server.
Client sends, for example,
GET /conf/stationID HTTP/1.1\r\n
Host: aaa.bbb.ccc.ddd\r\n\r\n
Server replies
HTTP/1.1 200 OK\r\n\r\n
1234
Reply is 23 Bytes long, this is how I became aware of the problem.
After sending the reply the connection is being closed on the module side and no exception is thrown, the application seems to have closed the connection.
Right.
Is that reply received by the netcat program each time (even if shorter than 24 bytes)?
Yes, the reply is received each time, but for replies shorter than 24 bytes, netcat waits forever, since the server doesn’t close the connection. Instead of netcat, I also tested with a web browser. With response shorter than 24 bytes, the browser waits forever to load the page. But the browser doesn’t show the response until the connection is closed on server side.
Is it possible to connect to the application then and establish the new connection?
Yes, that’s possible. But I fear after too many open connections, BGS5T would refuse further connections.
When the connection seems to be closed on the module's side the netcat program still considers this connection as open.
Right.
Between the module and PC application we have a backbone networks of different kinds.
I’m using provider “A1” from Austria.
The question is how we can be sure that the connection is really not closed on the module (or is closed but the notification is not sent to the other party).
I could provide test code and a test procedure.
Have you tried to verify this with other device to check if there is no problem in netcat or network?
No, currently I just have one BGS5T and one A1 SIM for development purposes.
So far I can't find any records about such a behaviour fro EHSx.
Can you provide the ATI1 response?
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.02
OK
Best regards,
Helmut
Hello,
Thank you for the detailed responses.
It seems that your firmware version is not the latest. So it would be good to start from updating the firmware.
You can get the latest firmware from the local Gemalto support or I can send it to you by email.
If the newer firmware will not help you can provide the test code and test procedure to me. If I will be able to reproduce this I could submit this as defect and it will be further processed.
It would be good if you were able to check this scenario with some other device connected via the same network provider.
Best regards,
Bartłomiej
Hello!
Please send me latest firmware via email, and also instructions how to update firmware
Best regards,
Helmut
Hello,
I've sent you an email.
Best regards,
Bartłomiej