# Lost data over TCP/IP (SSL) **URL:** \ **Category:** Open AT\ **Created:** [July 22, 2014, 2:35pm UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328 "2014-07-22T14:35:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mandy](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@mandy](https://forum.sierrawireless.com/u/mandy)\ **Post date:** [July 22, 2014, 2:35pm UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/1 "2014-07-22T14:35:24Z")
We have a socket connection to a server via TCP/IP with use of SSL. Sometime I lose some packets. I write some packets, which are successfully received by the server. And then comes at least one, which gets lost. As return of wip\_write I get the number of actually written bytes. But the data is not received by the server. The next written data returns with the error -999, followed by a WIP\_CEV\_PEER\_CLOSE event. Why returns the wip\_write successfully but the data is not received by the server? Thank for helping 😉 ---
**Author:** ![mandy](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@mandy](https://forum.sierrawireless.com/u/mandy)\ **Post date:** [July 25, 2014, 9:36am UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/2 "2014-07-25T09:36:55Z")
In the tcpdump on the server I see, that data bytes of the lost packet contain more bytes than the successfully transmitted packets. The useless bytes are the last bytes of the previous successfully tranmitted packet. The server software crashes with the error ‘SSL3\_GET\_RECORD:wrong version number’ (python). That seems, that the server software cannot decrypt the SSL data, because there are useless bytes. So the OpenAT firmware sends corrupt data. ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [July 25, 2014, 11:40am UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/3 "2014-07-25T11:40:22Z")
> [@mandy](#): > > the OpenAT firmware sends corrupt data. How do you know that it’s the OAT sending corrupt data - rather than the data getting corruptd at some other point(s) along the linl… ❓ ---
**Author:** ![mandy](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@mandy](https://forum.sierrawireless.com/u/mandy)\ **Post date:** [August 7, 2014, 12:57pm UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/4 "2014-08-07T12:57:04Z")
We used different gprs networks and frequency channels. We repeatedly get currupted data. We checked the transmission without SSL. The tcpdump showed also repeated bytes. Simplified payload received on server Packet1: 0x00 0x11 0x22 0x33 0x00 0x01 Packet2: 0x00 0x11 0x22 0x33 0x00 0x02 Packet3: 0x00 0x11 0x22 0x33 0x00 0x03 Packet4 & 5: 0x00 0x11 0x22 0x33 0x00 0x04 0x00 0x11 0x22 0x33 0x00 0x05 Packet6: 0x00 0x05 0x00 0x11 0x22 0x33 0x00 0x06 Packet7: 0x00 0x11 0x22 0x33 0x00 0x07 The 6th packet starts with the last bytes of the 5th packet. When this happens with SSL the SSL header is corrupt and the data cannot be decoded. Could there be a bug in the TCP stack? ---
**Author:** ![davidc](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@davidc](https://forum.sierrawireless.com/u/davidc)\ **Post date:** [August 9, 2014, 11:40pm UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/5 "2014-08-09T23:40:01Z")
Hiya, It sounds like you are filling/overflowing the TCP buffer in the module. You have to call wip\_write() until the value written is not equal to the number that you requested to write. This indicates that the internal TCP write buffer is full and is waiting to be transmitted. When wip\_write() returns, it doesn’t mean that the data has been transmitted, it just means that it has been transferred from your buffer into the internal TCP TX buffer… You then have to stop writing until you get another WIP\_CEV\_WRITE event which indicates that there is more space available to queue the next data to write. This is explained (but not very clearly) in the WIP doco. I struck this myself when first using WIP, and you have to follow the example to deal with the buffer not being fully transmitted. In my experience, this issue does not become apparent until you are starting to transmit large chunks of data - bigger than the ethernet MTU (roughly around 1500 bytes) packet size. ---
**Author:** ![mandy](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@mandy](https://forum.sierrawireless.com/u/mandy)\ **Post date:** [August 12, 2014, 6:25am UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/6 "2014-08-12T06:25:36Z")
I start writing after an WIP\_CEV\_WRITE event, until it returns a number that is smaller than my requested bytes to write (or an error event occurs). After this I wait for a WIP\_CEV\_WRITE event again before writing more data. In this case I do not transmit large buffers. One data packet consists of 38 bytes (I tested with different sizes for one data packet). I write the data (if channel ready for data) every 500ms (transfer interval of 2s produces also the error). The internal TCP TX buffer seems to collect 2 or 3 of my data packets (3 \* 38 bytes = 114 bytes) before sending and the next tranmitted packet is corrupt. ---
**Author:** ![davidc](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@davidc](https://forum.sierrawireless.com/u/davidc)\ **Post date:** [August 12, 2014, 7:02am UTC](https://forum.sierrawireless.com/t/lost-data-over-tcp-ip-ssl/7328/7 "2014-08-12T07:02:58Z")
Hiya, Hmm, interesting. There are a number of TCP parameters that you can tune using the wip\_setOpts() command. These include buffer sizes and TCP timeouts. Not in front of my dev PC at the moment, so can’t tell you _exactly_ which settings might be of use. ciao, Dave