Thu 11 Mar 2004 08:23:09 PM UTC, comment #1:
This bug report is invalid. lwIP is not multi-threaded, and cannot process incoming packets concurrently while running this piece of DHCP code.
It seems the bug reporter is processing incoming packets from a interrupt handler which pre-empts the current thread of execution.
Followed-up on lwip-users mailing list.
|
Thu 11 Mar 2004 08:11:38 PM UTC, original submission:
-unavailable- wrote:
> I am using lwIP 0.7.1 and found a situation that seems to be related
> to DHCP server offer timing.
>
> The following is the excerpt from dhcp_discover().
>
> /* set receive callback function with netif as user data */
> udp_recv(dhcp->pcb, dhcp_recv, netif);
>
> 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 */
At this point, the DISCOVER message is on its way to a DHCP server.
We must now listen to any DHCP server for an OFFER message. However,
the PCB is still "connected" to remote address IP_ADDR_BROADCAST, which
is 255.255.255.255.
> 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 */
>
Only after the connect, we accept packets from ANY address (0.0.0.0).
So yes, you have found a race condition.
|