lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] DHCP server offer timing


From: kuwa
Subject: Re: [lwip-users] DHCP server offer timing
Date: Sat, 13 Mar 2004 11:57:00 +0900 (LMT)

Hi,

Thank you for your reply, Leon.

From: Leon Woestenberg <address@hidden>
Subject: Re: [lwip-users] DHCP server offer timing
Date: Thu, 11 Mar 2004 21:21:27 +0100

> Hello,
> 
> address@hidden wrote:
>  > ...
> >     udp_bind(dhcp->pcb, IP_ADDR_ANY, DHCP_CLIENT_PORT);
> >     udp_connect(dhcp->pcb, IP_ADDR_BROADCAST, DHCP_SERVER_PORT);
> >     LWIP_DEBUGF(DHCP_DEBUG | DBG_TRACE, ("dhcp_discover: send()ing\n"));
> >     udp_send(dhcp->pcb, dhcp->p_out);       /* 1 */
> 
> >     LWIP_DEBUGF(DHCP_DEBUG | DBG_TRACE, ("dhcp_discover: bind()ing\n"));
> >     udp_bind(dhcp->pcb, IP_ADDR_ANY, DHCP_CLIENT_PORT);
> >     LWIP_DEBUGF(DHCP_DEBUG | DBG_TRACE, ("dhcp_discover: connect()ing\n"));
> >     udp_connect(dhcp->pcb, IP_ADDR_ANY, DHCP_SERVER_PORT);  /* 2 */
> > ... 
> > the offer from DHCP server will be received after udp_send() call
> > (marked as /* 1 */) before re- udp_bind() and re-udp_connect().
> > 
> 
> I have re-thought this situation: your system cannot process a packet to 
> the send() while you are still executing this piece the DHCP code.
> 
> I.e. the second bind() and connect() should occur atomically with the
> send(), *before* you start processing incoming packets.
> 
> It sounds like you are either multi-threading the lwIP stack, or your
> packet reception interrupt routine pre-empts the current code
> execution, by processing the packet in the interrupt routine.
> 
> lwIP DOES NOT support this, as it is not multi-threading safe.

Oh, I see.  I am using uC/OS-II and in my system dhcp_start()
(i.e. dhcp_discover()) is not called at TCP/IP task but an application
task.

> I *have* however, just implemented a udp_sendto() call to more cleanly
> support sending UDP datagrams from un-associated UDP PCB's and used
> these in the DHCP client. They are in CVS HEAD.
> 
> They will probably not fix your problem, if my assumption is correct.

I looked your changes and am guessing my system will be able to
receive DHCP server's OFFER because desired UDP PCB
(remote address==IP_ADDR_ANY:DHCP_SERVER_PORT) will become to exist.

However, as you say, I should fundamentally recosider multi-threading
safety of my system.

> 
> Please let me know how the incoming packets are processed.

My system is composed of multiple tasks and is mainly:

 - Application task
   This task initializes lwIP by calling {sys,mem,memp,pbuf}_init()
   and tcpip_init().
   Then this task register DHCP timers (i.e. dhcp_coarse_tmr() and
   dhcp_fine_tmr()) and calls dhcp_start().
   Then goes into application's main loop.

 - TCP/IP task
   This task is started by calling the above tcpip_init().
   Driver output routine also runs in TCP/IP task context.

 - Driver input task
   This task is waiting for semaphore will be signaled from receive
   interrupt handler.

   Driver interrupt handler does not call lwIP routines but just
   signals the above semaphore.
   And when this input task is wakeuped, it copys received packet in a
   pbuf and calls netif->input(pbuf, netif).
   This netif->input() passes incoming packet to TCP/IP task, because
   in my system this netif->input() is set to tcpip_input() (by
   netif_add() at the above application task).

For now, I am wondering how / where should I call dhcp_start()...
Should it be called within TCP/IP task? (same context as TCP/IP context?)
Should also DHPC timers are called within TCP/IP task?

--
Shuji KUWAHARA





reply via email to

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