Bug in WIP v5.32 and v5.41? WIP_COPT_NREAD wrong!

Legacy Open AT
1

Hello, there seems to be a bug in the WIP Soft library on my FXT009 modem - I tried version v5.32 and v5.41. The problem appears when using (transparent) TCP connections with WIP AT commands.

In the attached screenshot from my serial sniffer you can see the problem: at first the modem signals 9 bytes on the socket (+WIPDATA: 2,1,9) but the option WIP_COPT_NREAD (which should show the number of bytes available on the socket for reading) reports 0 bytes available (+WIPOPT: 2,6,0). This is working well on the old Fastrack Supreme Modems with WIP Soft v3.11 but according to my distributor there seems no way of getting v3.11 up and running on the new Fastrack Xtend modem.

I really need a reliable way of checking whether there is data on the socket or not (from AT-mode, changing to data mode is not really an option). Any ideas maybe?

Thanks in advance.

2

Is the +wipdata indication not enough to confirm the reception of data over the socket?

3

That is not the question - I want the bug to be fixed.

4

Hi
Concerning your problem a tracker has been created.Will keep you updated regarding that.

Regards
Moderator

5

What is the status of this issue? The problem is still existant in WIP v5.43.3, two years later!

6

Bump.

7

Hi,

tried with WIP v5.54, its working fine.

Thanks

8

According to M2M studio the latest available firmware package for the AirLink GL6100 is v7.47.6. This package “includes” WIP v5.43.3. As v7.51 (WIP v5.54) and v7.52 (WIP v5.56) are not yet available for this modem I am unsure whether I can only update WIPSoft to the newest version without breaking things.

So is it possible to run WIP v5.56 on firmware version v7.47.6 or do I have to wait until v7.51 or v7.52 are available for the GL6100?

9

Hi,

Yes its possible to run WIP v5.56 on firmware version v7.47.6.

Thanks

10

There is no .dwl file in the WIP v5.56 repository. When trying to flash WIP v5.54 on the GL6100 with firmware v7.47.6 I get the following message in M2M Studio:

Running firmware requires 0x260000 as Open AT application start address, but application to be downloaded was linked at 0x2A0000 (probably because of a Firmware package dependency or Memory Type configuration not matching with the connected module).

So where can I get a suitable WIP package for the GL6100 in which the bug is fixed?

11

Coming back to this issue. How did you try that? It does NOT work on my FXT009, neither with v5.54 nor with v5.56. :imp: Steps to reproduce:

  1. Open a TCP client connection to some host (AT+WIPCREATE).
  2. Once the connection has been established (+WIPREADY), let the host send some bytes of data and wait until they have arrived on the modem (+WIPDATA).
  3. Check the number of bytes available for reading on that socket (AT+WIPOPT) - it is always zero.
AT+WIPCREATE=2,1,"demo.domain.de",10500
OK

+WIPREADY: 2,1

+WIPDATA: 2,1,13
AT+WIPOPT=2,1,1,6
+WIPOPT: 2,6,0

OK

Software versions on my Fastrack Xtend FXT009:

AT+WIPCFG=3
 WIP Soft v556 on Open AT OS v652
Mar 25 2013 07:44:00
OK
ATI9
"DWL","V10c05","","Sierra Wireless",62640,"051513 10:45","a0836b50","00010000"
"FW","FW_752_34_3.Q2687RDG","R7.52.0.201306260837.FXT009","Sierra Wireless",6734
36,"062613 08:37","89796368","001d0000"
"MODEM","1.3.36","201306260837.FXT009","Sierra Wireless",1713240,"062613 08:37",
"85a2fb97","00020000"
"OAT","v1.3.1.20131223105602","Extended AT Application","Sierra Wireless",152674
8,"122313 10:56","fdff3cc2","002a0000"
 -"Developer Studio","2.3.2.201310241753"
 -"Open AT OS Package","6.52.0.201311140649"
 -"Firmware Package","7.52.0.201312200625"
 -"Internet Library Package","5.56.0.201305170830"
 -"Location Library Package","2.0.0.201310171016"
 -"Security Library Package","2.2.0.201306261000"
 -"eCall Library Package","1.2.3.201306191228"
 -"Jamming Library Package","1.1.0.201312230837"
 -"ExtendedATApplication Library Package","1.3.1.201312231055"
"ROM","800000"
"RAM","200000"
"DWLNAME","FXT009"

OK

This is how it should work:

AT+WIPCREATE=2,1,"demo.domain.de",10500
OK

+WIPREADY: 2,1

+WIPDATA: 2,1,13
AT+WIPOPT=2,1,1,6
+WIPOPT: 2,6,13

OK

Software versions on my Fastrack Supreme 20:

AT+WIPCFG=3
WIP Soft v301 on Open AT OS v421
Oct  3 2007 13:46:45 WIPlib:v3a02 WIPSoft:v2a07
OK
ATI3
663X09gg.FSU003 1955876 012308 12:21
12

Hello ralf

I noticed when using the wip library, that the following events that my TCPClient’s eventhandler receives, tell me that I can read 0 bytes and I can write 0 bytes. Always 0, odd I thought. Do you think this is the same problem, or at least related?

case WIP_CEV_READ:
	TRACE((TCP_TRACE_LEVEL, "Client received %d bytes", ev->content.read.readable));
	break;
case WIP_CEV_WRITE:
	TRACE((TCP_TRACE_LEVEL, "Client ready to write, %d bytes can be written", ev->content.write.writable));
	break;

ev is of type wip_event_t, see Internet library documentation. Using WIP 5.56

13

Well, I do not know any of the software internals but I guess your problem could be related to mine. I am really disappointed that nobody feels responsible for this bug.

14

Hi,

The AT+WIPOPT=2,1,1,6, response will be +wipopt: 2,6,X with X!=0 only if some more datas have been received and not reading since last +WIPDATA indication.

For example :

5 datas received while AT is in command mode => +WIPDATA:2,1,5 indication comes…
command AT+WIPOPT=2,1,1,6 sent to module, response will be +WIPOPT: 2,6,0
more 5 datas received, no +WIPDATA indication as previous datas have not been read yet…
command AT+WIPOPT=2,1,1,6 sent to module, response will be +WIPOPT: 2,6,5

Thanks
Rex…

15

Did you even read my message? I am only sending the commands shown there, no switch to data mode or anything else. This does simply NOT work.

16

Hi ralf,

yes i saw your use case…

let me clarify my point here :

Can we do a simple test here :

  1. Take a module… download wipsoft… make it as tcp server (at+wipcreate=3,1,80,4,8)
  2. Take another module… dowanload wipsoft again… make it as a tcp client to the server created in point 1 (at+wipcreate=2,1,“IP”,80).
  3. Now, let the server send some data. For that… in the server side type at+wipdata=2,4,1
    You will enter into data mode and then send only a single byte… lets say “A”.
  4. You will get wip data notification on the receiver’s side. Now, you give at+wipopt=2,1,1,6… you will get +WIPOPT: 2,6,0 which is what i meant to say.
  5. Now, again come to server part and type “B”… again only one byte.
  6. On receiver’s side, you will not get any WIP data event as the last data is not yet read successfully. Issue command AT+WIPOPT=2,1,1,6.
    You should get +WIPOPT: 2,6,1 this time, that one pending data is yet to be read.

Thanks

Can you please try this… i know it’s been a long time this you are struggling to get this working… but once if you can try this

Thanks

17

Oh great, the behaviour of “AT+WIPOPT=2,x,1,6” indeed changed. Thanks for the clarification, though it does not solve my issues.

Imho this is also contrary to the documentation. The description “Number of bytes that can currently be read on that socket” implies that you get the number of bytes you can expect upon the next AT+WIPDATA call (as it really was before). Actually it’s more something like “Number of bytes incoming since the last unsolicited +WIPOPT=2,6,x message”.

There is no way to get the previous behaviour back, right? And no other way to really get the “Number of bytes that can currently be read on that socket”?

18

Hi,

I did not test with WIP Soft v3.11… I believe, as u said, the issue is not seen in those wip versions… May be, i can create a tracker with sierra wireless to update the document accordingly. But, the behavior would have changed. Let’s see, if we can get back to the previous behavior… but i dont think this is possible as the implementation is like this only. Anyways, i’ll keep you updated on this… According to the guide, it is “Number of bytes that can currently be read on that socket”… I’ll get a clarification on this… probably we might need to update the documentation.

Thanks

19

Hi,

Actually, AT+WIPOPT=2,1,16 will read the data present on the socket. So, initially when you send 1 byte of data, then it will come to TCP channels buffer from where it is been read by wipsoft buffers and is displayed in the form of +WIPDATA indicaion. Now, again if you send 1 byte of data, then this time it will again come to TCP channels buffer… this time wipsoft will not read it as the previous data is still not yet read (we are still in AT mode and not in data mode).
So, this time if you give AT+WIPOPT=2,1,1,6 you will get 1 bytes of data as response,

Thanks
rex