[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
signature.asc
Description: Digital signature