ESP8266 Community Forum

- Tue Jan 27, 2015 4:04 am #8302

lwip is not open source in sdk_v0.9.5

Are there any plans on changing that? It would be very beneficial for us to be able to rebuild lwip with some different options enabled/disabled and it would allow us to fix the bugs, and there are some. For example, I was recently playing with creating tcp server and it's very easy to reboot the module remotely when you do - each TCP connection consumes 192 bytes of heap for 60 seconds after it's closed, staying in TIME-WAIT state. So all you have to do it to open enough such connections in one minute and you're out of heap. Now LWIP can recycle connections in this state but it will only do that if memp_malloc returns NULL. But that's not working on esp8266 even now when malloc can actually can return NULL. I know at least three workaround for that but that's only because I was able to work on the lwip source. So when it's closed, we won't have that possibility anymore :/

- Tue Jan 27, 2015 4:56 am #8305

This error is not removable - it is algorithmic errors, bad Espressif programmers.
+ http://lwip.wikia.com/wiki/License
PS: All mistakes, particularly global, open Espressif I will not until the full source code for all.

You know that the license is BSD, and thus they are perfectly allowed to keep their changes closed. It might not be the smartest move but if their management considers these changes are Espressif IP the programmer is not to blame. I also think you shouldn't say the programmers are bad and should be fired. Opening up the source and allowing the community to improve this fantastic chip would be a good idea though.

- Tue Jan 27, 2015 5:42 am #8307

lwip is not open source in sdk_v0.9.5

Are there any plans on changing that? It would be very beneficial for us to be able to rebuild lwip with some different options enabled/disabled and it would allow us to fix the bugs, and there are some. For example, I was recently playing with creating tcp server and it's very easy to reboot the module remotely when you do - each TCP connection consumes 192 bytes of heap for 60 seconds after it's closed, staying in TIME-WAIT state. So all you have to do it to open enough such connections in one minute and you're out of heap. Now LWIP can recycle connections in this state but it will only do that if memp_malloc returns NULL. But that's not working on esp8266 even now when malloc can actually can return NULL. I know at least three workaround for that but that's only because I was able to work on the lwip source. So when it's closed, we won't have that possibility anymore :/

espconn.h:
* Description : access port value for client so that we don't end up bouncing
* all connections at the same time .
sint8 espconn_set_opt(struct espconn *espconn, uint8 opt);
+ See LwIP:
/**
* Kills the oldest connection that is in TIME_WAIT state.
* Called from tcp_alloc() if no more connections are available.
*/
static void ICACHE_FLASH_ATTR tcp_kill_timewait(void);

In espconn large memory consumption... Only 4 connections...

Rebuild liblwip.a:
"xtensa-lx106-elf-ar -x liblwip.a"
Compile the source code LwIP (SDK 0.9.4) and assemble again.

PS: Perhaps after some time, will complete source on the chip (ESP8266) without codes and libraries Espressif...

- Tue Jan 27, 2015 6:46 am #8314 Yes, calling tcp_kill_timewait in tcp_alloc() is one of the options. I actually can this conditionally, if free heap drops to a certain value. Another option is to use LWIP internal memp_malloc but this preallocates ~20kb of memory at init with default settings, yet another thing we can do (but this will only partially help) is to reduce TCP_MSL.

I don't know why you mentioned espconn_set_opt, though. ESPCONN_REUSEADDR does not seem to fix this issue for me. Can you explain?

My point is, however, that in order to do any of this, we have to recompile LWIP and for that we need sources. We do have sources from 0.9.4 and we can maintain it ourselfes but this does not look like a good idea. If Espressif is fixing bugs and adding new features it its lwip implementation,then it would be best to have common code base that they could maintain, instead of relaying on some old code.