WiFi fragmented packets are not correctly handled

[niziak]

Expected behavior

On_receive callback function gets payload correctly

Actual behavior

Nothing. On_receive callback not called.

LwIP debug: IP (len 943) is longer than pbuf (len 476), IP packet dropped.

Test code

Configure WiFi access point to use 512 bytes fragmentation threshold.

Test server code:

SSID = "mywifi"; PSK = "mypass"
wifi.setmode (wifi.STATION)
wifi.sta.config(SSID, PSK)
wifi.sta.autoconnect (1)

srv = net.createServer(net.TCP, 10)
srv:listen(80,function(conn)
    conn:on("receive", function(conn, payload)
        print(payload)
        local response = "HTTP/1.1 200 OK\r\n\r\n<h1> Hello, NodeMcu.</h1>"
        conn:send(response, function()
            conn:close()
        end)
    end)
end)

Send HTTP request with long enough URL:

curl -v -X GET http://nodemcu_ip/?12345678901234567890....

NodeMCU version

1.5.4.1-master_20161201
81ec366

Hardware

ESP-12 module on NodeMCU development board (with microUSB socket)

Workaround

Change TCP_MSS to low value (In app/include/lwipopts.h)

[marcelstoer]

@djphoenix one for you? @niziak can we ask you to test against djphoenix:net-udp-lwip from #1379 as well?

[niziak]

Doesn't help. I think problem is located in WiFi driver or something is not correctly configured. Reassembly of fragmented WiFi frames should be done before packet go into IP stack. Probably closed-source WiFi part is not doing it correctly.

[djphoenix]

@marcelstoer thanks for tagging me here.
I note that message about packet drop goes from open-source part:

// app/lwip/core/ipv4/ip.c:336
err_t
ip_input(struct pbuf *p, struct netif *inp)
{
// ...
    if (iphdr_len > p->tot_len) {
      LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_LEVEL_SERIOUS,
        ("IP (len %"U16_F") is longer than pbuf (len %"U16_F"), IP packet dropped.\n",
        iphdr_len, p->tot_len));
    }
// ...
}

And one reference to this is from app/lwip/netif/etharp.c:1377 (open too).
Maybe some debugging in this points may help. But I'm not really sure that this can be fixed from our side.

@niziak with current dev (that updated to SDK 2.0.0 and so latest LWIP from Espressif) you see same issue?