ESP8266 Community Forum

- Sun May 10, 2015 1:20 pm #17107 In clientcontext.h I changed line 70 and following (the following if ()... is now useless, but for a test.) to:

err = tcp_close(_pcb);
tcp_abort(_pcb);
if(err != ERR_OK) {

This fixes the "memory leak" and does not seem to harm the Webserver example.

- Sun May 10, 2015 2:05 pm #17111

This fixes the "memory leak" and does not seem to harm the Webserver example.

Except your TCP implementation is now not conformant with the specification, and your client/server connection is now marginally more vulnerable to malicious men in the middle mucking with the protocol state.

Given that you're not running HTTPS, security probably isn't your main concern, so this may not actually matter much, but I thought I'd point out why it is the way it is. (a close-wait of 2 minutes is probably too long for modern networks -- 10 seconds would be plenty for most cases.)

Also, if you're planning on turning your project into a real product, hacks like these are how embedded web servers come to be known as sleeping bombs in everyone's house.

- Thu Jun 04, 2015 5:17 pm #19483

Also, if you're planning on turning your project into a real product, hacks like these are how embedded web servers come to be known as sleeping bombs in everyone's house.

Out of curiosity how can something like that compromise the whole network? It's just an embedded project running in a corner of the house and doing whatnot, you can't even remotely reprogram the thing... A sleeping bomb sounds a bit extreme, can you really access the network by doing weird things with the ESP when the protocol doesn't match the spec?

- Fri Jun 05, 2015 5:04 am #19534 I agree with jwatte, you should stay spec compliant (that is what we do with product of my day job). Only that way you can guarantee interoperability.

From 1981(!) TCP spec:

Knowing When to Keep Quiet

To be sure that a TCP does not create a segment that carries a
sequence number which may be duplicated by an old segment remaining in
the network, the TCP must keep quiet for a maximum segment lifetime
(MSL) before assigning any sequence numbers upon starting up or
recovering from a crash in which memory of sequence numbers in use was
lost. For this specification the MSL is taken to be 2 minutes.

Another point is that this thread title is wrong, a leak will remain while a temporary resource low will go away finally (and it seems that it will go away after 2 minutes MSL).

So the correct fix seems to be to release memory in webserver when entering close-wait state, I have not looked into the sources nor am I an expert on protocol stuff.

Hermann.