Re: [lwip-users] FW: Problem with renewing DHCP after link down/up with the new LWIP V2.0.2

[simeon.trifonov]

Thank you for the response. Yes, it seems that the renewing works well, I
just had a wrong understanding what I have to expect. But the LWIP stack
V1.4.1 worked in a different way and when I migrated to 2.0.2 (now 2.0.3) I
had problems with my code. My mistake, sorry...
Now I'm trying to reconnect the Ethernet cable to another network (different
address area). The device sends a DHCP request which is a broadcast, but the
source is the IP address of the device from the former network and probably
as it is expected, it is not answered. I'm wondering how can I handle this
situation too? Should I use dhcp_stop(), dhcp_start() to be able to handle
all situations by reconnecting instead of dhcp_renew()? But I know that in
this case the DHCP server can give another address to the device. Which way
is the right one?

Simeon

> -----Original Message-----
> From: lwip-users <lwip-users-bounces+simeon.trifonov=amk-
> address@hidden> On Behalf Of address@hidden
> Sent: Friday, March 30, 2018 10:50 AM
> To: Mailing list for lwIP users <address@hidden>
> Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link
> down/up with the new LWIP V2.0.2
> 
> On 30.03.2018 08:56, SciMan wrote:
> > Hi!
> > I have stopped my trials to start-up the DHCP renewing cause it wasn't
> > really required. But now I'm back to this task and I still cannot find
> > a solution.
> > After power on, the device received a new address and all is fine.
> > When I disconnect and connect the Ethernet cable, I get the following
log:
> > <http://lwip.100.n7.nabble.com/file/t1647/dhcp_renew.jpg>
> 
> That's not a log, that's a screenshot. We can't see the packet's contents,
so
> how would we know what's in there?
> 
> > The address is valid, but the status change callback is not called.
> 
> Which status callback do you expect to be called? If everything works
fine,
> the address does not change, so the netif status callback is not called.
The
> link status callback should be called though. And the netif status
callback
> should be called if renewing fails...
> 
> > This
> > probably means that the device didn't accepted the new address. I see
> > in the source of the stack that the callback is called after binding
> > to the new address (then function netif_set_ipaddr() is called).
> 
> No, netif_set_ipaddr() only results in a status callback if the address
has
> changed.
> 
> > I also don't
> > understand why there is a second request that is not broadcast. Is
> > that expected?
> 
> Hmm, I don't know. I'll have to check that. Seems wrong...
> 
> Simon
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users