ESP8266 Community Forum

- Sun Oct 01, 2017 7:45 am #70503 @tele_player: I'm not sure if you're still following this, but I do appreciate your ideas along the way. I have a better workaround - I discovered client.setNoDelay() which appears to push out each tcp packet following a write. This eliminated the delay and updates are much better. While I don't like hacking a library function, I think this will work for now. Thanks again.

- Sun Oct 29, 2017 10:10 am #71344 I am seeing the same problem since I upgraded from core 2.3.0 to 2.4.0. Web pages don't get loaded by some smartphones while it works OK with others. In fact the problem occurs with 2.4.0 when the size of the page is equal or bigger than 1460 bytes. The change in behaviour in 2.4.0 may not be a bug per say but obviously something has changed in the core code or in the SDK and causes a problem... May be the apps code needs modifications to run with 2.4. 0 but I've not seen anything related to this in the doc.

@weekendguy: you said you worked around this by using client.setNoDelay(). My understanding is that this statement should apply to the web client running on the ESP8266, not to web client in a smartphone. Have you started a when client in your sketch which in return affects the way pages are served by the web server running on the ESP8266 ?
Thanks
Bruno

- Fri Mar 02, 2018 11:43 am #74310 HI,

already posted this, but it somehow got lost? Sorry if it appears twice now...

I know this thread is from last year, but still: I have more or less the same problem, even slightly worse and hope someone can help me here.

I use Sonoff-Tasmota, a firmware that provides a web interface. The web interface works fine, as long as the client is in the same WLAN. It does not work if I use my home LAN to access the device, or port forwarding and accessing from the internet or accessing my home network via VPN.

I tracked the issue down by using the simple ESP WebUpdate example.
It works everywhere (WLAN, LAN, portforwarding Inet or VPN inet.
But when I change the served page to be larger than ~1400 bytes, all but same WLAN stop working.

tcpdump shows this when it hangs:

Code: Select all16:38:28.681580 IP (tos 0x0, ttl 64, id 49138, offset 0, flags [DF], proto TCP (6), length 391)
    192.168.1.4.48474 > 192.168.1.191.80: Flags [P.], cksum 0xf954 (correct), seq 1:352, ack 1, win 9200, length 351: HTTP, length: 351
        GET / HTTP/1.1
        Host: webupdate1.local
        User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
        Accept-Language: de,en-US;q=0.7,en;q=0.3
        Accept-Encoding: gzip, deflate
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        Cache-Control: max-age=0

16:38:28.689947 IP (tos 0x0, ttl 128, id 22, offset 0, flags [none], proto TCP (6), length 144)
    192.168.1.191.80 > 192.168.1.4.48474: Flags [P.], cksum 0x3bc1 (correct), seq 1:105, ack 352, win 5489, length 104: HTTP, length: 104
        HTTP/1.1 200 OK
        Content-Type: text/html
        Connection: close
        Content-Length: 1418
        Connection: close

16:38:28.689988 IP (tos 0x0, ttl 64, id 49139, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.48474 > 192.168.1.191.80: Flags [.], cksum 0x1ead (correct), seq 352, ack 105, win 9200, length 0
16:38:38.700909 IP (tos 0x0, ttl 64, id 49140, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.48474 > 192.168.1.191.80: Flags [.], cksum 0x1eae (correct), seq 351, ack 105, win 9200, length 0
16:38:38.702453 IP (tos 0x0, ttl 128, id 23, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.191.80 > 192.168.1.4.48474: Flags [.], cksum 0x2d2c (correct), seq 105, ack 352, win 5489, length 0
16:38:48.716955 IP (tos 0x0, ttl 64, id 49141, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.48474 > 192.168.1.191.80: Flags [.], cksum 0x1eae (correct), seq 351, ack 105, win 9200, length 0
16:38:48.718340 IP (tos 0x0, ttl 128, id 24, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.191.80 > 192.168.1.4.48474: Flags [.], cksum 0x2d2c (correct), seq 105, ack 352, win 5489, length 0
16:38:58.732921 IP (tos 0x0, ttl 64, id 49142, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.48474 > 192.168.1.191.80: Flags [.], cksum 0x1eae (correct), seq 351, ack 105, win 9200, length 0
16:38:58.734085 IP (tos 0x0, ttl 128, id 26, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.191.80 > 192.168.1.4.48474: Flags [R.], cksum 0x2bc9 (correct), seq 106, ack 351, win 5840, length 0


while it looks like this when it works

Code: Select all16:29:34.136514 IP (tos 0x0, ttl 64, id 2168, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.45136 > 192.168.1.191.80: Flags [.], cksum 0x1a1d (correct), seq 1, ack 1, win 9200, length 0
16:29:34.136590 IP (tos 0x0, ttl 64, id 2169, offset 0, flags [DF], proto TCP (6), length 391)
    192.168.1.4.45136 > 192.168.1.191.80: Flags [P.], cksum 0xf2fd (correct), seq 1:352, ack 1, win 9200, length 351: HTTP, length: 351
        GET / HTTP/1.1
        Host: webupdate1.local
        User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
        Accept-Language: de,en-US;q=0.7,en;q=0.3
        Accept-Encoding: gzip, deflate
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        Cache-Control: max-age=0

16:29:34.145089 IP (tos 0x0, ttl 128, id 15, offset 0, flags [none], proto TCP (6), length 144)
    192.168.1.191.80 > 192.168.1.4.45136: Flags [P.], cksum 0x356a (correct), seq 1:105, ack 352, win 5489, length 104: HTTP, length: 104
        HTTP/1.1 200 OK
        Content-Type: text/html
        Connection: close
        Content-Length: 1319
        Connection: close

16:29:34.145110 IP (tos 0x0, ttl 64, id 2170, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.45136 > 192.168.1.191.80: Flags [.], cksum 0x1856 (correct), seq 352, ack 105, win 9200, length 0
16:29:34.147743 IP (tos 0x0, ttl 128, id 16, offset 0, flags [none], proto TCP (6), length 1359)
    192.168.1.191.80 > 192.168.1.4.45136: Flags [P.], cksum 0xaa37 (correct), seq 105:1424, ack 352, win 5489, length 1319: HTTP
16:29:34.147756 IP (tos 0x0, ttl 64, id 2171, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.45136 > 192.168.1.191.80: Flags [.], cksum 0x0de7 (correct), seq 352, ack 1424, win 10552, length 0
16:29:34.158468 IP (tos 0x0, ttl 64, id 2172, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.4.45136 > 192.168.1.191.80: Flags [F.], cksum 0x0de6 (correct), seq 352, ack 1424, win 10552, length 0


The difference is the length of the packet after the response header: 0 vs. 1359.

I use many other web services in the same lan/wlan without having seen this issue anywhere else.

So I am quite sure it is the implementation of the web server or tcpip layer.
Maybe it is MTU related, but I doubt it, because I lowered the MTU on the client to 500 and the limit is still the same (1400+ bytes).

In case it matters: the ESP8266 framework version I used to build the sketch is 2.4.0-rc.1.