# WIP 5.3 - periodic http GET **URL:** \ **Category:** Open AT\ **Created:** [August 11, 2010, 3:16pm UTC](https://forum.sierrawireless.com/t/wip-5-3-periodic-http-get/4610 "2010-08-11T15:16:09Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Jeroen1](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jeroen1](https://forum.sierrawireless.com/u/Jeroen1)\ **Post date:** [August 11, 2010, 3:16pm UTC](https://forum.sierrawireless.com/t/wip-5-3-periodic-http-get/4610/1 "2010-08-11T15:16:09Z")
I have been looking at HTTP GETs with WIP 5.1 at the end of 2008. Finally resulting in forcing both channels to always close and rebuild from scratch again for the next request, even though the manual states the HTTP session could be reused, see also [forum.sierrawireless.com/viewtop … 109&t=4567](https://forum.sierrawireless.com/t/multiple-http-requests-every-other-one-fails/4184/1) Awneil, did this issue ever get a tracking number / any feedback? This worked most of the time, and always on a desk/debug environment, but on some networks, it seemed as if WIP (error) events are simply not received. This occured only after several hours / days of normal operations. Never able to reproduce this intentionally, nor find a suitable way to recover from such a situation. Similiar problems are reported here [forum.sierrawireless.com/viewtop … 535#p18533](https://forum.sierrawireless.com/t/socket-issues/4001/14). Since there are now several new WIP version, I had a look at WIP 5.30 to check if things got a bit better by now. The tested modem has an ethernet IESM card, so I can see what it is actually doing. Versions are: Fastrack Supreme Firmware: R7.43.0 Application: 6.32 Wip: 5.30 Interestingly enough the WIP HTTP client still seems to behave at least to say strange or I am completely missing something. The intention is quit simple, request a url (GET) on a regular interval in the minutes range. Below are (some) things I tried, As per http\_get example: When opening a session the initial GET by HTTP/1.1 always goes fine, wip\_close() is called on WIP\_CEV\_PEER\_CLOSE for the data channel. In the meantime the remote server closes the connection since there is no activity (The KeepAliveTimeout of Apache is 15 seconds by default.); it sends a packet with FIN set. The modem ACKs the reception of the FIN. The next request is scheduled say a minute later to the same url using the same HTTP session. WIP will then reuse the by now closed socket!! Resulting in a tcp packet with RST flag set from the remote side. The data channel receives therefore an error: WIPEV WIP\_CEV\_ERROR @ TCPCLIENT 0x180c8cac (errno = WIP\_CERR\_ABORTED/-1000) The next request succeeds again. So every other request results in an error if the remote side closes the connection in the meantime… There seems to be a bug in WIP 5.3 not handling the socket closure correctly. There should either be a peer close event on the session channel or subsequent requests should first check if the socket is still open, and if closed, open a new tcp socket instead. So since the keep-alive does not work, I tried the reverse. Not keeping the TCP socket open but closing it directly; Added the header Connection: close and closing both channels in WIP\_CEV\_PEER\_CLOSE on the data channel. This at least works without error events. Looking at the actual data sent, the connection is directly closed by the server (FIN) as requested. The modem send an ACK as response, so actually confirmes that it saw the frames. So this is completely fine so far. However wip\_close insists on sending a RST to the already (confirmed) closed socket…!! No matter what I tried, wip\_shutdown, defering wip\_close of the session till the finalizer of the data channel is called etc, the wip\_close always seems to want to send a RST as if the socket is still open. (the tcp data seems fine by not calling wip\_close, but then the modem runs out of sockets ). In short, it seems as if remote socket closing is not handled correctly, at least not for the HTTP client. Explicitly closing the connection seems to be the best thing to do, despite an additional RST being send. (which should not be there afaik, but is fine as long as WIP did not reuse the same port again). Don’t know about the behaviour of 5.3 in the long run, but this seems not all too promising. Can anybody confirm above? Does anybody have experience with a reliable way to periodic log by HTTP, also for long periods of time with WIP 5. If so, which version of WIP is then used? ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [August 12, 2010, 5:35am UTC](https://forum.sierrawireless.com/t/wip-5-3-periodic-http-get/4610/2 "2010-08-12T05:35:45Z")
> [@Jeroen](#): > > Awneil, did this issue ever get a tracking number / any feedback? 'fraid not. 😢