NetDemo sample application throws execption | Telit Cinterion IoT Developer Community
January 8, 2015 - 11:29am, 5508 views
When I launch the NetDemo sample from eclipse I receive an exception when the socket is closed on the server side. I would expect that is.read() returns -1. The module is a BGS5T.
Using USB port COM7.
Connecting to module...
Initializing module for debugging...
Establishing "IP connection for remote debugging of BGSx"...
Registering ip address "192.168.244.1" of remote debugging device...
Waiting for debug device registration of "IMP_NG_BGS5_REMOTE"...
Passing control to external device emulator...
Installing suite from: http://192.168.244.2:50571/NetDemo.jad
NetDemo: Constructor
NetDemo: startApp
NetDemo: Connector open: socket://v.x.y.z:80;bearer_type=GPRS;access_point=internet;username=anyone;password=something
NetDemo: sending: GET /somefile.txt HTTP/1.0
NetDemo: Unknown error -123 during socket::read
NetDemo: destroyApp(true)
MIDlet:NetDemo.NetDemo exited
End of debug session. Emulator is closed!
Stacktrace:
java.io.IOException: Unknown error -123 during socket::read
- com.sun.midp.io.j2me.socket.Protocol.read0(), bci=0
- com.sun.midp.io.j2me.socket.Protocol.nonBufferedRead(), bci=10
- com.sun.midp.io.BufferedConnectionAdapter.readBytes(), bci=30
- com.sun.midp.io.BaseInputStream.read(), bci=197
- com.sun.midp.io.BufferedInputStream.fill(), bci=120
- com.sun.midp.io.BufferedInputStream.read(), bci=12
- NetDemo.NetDemo.startApp(NetDemo.java:107)
- javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
- com.sun.midp.midlet.MIDletPeer.startApp(), bci=5
- com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=261
- com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
- com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
- com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=134
- com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
This is reproducible on another BGS5T unit and without the debugger.
Hello,
I've checked this on my desk.
It seems that the application is able to get the proper response from server if the file is on server and the address and APN data is correct.
The server replies and closes the connection. But the read() method does not get the -1 as end of the stream - the exception is thrown instead and this is the reason why the application does not print the response.
The simplest workaround would be to change the application in a way to get the server response from StringBuffer after catching this exception.
The other way could be to use DataInputStream instead of InputStream and use available() method to check if there are data to be read:
while (is.available() > 0) { ch = is.read(); str.append((char)ch); }But some sleep would be needed before the loop to wait for data.
Best regards,
Bartłomiej
Thanks for your confirmation and workarround.
The communication and apn is ok. I have had a succesfull connection using apache2, netcat and tcplisten except for the exception of course. Monday I will ask my colleague to verify this on a tc65t
When I ran the sample app without the server application started I got an unknown error -123 exception at sc.Open()
What suprises me the most is that googling this unknown error '-123' does not give any java me related results.
regards
Hello,
I am having a simular issue for writting data to the server socket.
java.io.IOException: IOError -134 during socket:: write \n
- com.sun.midp.io.j2me.socket.Protocol.write0(), bci=0
- com.sun.midp.io.j2me.socket.Protocol.writeBytes(), bci=10
- com.sun.midp.io.BaseOutputStream.write(), bci=43
- java.io.DataOutputStream.write(), bci=4
- java.io.OutputStream.write(), bci=5
My send packet method looks like that:
public void sendPacket(byte[] p) {
try {
out.write(p);
out.flush();
} catch (Exception e) {
disconnect();
e.printStackTrace();
}
It works to send some packets but it randomly fails for others.
Please, Could you advice?
ps: I am using the EHS6 module.
Thanks!
Hello,
Could you paste the ATI1 and AT^SCFG? outputs?
Could you write some more information? How often does it happen? Have you tested with more than one server? What it the application doing?
This exception does not explain much besides that there was some I/O error during sending the data. So one of the reasons could always be some network error. And the important question here is: what is the signal quality - AT+CSQ, AT^SMONI.
Regards,
Bartłomiej
The application is a client that exchange messages with a server socket via proprietary protocol.
This behavior is very strange because it fails randomly to send some packets, but the application is able to send the same packet after reinstantiate and reconnect the socket. I have tested it on different servers and got the same issue. Also, I have different equipments (not EHS6) that works on the same way without any issue.
Thanks and Regards,
ati1
Cinterion
EHS6
REVISION 03.001
A-REVISION 00.000.14
OK
at^scfg?
^SCFG: "Audio/Loop","0"
^SCFG: "Call/ECC","0"
^SCFG: "Call/Ecall/AckTimeout","5000"
^SCFG: "Call/Ecall/Callback","0"
^SCFG: "Call/Ecall/CallbackTimeout","43200000"
^SCFG: "Call/Ecall/Msd","0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
^SCFG: "Call/Ecall/Pullmode","0"
^SCFG: "Call/Ecall/SessionTimeout","20000"
^SCFG: "Call/Ecall/StartTimeout","5000"
^SCFG: "Call/Speech/Codec","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/mode/ASC1","std"
^SCFG: "Gpio/mode/DAI","gpio"
^SCFG: "Gpio/mode/DCD0","gpio"
^SCFG: "Gpio/mode/DSR0","gpio"
^SCFG: "Gpio/mode/DTR0","gpio"
^SCFG: "Gpio/mode/FSR","gpio"
^SCFG: "Gpio/mode/HSIC","rsv"
^SCFG: "Gpio/mode/PULSE","gpio"
^SCFG: "Gpio/mode/PWM","gpio"
^SCFG: "Gpio/mode/RING0","gpio"
^SCFG: "Gpio/mode/SPI","rsv"
^SCFG: "Gpio/mode/SYNC","gpio"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","EHS6"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEShutdown/sVsup/threshold","0","0"
^SCFG: "MEopMode/CFUN","0","1"
^SCFG: "MEopMode/Dormancy","0","0"
^SCFG: "MEopMode/SoR","off"
^SCFG: "Radio/Band","511"
^SCFG: "Radio/Mtpl","0"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless Modules","EHx",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/OTAP","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","0"
^SCFG: "Userware/DebugInterface","0.0.0.0","0.0.0.0","0"
^SCFG: "Userware/DebugMode","off"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","usb4",,,,"off"
^SCFG: "Userware/Watchdog","2"
OK
at^smoni
^SMONI: 3G,10763,377,-6.5,-101,724,31,3F26,3496AC8,5,14,NOCONN
OK
at+csq
+CSQ: 20,99
OK
Hello,
The firmware is currently the latest official release. The network conditions are not bad, at least at the moment when measured.
Still I think that there must be some network error that could be caused either by the wireless network quality problem or some other problem in WAN or maybe some behavior of one of the party which is not accepted by the other. If we had a TCP trace we would be at least able to see what packets are transmitted and which party breaks the connection. You could also use the com.cinterion.misc.NetExtension class and try to use LastNetError() method to see what it returns or try to manipulate some of the TCP parameters.
The device that you compare with EHS6 has some different implementation of TCP stack and maybe also the configuration of retransmissions and timeouts so it is also possible that it can survive some situations which cause the above exception in EHS6. Or it usus some different network access technology.
Regards,
Bartłomiej
Hi Bartłomiej,
Thanks for your help. I have found that the issue was hardware related. It was wrongly pulsing SIM DET signal that was restarting the simcard and losing the socket connection. Now it is working properly.
Thanks,
Thanks for the information.
Regards,
Bartłomiej