lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] DHCP usage with latest git code version


From: Sylvain Rochet
Subject: Re: [lwip-users] DHCP usage with latest git code version
Date: Fri, 11 Sep 2015 11:55:35 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Bram,

On Fri, Sep 11, 2015 at 11:48:33AM +0200, Sylvain Rochet wrote:
> Hi Bram,
> 
> On Fri, Sep 11, 2015 at 09:10:28AM +0000, Bram Peeters wrote:
> > Thanks for the clarification!
> > 
> > I had to add 
> > #define LWIP_DHCP_CHECK_LINK_UP     1
> > as well to make 
> > 
> > > netif_set_up(&gnetif);
> > > dhcp_start(&gnetif);
> > > Then DHCP will start if netif is already "link up" or at the next "link  
> > > up" event.
> > 
> > work with the netif initially in link down Otherwise the DCHP state 
> > was in DHCP_STATE_OFF mode, and stayed in that mode when 
> > dhcp_network_changed(struct netif *netif) was called when link up 
> > occurred.
> 
> I don't agree. Only dhcp_release()/dhcp_stop() (and obviously initial 
> state) switches DHCP to DHCP_STATE_OFF. (Or did you find a bug ?, if so, 
> please investigate a bit more about this issue ;-) )
> 
> The only difference LWIP_DHCP_CHECK_LINK_UP makes is that DHCP is not 
> trying to send discover frames if link is down and then wait for a link 
> up event, otherwise we are sending discover frames whatever the current 
> link state is. The dhcp_network_changed() call just speed it up by 
> cancelling retry timeout.
> 
> 
> Indeed, DHCP without LWIP_DHCP_CHECK_LINK_UP does not care about current 
> link state, I should have mentioned that. So it should work whatever the 
> current shape of your link up/down events handler is.

After thinking about it again. It looks like your lwIP timers(timeouts) 
are not working, which could be an issue with your port.

Sylvain

Attachment: signature.asc
Description: Digital signature


reply via email to

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