[lwip-users] API code issues

[Derek Guerdon]

Hi everyone,

I've come across a couple of things in the API code that do not seem
to be correct.

Functions in api_lib.c call api_msg_post(), which just calls
tcpip_apimsg() which posts the message to the TCP/IP thread's mailbox.
After the return from the calls to api_msg_post(), the api_lib.c calls
always pend on their own mailboxes in order to block until the
completion of message processing.

The first problem occurs when memp_malloc() fails in tcpip_apimsg():

  msg = memp_malloc(MEMP_TCPIP_MSG);
  if (msg == NULL) {
    memp_free(MEMP_API_MSG, apimsg);
    return;
  }

When memp_malloc() returns NULL, the calling thread locks because no
message is ever posted to the TCP/IP thread's mailbox which causes the
caller to wait forever for a message in its own mailbox.

If tcpip_apimsg() and api_msg_post() returned an error, the api_lib.c
functions could handle it appropriately. This would also remove the
need for tcpip_apimsg() to free the apimsg object, which I assume is
done to free up resources since it is knows that the caller will lock.


The second problem is with err_tcp(), which posts a message to the
mailbox of the connection with the error. Since the mailboxes are only
used for the API messaging noted above, no one is waiting for that
post. The problem occurs on the next api_lib.c call which uses the
mailbox. Since it pends on the mailbox for the end of message
processing, and there is already a message in the mailbox, the
function takes the message posted by err_tcp() as an indication that
its own message has been processed. This results in a premature
freeing of the API message.


I'm not the best writer, so I hope I communicated what I'm seeing. I
also may not fully understand what lwIP is doing in these instances.
If so, please let me know what I'm not understanding.
-- 
Derek Guerdon