lwIP TCP socket buffer read bug?

Hello everyone,
I think there is a small bug in RIOT/pkg/lwip/contrib/sock/tcp/lwip_sock_tcp.c

346 /* post-process buf */
347 if (buf_len > copylen) {
348     /* there is still data in the buffer */
349     sock->last_buf = buf;
350     sock->last_offset = copylen;
351 }

In line 350, I guess it should be sock->last_offset += copylen;\

The problem occurs when I read a message from the socket buffer by multiple (more than two) calls to sock_tcp_read(...).

There is a buffer of 10 Bytes available and in the first call I read 8 Bytes.
We’ll have sock->last_buf set and sock->last_offset is 8.\

In the next step we read 1 Byte (copylen = 1). The remaining buffer length is computed by

337 buf_len = buf->tot_len - sock->last_offset;

and obviously is 2.
There is still data in the buffer left to read, so again we’ll have sock->last_buf set and sock->last_offset now is 1, since copylen = 1.

If we want to read the last remaining Byte, we’ll compute the remaining buffer length to

buf_len = buf->tot_len - sock->last_offset
                10     -         1          = 9

which should not be the case.

The problem occurs when I want to read new data from the socket buffer. Then I get the pointer of the old buffer with a wrong sock->last_offset value and with the previous example I would start reading at offset 1.

sock->last_offset += copylen; should solve the issue, since it properly increments the last offset and the remaining buffer length will be computed correctly.


Hi @ChrisR,

I will have a look later, but please report this big to our issue tracker over at Github (even if it might not be one). This way there is less risk that this gets lost.

Best regards, Martine