Multiple HTTP Requests - every other one fails

Legacy Open AT
1

OS: 6.21;
WIP: 5.10;
Firmware: R73a;

But it doesn’t seem to work!

After making a GET or PUT request, I receive the CEV_PEER_CLOSE event, and call wip_close to, “close the channel and make the session ready for another request” - as the guide says (see above).
But the next request (GET or PUT) will always fail with CERR_ABORTED, “channel closed by server”

After this failure, the next request (GET or PUT) will always work!

It looks like the wip_close is not correctly making the channel ready for another request!

These are the traces at the end of a successful request, on the CEV_PEER_CLOSE event:

wip_close=0
[WIP] closing HTTP_DATA 0x180c43e4
[HTTP] destroy request @ 180c43e4
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c4684
[req_event] WIP_CEV_PEER_CLOSE

In this case, note that only HTTP_DATA is closed.

And these are the traces at the end of a failed request, on the CEV_ERROR (CERR_ABORTED) event:

wip_close=0
[WIP] closing TCPCLIENT 0x180c4684
[WIP] closing HTTP_DATA 0x180c4964
[HTTP] destroy request @ 180c4964

In this case, note that both HTTP_DATA and TCPCLIENT are closed - and, after this, the next request will work.

The code is the Wavecom WIP HTTP GET sample from the SDK;
The [WIP] and [WIPEV] and [HTTP] and [req_event] are internal traces from WIP itself.

So, what’s going wrong here? Why is wip_close not doing its job?

2

Do you need to give it time to “recover” after closing?

3

Even after 2.5 minutes it still fails!

4

I have just rebuilt exactly the same code with:
Firmware 663 + Open-AT 4.20 + WIP 3.01

This works every time!
(which explains why I was sure that I’d done this before and not had this problem).

So, it looks like something in WIP has been broken between v3.01 and v5.10… :unamused:

5

have you also tried with 5.20 ? (included with 7.4a)

6

No, I haven’t (yet).

The problem seems to be to do with the TCPCLIENT - which appears in the traces, but is not visible to the application (it is neither the application’s Data channel, nor the application’s Session channel)

The TCPCLIENT is entirely invisible to the application & hidden within WIP

The HTTP_DATA in the traces is the application’s Data channel, and it can be seen that events on this are notified to the application’s Data channel event handler:

[WIPEV] WIP_CEV_PEER_CLOSE @ HTTP_DATA 0x180c44c4
Data Ch=180C44C4 Ev=3
http_ClientTestDataHandler: WIP_CEV_PEER_CLOSE

But the TCPCLIENT events are not notified to the application at all - particularly its PEER-CLOSE event:

[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c4744
[req_event] WIP_CEV_PEER_CLOSE

And it is this which causes the CERR_ABORTED error when the application tried to make its next request.

WIP 3.01 handled this internally, and would automatically create a new TCPCLIENT if it needed to;

WIP 5.10 doesn’t do this automatically, and provides no way for the application to know that it needs to be done - it just fails the request! :angry:

7

As a side note, these kind of traces are generated “internally” by WIP:

[WIP] closing HTTP_DATA 0x180c43e4
[HTTP] destroy request @ 180c43e4
[WIPEV] WIP_CEV_PEER_CLOSE @ TCPCLIENT 0x180c4684
[req_event] WIP_CEV_PEER_CLOSE

To enable them, you need to set the Log Events Flag:

wip_logEvents = TRUE; /* Enable all WIP Event traces */

You specify whether you want them to appear in the Trace, or on UART1 or on UART2 by using the appropriate option in wip_netInitOpts:

r = wip_netInitOpts
( 
      //WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1, /* WIP traces on UART1 */
      //WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART2,
        WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_TRACE, /* WIP traces in TRACE  */

      WIP_NET_OPT_END /* Marks the end of the options */
);
8

Even if it did know that it needed to be done, WIP provides nothing that would allow the application to correct the situation, other than closing the Session Channel - which the documentation specifically states should not be required!

I call this a bug: WIP v5.10 Bug: Multiple HTTP Requests