7:35 a.m.
Hi Pieter,
On Wed, Oct 07, 2020 at 10:12:03AM +0000, Pieter Cardoen wrote:
We are using connman as network manager for our embedded devices. We
are currently facing an issue regarding DHCP.
I've noted that if a service is configured to use DHCP, a DHCP discover message is
sent multiple times (DISCOVER_RETRIES). If the DHCP server doesn't respond in time, a
fallback scenario is used and a fixed static IP address is configured instead.
For or application, this behaviour is unexpected and a device should keep sending
discover messages until the end of times đ.
We currently applied a dirty fix (see below). What is the reason of this fallback
behaviour and is it possible to configure connman to keep sending discovers in a better
way?
Which version of ConnMan are you using. The current version should keep
sending DHCP discovery message.
Thanks,
Daniel
2:14 p.m.
New subject: dhcp discover timeout
Dear Daniel
I've just re-executed this test using the latest master:
commit f867b03e3040f5f0d8fe29106174198de151afdd
Author: Daniel Wagner <wagi(a)monom.org>
Date: Fri Nov 20 16:27:29 2020 +0100
iwd: Enable/disable auto_connect on known networks
I'm noticing that the dhcp discover indeed continues sending requests:
Send 6 discovers with 5 seconds interval - wait 65 seconds - repeat.
Debugging dhcp results in this trace:
connmand[611]: x1 {RX} 0 packets 0 bytes
connmand[611]: x1 {TX} 51 packets 22338 bytes
connmand[611]: x1 {update} flags 102467 <UP,RUNNING,LOWER_UP>
connmand[611]: x1 {newlink} index 4 address 00:0E:3D:01:EA:9F mtu 1500
connmand[611]: x1 {newlink} index 4 operstate 6 <UP>
connmand[611]: DHCP index 4: switch listening mode (0 ==> 1)
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: ipconfig state 3 ipconfig method 1
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: DHCP index 4: sending DHCP discover request
connmand[611]: IPv4LL index 4: sending IPV4LL probe request
connmand[611]: IPv4LL index 4: switch listening mode (0 ==> 3)
connmand[611]: IPv4LL index 4: IPV4LL probe timeout (retries 1)
connmand[611]: IPv4LL index 4: sending IPV4LL probe request
connmand[611]: IPv4LL index 4: IPV4LL probe timeout (retries 2)
connmand[611]: IPv4LL index 4: sending IPV4LL probe request
connmand[611]: IPv4LL index 4: IPV4LL probe timeout (retries 3)
connmand[611]: IPv4LL index 4: sending IPV4LL announce request
connmand[611]: IPv4LL index 4: request timeout (retries 1)
connmand[611]: IPv4LL index 4: sending IPV4LL announce request
connmand[611]: IPv4LL index 4: request timeout (retries 2)
connmand[611]: IPv4LL index 4: switching to monitor mode
connmand[611]: x1 {add} address 169.254.98.96/16 label x1 family 2
connmand[611]: x1 {add} route 169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
connmand[611]: x1 {add} route 0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Why is the static ip address assigned?
Thanks for the support
Pieter
________________________________
Van: Daniel Wagner <wagi(a)monom.org>
Verzonden: donderdag 8 oktober 2020 8:35
Aan: Pieter Cardoen <P.Cardoen(a)TELEVIC.com>
CC: connman(a)lists.01.org <connman(a)lists.01.org>
Onderwerp: Re: dhcp discover timeout
CAUTION: This Email originated from outside Televic. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hi Pieter,
On Wed, Oct 07, 2020 at 10:12:03AM +0000, Pieter Cardoen wrote:
We are using connman as network manager for our embedded devices. We
are currently facing an issue regarding DHCP.
I've noted that if a service is configured to use DHCP, a DHCP discover message is
sent multiple times (DISCOVER_RETRIES). If the DHCP server doesn't respond in time, a
fallback scenario is used and a fixed static IP address is configured instead.
For or application, this behaviour is unexpected and a device should keep sending
discover messages until the end of times đ.
We currently applied a dirty fix (see below). What is the reason of this fallback
behaviour and is it possible to configure connman to keep sending discovers in a better
way?
Which version of ConnMan are you using. The current version should keep
sending DHCP discovery message.
Thanks,
Daniel
574
days inactive
627
days old
1 comments
2 participants
participants (2)
-
Daniel Wagner -
Pieter Cardoen