[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] FTP-DATA exchange: TCP issues

From: tbutler
Subject: RE: [lwip-users] FTP-DATA exchange: TCP issues
Date: Wed, 9 Mar 2005 10:13:25 +0100


I used to utilize both the tcp_poll and tcp_sent callbacks to drive the
continuation of transmission of data, but I ran into reentrancy problems.
In my case, it was due to the fact the during the course of its output
processing, LWIP calls sys_sem_wait(), which in turn executes the
per-thread timer logic (in the same fashion as the call to sys_mbox_fetch()
in the main loop of the TCPIP thread). If sys_sem_wait() happened to detect
a timeout, tcp_tmr() would execute, thereby reentering the TCPIP thread
logic. When this resulted in a call to tcp_poll(), all of my transmit logic
was reentered, which was where I happened to detect the ill effects of the
reentrancy. My solution was to simply stop using tcp_poll to do any

I'm not sure if this is the same problem you're experiencing; the use of a
semaphore during the TCP output processing could be due to the fact that I
have SYS_LIGHTWEIGHT_PROT disabled, which results in the use of a semapore
in the memory pool/Pbuf logic.


"Tom C. Barker" <address@hidden>@nongnu.org con fecha 08/03/2005

Por favor, responda a Mailing list for lwIP users <address@hidden>

Enviado por:      address@hidden

Destinatarios:    "Mailing list for lwIP users" <address@hidden>
Asunto:     RE: [lwip-users] FTP-DATA exchange: TCP issues

The issue is that my polling function was
trying to send data. Has anyone ever implemented
a poll function which sends data? You'd have
to have a semaphore from my current experience,
right? All comments welcome. Here's what I found.

When the polling function sends data it could and
did become reentrant in tcp_enqueue. With some added
debug statements shown below, when the alloc is called
and we have to wait, the tcp_slowtmr: begins another
call to FTP: ftp_retreiveFile_poll... In combination
with an optimized compiler, the pcb->snd_lbb in the regs
gets off by one and the transfer becomes corrupted.

  FTP: ftp_retreiveFile_poll at pcb 0x110b4bf8
  tcp_write(pcb=0x110b4bf8, arg=0x1109bd14, len=2920, copy=1)
  tcp_enqueue(pcb=0x110b4bf8, arg=0x1109bd14, len=2920, flags=0, copy=1)
  TCPOUT_enter: pcb->snd_lbb = 242214
  tcp_enqueue: queuelen: 9
  TCPOUT_allocing: start in thread Lwip/TCPIP-InputSem.
  TCPOUT_allocing: end in thread Lwip/TCPIP-InputSem.
  tcp_enqueue: queueing 242214:243674 (0x0)
**TCPOUT_allocing: start in thread Lwip/TCPIP-InputSem.

  tcp_slowtmr: processing active pcb


  tcp_enqueue: queueing 243674:245134 (0x0)
  TCPOUT_exit: pcb->snd_lbb = 248054

lbb should be 245134 but here it shows as 248054!


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]