LWIP TCPSocket is losing packets when connection is closed right after the last packet

[janjongboom]

Description

• Type: Bug

---

Bug

Target K64F

Toolchain: GCC_ARM

Toolchain version: 4.9.3

meed-os sha: 269f58d75b752a4e67a6a2d8c5c698635ffd6752

Expected behavior

The Hue bridge closes the connection straight after returning a request. This is causing LWIP to drop packets. This issue does not show on ESP8266.

Here's an example program:

#include "mbed.h"
#include "easy-connect.h"
#include <string>

Serial pc(USBTX, USBRX);

int main() {
    pc.baud(115200);
    // Connect to the network (see mbed_app.json for the connectivity method used)
    NetworkInterface *network = easy_connect(true);
    if (!network) {
        printf("Cannot connect to the network, see serial output");
        return 1;
    }

    TCPSocket socket;
    socket.open(network);
    socket.connect("192.168.1.10", 80);

    const char req[] = "POST /api HTTP/1.1\r\nHost: 10.2.202.46\r\nContent-Length: 41\r\n\r\n{ \"devicetype\": \"mbed_hue#elektor_demo\" }";

    socket.send(req, sizeof(req));

    uint8_t* buffer = (uint8_t*)malloc(8 * 1024);
    uint8_t* orig_buffer = buffer;

    size_t recv_ret = 0;

    while ((recv_ret = socket.recv(buffer, 1024)) > 0) {
        buffer += recv_ret;
    }

    printf("total bytes %d\r\n", buffer - orig_buffer);

    std::string blah((const char*)orig_buffer, static_cast<size_t>(buffer - orig_buffer));

    printf("return value is:\r\n%s\r\n", blah.c_str());

    Thread::wait(osWaitForever);
}

If you press the 'link' button on the Hue bridge the program returns this:

total bytes 17
return value is:
HTTP/1.1 200 OK

This is not correct. The bridge actually sends two TCP packets, one 17 bytes and another one 481 bytes. The ESP8266 driver does correctly receive two TCP packets... Somehow we're losing packets. When looking at the Wireshark logs we correctly see two TCP packets go by over the network interface, so it looks like an LWIP bug.

@sg- @matthewelse

[0xc0170]

cc @geky

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-355

[deepikabhavnani]

@janjongboom - Is this issue still valid?

[janjongboom]

@deepikabhavnani No clue, but I think the esp8266 driver was rewritten since, so I hope it's gone.