ELS31-V: Non-transparent listener doesn't work properly after upgrading from rev B to D(.3.3.0-36343) | Thales IoT Developer Community
August 7, 2019 - 10:14pm, 6336 views
Listener is open on service 8. With rev B when everything was working as expected:
1.URC ^SIS: 8,1,x from the module on an incoming connection, where X is a dynamically assigned service.
2. Command AT^SISO=x.
3. Module: URC ^SISR: x,1
4. Then AT^SISR=x,y; and so on.
1. Module doesn't always send URC ^SIS: 8,1,x, or the URC comes with several second delay.
3. URC ^SISR: x,1 never come ( 99% of cases). If URC did come, following exchange works as expected.
Please, advice how this problem can be fixed.
HTTP client seems to work fine.
Could you please provide answer to ati1 to check what exactly FW version you use now?
Also, could you please verify if network properly assigns to the module public, static IP? To do it please check AT+CGPADDR / AT^SISO? command.
Played with TeraTerm and Putty.
1. First several attempts to open a TCP connection had a timeout. After that was able to open/close TCP connection several ***** with Putty acting as a TCP client.
2. Had a success with Putty sending data manually. Not when data were sent by an automated client like Chrome or Edge.
3. Trouble seems to happen when the TCP client sends the data BEFORE connection is open by the host. Can’t blame the TCP client for doing that because from the client perspective the connection is indeed open by the modem before host had a chance to confirm or reject it. Modem either have to wait for the host to make a decision; or keep the data and inform the host about data available once connection is confirmed. From my experiments it was evident that modem is keeping the data, but never inform the host about the data. Even when TCP client sends more data after connection is confirmed. I was able to retrieve the whole data accumulated by the modem by blindly requesting them from the modem.
4. Another issue, sometime connection is open, but host doesn’t get URC for several seconds.
There are periods when modem does not respond to pings and incoming TCP connections. In the same time modem reports that internet connection is up (^SICA: 3,1).
Thanks for your feedback.
I'm preparing test setup and will try to check it on my side.
Regarding 3., has the behavior changed comparing to the previous FW?
We didn't have this problem using rev.B. About 50+ rev.B modems are currently in the field that we have to upgrade to meet Verizon requirement.
The issue we are experiencing with rev.B is a lose of Internet when it is idle. We will deal with it later.
I performed test on the same module as you use:
Let me comment your observations:
1./4. For me every connection was successful and I did not notice problem with ping. Please check network condition on your side, maybe that's the reason. I can see one more difference, in CGPADDR command profile 3 you have assigned both IPv4 and IPv6, but I have public address only on IPv4:
Is it possible for you to check if connection will work more stable when using IPv4 only?
2./3. I can confirm, I observed the same behavior on my side - if data is sent before host accepts connection, it stores the data but does not inform about it. I have two workaround ideas:
-You can always after opening the connection check if any data waits for you with command at^sisr=x,0,
-If you have only one client connected, could you consider using transparent listener with autoconnect opton? (at^siss=x,"address","socktcp://listener:port_number;etx;autoconnect=1")
Thanks to it module will automatically opens the connection when client will be discovered.
Could you please let me know what was the behavior on rev B?
Thanks for feedback. Before we will treat it as a module issue, I would like to clarify few more things with you.
I'm a bit confused, why you tried to limit IP to version 4 on rev.B? Shouldn't we focus on rev. D?
Let's sum up how many IP services you use at the same time:
-one HTTP client,
-one non-transparent TCP listener,
-incoming TCP connections to the Listener - what is the *** number of clients?
Thanks to it I will be able to better mimic your scenario.
Could you please also confirm that there is no significant difference in network condition / physical location of module with rev. B and D?
Your test confirmed, there is a clear difference in how rev.D handle the connection when data was received before the AT^SISO. Specifically, the modem doesn’t send URC ^SISW: 0,1 to confirm the opening; and URC ^SISR: 0,1 when data is available. Test was performed with no HTTP clients, and one incoming TCP client.
It would probably better if a connection will not be open until modem is being told to do so. But, this along is not an issue for us, and works in our favor helping speed up the communication. Not getting correspondent URC’s is a real problem.
We are using:
- One HTTP client. Client is always closed at the time of issuing AT^SISO to open a TCP client.
- one non-transparent TCP listener;
- typically one or two incoming TCP connections.
How limit the protocol to IPV4 only? Command AT+CGDCONT=3,"IP","ne01.VZWSTATIC" returns ERROR.
I've just seen that there ia a newer firmware released - els31-v-rev220.127.116.11f-40869 and in the release note I've found an information about improved initial data ready URC ^SISW: x,1,1 on non-transparent socket listener connection acceptance. I think that it's worth trying on your side.
This is great new, I would be happy to try. Where can I download the release? Our supplier doesn't have it yet, and it may take a while before it will be available for us.