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

[simeon.trifonov]

OK, I have already explanation of my strange problems with the DHCP renew. The 
problem was, unfortunately, in my code ☹. The stack stores a chained pcbs for 
all UDP connections. DHCP creates such connection when it is started. But 
because of my mistake, I brake the chain and I'm losing connection with the 
pcb, created from the DHCP (the first one that was created after power on). 
Therefore by renew the stack doesn't find a pcb for port 68. After a small fix 
in my code all works just fine and it is so simple as it should be.

 

Simeon 

 

> -Original Message-

> From: lwip-users <lwip-users-bounces+simeon.trifonov=amk-

> drives...@nongnu.org> On Behalf Of goldsi...@gmx.de

> Sent: Friday, March 30, 2018 4:10 PM

> To: Mailing list for lwIP users <lwip-users@nongnu.org>

> Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link

> down/up with the new LWIP V2.0.2

> 

> On 30.03.2018 13:01,  <mailto:simeon.trifo...@amk-drives.bg> 
> simeon.trifo...@amk-drives.bg wrote:

> > I replaced the function dhcp_renew() with dhcp_network_changed().

> > After power on, the dhcp works fine again (the complete log is

> > attached). The first strange thing for me is the ARPs that follow. The

> > devices askes who has IP address 192.168.5.60, but it is his new address... 
> > Is

> that normal?

> 

> Yes. The client checks if the address assigned by the server is really unused.

> This is sometimes called "address collision detection" (ACD) and is e.g.

> required for Ethernet-IP at least... Just yesterday I had a DHCP server

> assigning a duplicate address, where this helps :-)

> 

> > The other strange thing is that if I disconnect the Ethernet cable and

> > connect it again (in the same network), all things that follow (after

> > line

> > 12) are not understandable for me.

> 

> The IP checksum of the DHCP ACKs are 0, but that might be checksum

> offloading because you monitor on the host that is running the DHCP server?

> If not, it's correct that lwIP does not get them.

> 

> > I seems that my device doesn't receive the frames from the DHCP

> > server.

> 

> Hmm, looking again, it seems that lwIP just does not receive the answers as

> valid DHCP packets, as it sends an ICMP "port unreachable" as response.

> That's strange... I don't think that's a problem with your tunneling thing...

> 

> Simon

> 

> ___

> lwip-users mailing list

>  <mailto:lwip-users@nongnu.org> lwip-users@nongnu.org

>  <https://lists.nongnu.org/mailman/listinfo/lwip-users> 
> https://lists.nongnu.org/mailman/listinfo/lwip-users

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

On 30.03.2018 13:01, simeon.trifo...@amk-drives.bg wrote:

I replaced the function dhcp_renew() with dhcp_network_changed(). After
power on, the dhcp works fine again (the complete log is attached). The
first strange thing for me is the ARPs that follow. The devices askes who
has IP address 192.168.5.60, but it is his new address... Is that normal?


Yes. The client checks if the address assigned by the server is really 
unused. This is sometimes called "address collision detection" (ACD) and 
is e.g. required for Ethernet-IP at least... Just yesterday I had a DHCP 
server assigning a duplicate address, where this helps :-)



The other strange thing is that if I disconnect the Ethernet cable and
connect it again (in the same network), all things that follow (after line
12) are not understandable for me.


The IP checksum of the DHCP ACKs are 0, but that might be checksum 
offloading because you monitor on the host that is running the DHCP 
server? If not, it's correct that lwIP does not get them.



I seems that my device doesn't receive
the frames from the DHCP server.


Hmm, looking again, it seems that lwIP just does not receive the answers 
as valid DHCP packets, as it sends an ICMP "port unreachable" as 
response. That's strange... I don't think that's a problem with your 
tunneling thing...


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[simeon.trifonov]

I replaced the function dhcp_renew() with dhcp_network_changed(). After
power on, the dhcp works fine again (the complete log is attached). The
first strange thing for me is the ARPs that follow. The devices askes who
has IP address 192.168.5.60, but it is his new address... Is that normal?
The other strange thing is that if I disconnect the Ethernet cable and
connect it again (in the same network), all things that follow (after line
12) are not understandable for me. I seems that my device doesn't receive
the frames from the DHCP server. But I have a bad feeling about this. The
Ethernet traffic on my device is tunneled by VARAN interface. I suspect that
after the reconnection, something doesn't work as expected with this
tunneling of the Ethernet frames. However, this is a topic for another
forums. It is surely not a LWIP problem. But I'm really interested how the
ARP that I mentioned above can be explained?!

Simeon

> -Original Message-
> From: lwip-users <lwip-users-bounces+simeon.trifonov=amk-
> drives...@nongnu.org> On Behalf Of goldsi...@gmx.de
> Sent: Friday, March 30, 2018 11:44 AM
> To: Mailing list for lwIP users <lwip-users@nongnu.org>
> Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link
> down/up with the new LWIP V2.0.2
> 
> On 30.03.2018 10:40, simeon.trifo...@amk-drives.bg wrote:
> > [..]
> > 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()?
> 
> Ehrm, when reconnecting the link, you should now call dhcp_renew() at all.
> Instead, call dhcp_network_changed(). This function does the correct thing
> depending on dhcp state. In your situation, it will call dhcp_reboot(),
which
> should try to renew the lease and if that fails request a new one via
> broadcast.
> 
> Simon
> 
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


dhcp_network_changed.pcapng
Description: Binary data
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

On 30.03.2018 10:40, simeon.trifo...@amk-drives.bg wrote:

[..]
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()?


Ehrm, when reconnecting the link, you should now call dhcp_renew() at 
all. Instead, call dhcp_network_changed(). This function does the 
correct thing depending on dhcp state. In your situation, it will call 
dhcp_reboot(), which should try to renew the lease and if that fails 
request a new one via broadcast.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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-
> drives...@nongnu.org> On Behalf Of goldsi...@gmx.de
> Sent: Friday, March 30, 2018 10:50 AM
> To: Mailing list for lwIP users <lwip-users@nongnu.org>
> 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
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[SciMan]

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:
 

The address is valid, but the status change callback is not called. 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). I also don't
understand why there is a second request that is not broadcast. Is that
expected?

In my code I do the following. By detecting link down from the HW, I call
netif_set_link_down(). I have callback function that is called by link
status change that calls dhcp_renew(). By link up detected from the HW, I
call netif_set_link_up(). That's all. I expect that when the DHCP has
delivered a new address after renewing, the status change callback will be
called, so I will be able to inform the higher level software about the new
IP address (normally it should be the same), but this never happens after
DHCP renewing.
What I'm doing wrong? I really need some help here...

Simeon



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[goldsi...@gmx.de]

Could you please stop quoting over 80kb per mail? Thanks.

simeon.trifo...@amk-drives.bg wrote:

I also set the IP address and mask to 0 when I detect link down.


Ehrm, why do you do that? When DHCP is enabled, DHCP has control over 
the IP addresses. If you mess with them manually while DHCP is enabled, 
it's not strange at all that things don't work.


Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

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

[simeon.trifonov]

Hi Noam,

 

I use OS, but actually this is not important, because I use the stack in a 
single thread. So I don’t expect problems from not thread safe functions. 

I also set the IP address and mask to 0 when I detect link down. But I expect 
somehow to have a function call when the IP address is assigned again via DHCP. 
This works during the first start of the device. But after diconnect/connect of 
the Ethernet cable, the callback is not called anymore, even if the address is 
assigned. I don’t like the polling solution. I’m working on an embedded device 
and I don’t need to waste time for such operations.

So the principle questions are:

*   Why dhcp_renew() doesn’t work as before (in V1.4.1)? Is this behavior 
expected or I’m doing something wrong?
*   Is it correct to make dhcp_stop() dhcp_start() during link down/up to 
have a correct DHCP behavior?
*   When the status change callback is called? When I’m looking the code is 
seems that happens only during net up and down. But after the device start-up 
this callback is called also when the address is assigned via DHCP.

And Noam, thank you for your advices and your will to help… Next week, I’m not 
in an official trip abroad so I will not be able to work on this project, but 
when I come back, I will continue with it.

 

Have a nice weekend too!

 

Simeon

 

From: lwip-users 
[mailto:lwip-users-bounces+simeon.trifonov=amk-drives...@nongnu.org] On Behalf 
Of Noam Weissman
Sent: Friday, October 06, 2017 11:16 AM
To: 'Mailing list for lwIP users' <lwip-users@nongnu.org>
Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link down/up 
with the new LWIP V2.0.2

 

Hi Simeon,

 

Do you use an OS ?... if you do, you are not supposed to call dhcp_start etc... 
but rather netif_dhcp_start (or similar) 

I am not by PC so I writing from memory 

 

The difference are that the first must be called from within LwIP own task as 
it is not thread safe, while the second can 

be called from your own code and is thread safe.

 

What I am doing is running a task that sets address/mask etc to ZERO, poll's 
the address gotten from DHCP and if it get assigned

I have a new address.  I can send you my code on Sunday when I will return to 
work.

 

Have a nice weekend,

Noam.

 

  _  

From: lwip-users <lwip-users-bounces+noam=silrd@nongnu.org 
<mailto:lwip-users-bounces+noam=silrd@nongnu.org> > on behalf of 
simeon.trifo...@amk-drives.bg <mailto:simeon.trifo...@amk-drives.bg>  
<simeon.trifo...@amk-drives.bg <mailto:simeon.trifo...@amk-drives.bg> >
Sent: Friday, October 6, 2017 9:49 AM
To: 'Mailing list for lwIP users'
Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link down/up 
with the new LWIP V2.0.2 

 

Hi Noam,

 

I tried to find out something concerning my problem, but without success. 
However, I have a little progress. If I call the function dhcp_stop() on link 
down event (immediately after the call of netif_set_link_down(), then I call 
dhcp_start() in the same way on link up event, then the DHCP works fine. It 
works again after the reconnection. But there is still one problem. The 
callback function for state change is not called when the address is receive. 
This is a problem for me, because I want to inform the higher level software 
for the new address and I’m using for this purpose the callback for status 
change. So actually this is not the solution I want and any further ideas are 
welcome.

 

Simeon

 

From: lwip-users 
[mailto:lwip-users-bounces+simeon.trifonov=amk-drives...@nongnu.org] On Behalf 
Of Noam Weissman
Sent: Thursday, October 05, 2017 3:20 PM
To: lwip-users@nongnu.org <mailto:lwip-users@nongnu.org> 
Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link down/up 
with the new LWIP V2.0.2

 

Hi Simeon,

 

I am out of my office till next week so I cannot send any code. I am working 
with LwIP 2.02

and my DHCP works fine. There were a few small changes in using it.

 

I suggest searching the forum as this was addressed several times and I am sure 
you can 

find what you need in older correspondence.

 

BR,

Noam.

 

  _  

From: lwip-users < <mailto:lwip-users-bounces+noam=silrd@nongnu.org> 
lwip-users-bounces+noam=silrd@nongnu.org> on behalf of  
<mailto:simeon.trifo...@amk-drives.bg> simeon.trifo...@amk-drives.bg < 
<mailto:simeon.trifo...@amk-drives.bg> simeon.trifo...@amk-drives.bg>
Sent: Thursday, October 5, 2017 2:50 PM
To:  <mailto:lwip-users@nongnu.org> lwip-users@nongnu.org
Subject: [lwip-users] FW: Problem with renewing DHCP after link down/up with 
the new LWIP V2.0.2 

 

I’m still can’t come to a solution of my problem. But my information wasn’t 
very exact. To be more clear I made a log with Wireshark:

 



 

The first 4 lines show normal start-up process. The address is received and all 
works fine. When the cable is unplugged and plugged again, we see

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

[simeon.trifonov]

Hi Noam,

 

I tried to find out something concerning my problem, but without success. 
However, I have a little progress. If I call the function dhcp_stop() on link 
down event (immediately after the call of netif_set_link_down(), then I call 
dhcp_start() in the same way on link up event, then the DHCP works fine. It 
works again after the reconnection. But there is still one problem. The 
callback function for state change is not called when the address is receive. 
This is a problem for me, because I want to inform the higher level software 
for the new address and I’m using for this purpose the callback for status 
change. So actually this is not the solution I want and any further ideas are 
welcome.

 

Simeon

 

From: lwip-users 
[mailto:lwip-users-bounces+simeon.trifonov=amk-drives...@nongnu.org] On Behalf 
Of Noam Weissman
Sent: Thursday, October 05, 2017 3:20 PM
To: lwip-users@nongnu.org
Subject: Re: [lwip-users] FW: Problem with renewing DHCP after link down/up 
with the new LWIP V2.0.2

 

Hi Simeon,

 

I am out of my office till next week so I cannot send any code. I am working 
with LwIP 2.02

and my DHCP works fine. There were a few small changes in using it.

 

I suggest searching the forum as this was addressed several times and I am sure 
you can 

find what you need in older correspondence.

 

BR,

Noam.

 

  _  

From: lwip-users <lwip-users-bounces+noam=silrd@nongnu.org 
<mailto:lwip-users-bounces+noam=silrd@nongnu.org> > on behalf of 
simeon.trifo...@amk-drives.bg <mailto:simeon.trifo...@amk-drives.bg>  
<simeon.trifo...@amk-drives.bg <mailto:simeon.trifo...@amk-drives.bg> >
Sent: Thursday, October 5, 2017 2:50 PM
To: lwip-users@nongnu.org <mailto:lwip-users@nongnu.org> 
Subject: [lwip-users] FW: Problem with renewing DHCP after link down/up with 
the new LWIP V2.0.2 

 

I’m still can’t come to a solution of my problem. But my information wasn’t 
very exact. To be more clear I made a log with Wireshark:

 



 

The first 4 lines show normal start-up process. The address is received and all 
works fine. When the cable is unplugged and plugged again, we see new DHCP 
request and acknowledge two times (line No. 17 to 23). In this case the state 
change callback is not called, that means IP address is now received. Then new 
discover-frame follows. 

I need an advice, please!

 

Simeon

 

From: simeon.trifo...@amk-drives.bg <mailto:simeon.trifo...@amk-drives.bg>  
[mailto:simeon.trifo...@amk-drives.bg] 
Sent: Thursday, October 05, 2017 10:15 AM
To: 'lwip-users@nongnu.org' <lwip-users@nongnu.org 
<mailto:lwip-users@nongnu.org> >
Subject: Problem with renewing DHCP after link down/up with the new LWIP V2.0.2

 

Hi,

I’m facing to a problem with the renew of the DHCP after link down/up. With 
V1.4.1 all worked fine. Probably I’m missing something now. I call correct the 
functions netif_set_link_up() and netif_set_link_down() when the corresponding 
events occur. After power on DHCP works fine. But after disconnecting and 
connecting back the cable, I see that the discover-frame is sent from the stack 
and an offer-frame is returned from the DHCP server, but there is no reaction 
from the stack. Also the callback for status change is not called. I tried to 
call additionally netif_set_up() and dhcp_renew when link up event is 
generated, but there is no change. Can you give me a hint what I’m missing?

 

Simeon

 

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users