[lwip-users] Query amount of free buffers

[Marco Jakobs]

Good evening,

i'm looking for a method to query the amount of free and allocated 
buffers in LwIP.

Background is a problem which i'm facing with my project: I've written a 
telnet access to configure and control the device. But part of this is 
also that i want to access my control on the road, using my IPhone or 
the PC.

I notified the following effect: I start the output of my protocol 
logger, this are around 600+ lines of text being written on the telnet 
connection. Now my phone makes a handover to another cell, and we all 
know that a running data connection will take some couple of seconds to 
also continue the data transfer. What i think what's happening is, that 
the telnet task in my device still continues it's "netconn_write..." 
commands, getting the LwIP buffers to a point, where there is no space 
left for buffering all the data - the output is blocked by the stuck GSM 
connection.

In that case, the complete ethernet traffic (also the local protocols on 
the ethernet) got stuck as all "netconn_write" commands are ending in a 
waiting state for the buffer to bee freed. As i want to have my IP tasks 
in a higher priority (for speed reasons" than the other tasks, Free RTOS 
will not leave the higher priorized IP handling task with the 
"netconn_write" in it -> this results in a complete watchdog reset of 
the whole device.

My idea on this would be to block the TCP output in the telnet task on 
my side, if i will see that the LwIP buffer is i.e. more than 50% used. 
In that case i would wait until the buffer gets in a not-so-critical 
state before continuing the output. My protocol traffic on the ethernet 
will not be affected by this as this is all UDP traffic which won't use 
much buffer space as it won't hold any packets waiting for acknowledge.

To realize this, i need some runtime information on the LwIP memory 
usage like "total buffers / used buffers" or "total memory / used 
memory" - with which my TCP tasks like telnet would not send any data in 
case of low memory. This would prevent system stability and - most 
important - not affect the local UDP protocol traffic on the ethernet. 
Telnet may wait or even drop, but not the whole system.