[lwip-users] Lock-up issue with tcp_receive() and tcp

Hi,

I am having some problems with my application getting locked-up in a couple of the tcp routines.

The first is in the tcp_receive() function in module tcp_in.

In this module the firmware gets stuck in the following while loop:

/* Remove segment from the unacknowledged list if the incoming

ACK acknowlegdes them. */

while (pcb->unacked != NULL &&

TCP_SEQ_LEQ(ntohl(pcb->unacked->tcphdr->seqno) +

TCP_TCPLEN(pcb->unacked), ackno)) {

LWIP_DEBUGF(TCP_INPUT_DEBUG, ("tcp_receive: removing %"U32_F":%"U32_F" from pcb->unacked\n",

ntohl(pcb->unacked->tcphdr->seqno),

ntohl(pcb->unacked->tcphdr->seqno) +

TCP_TCPLEN(pcb->unacked)));

next = pcb->unacked;

pcb->unacked = pcb->unacked->next;

LWIP_DEBUGF(TCP_QLEN_DEBUG, ("tcp_receive: queuelen %"U16_F" ... ", (u16_t)pcb->snd_queuelen));

LWIP_ASSERT("pcb->snd_queuelen >= pbuf_clen(next->p)", (pcb->snd_queuelen >= pbuf_clen(next->p)));

pcb->snd_queuelen -= pbuf_clen(next->p);

tcp_seg_free(next);

LWIP_DEBUGF(TCP_QLEN_DEBUG, ("%"U16_F" (after freeing unacked)\n", (u16_t)pcb->snd_queuelen));

if (pcb->snd_queuelen != 0) {

LWIP_ASSERT("tcp_receive: valid queue length", pcb->unacked != NULL ||

pcb->unsent != NULL);

}

The second is in the tcp_output() function in module tcp_out.

In this module the firmware gets stuck in the following for loop:

/* useg should point to last segment on unacked queue */

useg = pcb->unacked;

if (useg != NULL) {

for (; useg->next != NULL; useg = useg->next);

}

In normal operation the application works ok but the lock-up occurs under stress testing (i.e. increasing the amount of network traffic).

The application is based upon lwip version 1.3.1.

There is a later version of lwip available (1.3.2) and there are some changes in this area.

I incorporated the changes from the later version for these modules but was still able to create the lock-up, so for the time being I have reverted to 1.3.1.

I should also mention the Nagel algorithm has been disabled in order to speed up the transmission of the product protocol command responses.

Also the application is not using an RTOS.

I can trap the conditions in the offending loops but I am not certain what I should do after trapping the condition.

It would be better to prevent the condition occurring in the first place.

I would appreciate any suggestions or ideas as to what I can do to fix this issue.

Thanks,

Tony

This email contains confidential and/or privileged information belonging to Devlin Electronics Ltd its affiliates and/or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and/or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error; please notify the sender by return Email and delete it from your system. If you require assistance, please contact our sales office on +44 (0)1256 467367 or visit our websites www.devlin.co.uk & www.devlinmedical.co.uk Devlin Electronics Limited is registered in England and Wales with company no 4067603. VAT no GB200 8583 88 Registered Address: Unit D1, Grafton Way, Basingstoke, Hampshire, RG22 6HZ, England.

From:	Carr, Anthony
Subject:	[lwip-users] Lock-up issue with tcp_receive() and tcp_output()
Date:	Tue, 4 Jan 2011 11:18:37 +0000

[lwip-users] Lock-up issue with tcp_receive() and tcp_output()