Moderator: igrr
@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
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:
16: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
16: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.