Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Why connmand consume such higher CPU resource? (JH)
2. Re: Why connmand consume such higher CPU resource? (Daniel Wagner)
3. Re: Why connmand consume such higher CPU resource? (Daniel Wagner)
----------------------------------------------------------------------
Date: Thu, 16 Jan 2020 22:07:15 +1100
From: JH <[email protected]>
Subject: Re: Why connmand consume such higher CPU resource?
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<CAA=hcwsgcmhoqj_oyzgoedv-k4neflvca6qgl1ooqbtvt_7...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On 1/16/20, JH <[email protected]> wrote:
> Hi Daniel,
>
> On 1/16/20, Daniel Wagner <[email protected]> wrote:
>>> I updated connman to 1.37 to an imx6 device with WiFi, but I got
>>> trouble to bring the WiFi up. The 1.35 worked perfectly to get and to
>>> sign an IP address from my WiFi router DHCP server. The 1.37 could not
>>> get IP address, it called check_dhcpv6() reply (nil), please see the
>>> whole debug log attached and get nil. But, a little bit late, it
>>> eventually assigned an IP address 169.254.176.66 to the WiFi
>>> interface. My WiFi route IP is in 192.168.0.x range, no ideal where
>>> was the 169.254.176.66 from, it was not connected to the Internet. Did
>>> 1.37 assign an IP to the WiFi itself if it could not get IP from the
>>> DHCP server?
>>
>> 169.254.0.0/16 is the link local address range. If there is no DHCP
>> response, ConnMan assigns the interface automatically an IP in this
>> range according the IPv4 link local protocol.
>
> So it is the new feature in 1.37?
>
>> About IPv6: do you have an IPv6 enabled network? If not, the reply
>> (nil) is to be expected.
>
> No, it only set up IPv4, so that should not be an issue.
>
>> Just to make sure, you didn't change anything except updating ConnMan?
>> No network configuration changes or distro update?
>
> The connman 1.35 was built from Yocto thud, but I could not build
> connman 1.37 in thud so I have to upgrade Yocto to zeus, no network
> configuration changes, no kernel changes using the same mwifiex, but
> build system is updated, I guess that distro is updated. But how could
> that affect to network? If libraries are missing, the connman won't be
> able to run, right?
>
>>> Appreciate your clues what I could be missing in 1.37.
>>
>>
>> $ git log --oneline 1.35.. -- gdhcp
>> 4834f197083d dhcp: Bind to interface when sending
>> b30e4cf4cbf4 gdhcp: Check for in6_pktinfo.ipi6_addr explicitly
>> 9dadd8410ac3 build: Use AC_USE_SYSTEM_EXTENSIONS
>> c52a1c09d36c gdhcp: Retry to get an IPv4ll ip even after MAX_CONFLICTS
>> bb19d2146af5 gdhcp: Fix use of dhcp_client after free
>> d12b1ab127f1 src: Remove redundant returns at the end of functions that
>> return void
>> 5c43a53f9f56 dhcp: Prefer to reuse broadcast flag from DHCPDISCOVER
>> b8566ac5a01a dhcp: Add sending of DHCP decline
>> a9c61353dc10 shared/arp: Add arp_random_ip()
>> 577def113f2c inet: Add __connman_inet_get_interface_mac_address()
>> e372af75f593 shared: Add low-level ARP functions
>> d4b2908a36ff dhcp: Use __connman_util_get_random
>> 9c8e70074259 util: Add function __connman_util_random_delay_ms
>> ac29745ff5a0 gdhcp: Fix wrong initialization of listener_watch
>> 2ea605a3fe31 gdhcp: Fixed IPv4 link-local IP conflict error.
>> 0f6e829ee7a9 gdhcp: Fixed wrong byte order.
>> $ git log --oneline 1.35.. -- src/dhcp.c b8566ac5a01a dhcp: Add sending
>> of DHCP decline
>> d4b2908a36ff dhcp: Use __connman_util_get_random
>>
>>
>> After the 1.35 release we added the ACD protocol support.
>>
>> First, set the environment variable CONNMAN_DHCP_DEBUG=1 and
>> CONNMAN_DHCPV6_DEBUG=1 (see README) before starting ConnMan with
>> logging enabled. That should give a more detailed log what's going on
>> in the DHCP layer.
>
> Attached log debug file set up CONNMAN_DHCP_DEBUG=1 and
>> CONNMAN_DHCPV6_DEBUG=1.
>
Also found kernel message:
[ 136.249655] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f erro2
[ 256.798536] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from 32
[ 257.046699] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[ 257.933383] mwifiex_sdio mmc0:0001:1: info: trying to associate to 'JupiterI2
[ 257.988831] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:y
[ 258.106868] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[ 258.183731] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
[ 320.566074] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
[ 856.809338] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from 32
[ 856.996441] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[ 857.862165] mwifiex_sdio mmc0:0001:1: info: trying to associate to 'JupiterI2
[ 857.906284] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:y
[ 857.993233] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[ 858.042788] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
Could that mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error,
result=0x2 caused the problem? I used the same kernel and the same
mwifiex_sdio in connman 1.35.
Thank you.
- jh
>> And if we don't see anything useful we need trace from wireshark.
>>
>> Thanks,
>> Daniel
>>
>
------------------------------
Date: Fri, 17 Jan 2020 08:43:08 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Why connmand consume such higher CPU resource?
To: JH <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Jan 16, 2020 at 09:08:09PM +1100, JH wrote:
> > 169.254.0.0/16 is the link local address range. If there is no DHCP
> > response, ConnMan assigns the interface automatically an IP in this
> > range according the IPv4 link local protocol.
>
> So it is the new feature in 1.37?
No it's not a new feature. Local link support is in since the early
days of ConnMan.
> > Just to make sure, you didn't change anything except updating ConnMan?
> > No network configuration changes or distro update?
>
> The connman 1.35 was built from Yocto thud, but I could not build
> connman 1.37 in thud so I have to upgrade Yocto to zeus,
That means you have a complete new system. Basically everything changed.
> no network
> configuration changes, no kernel changes using the same mwifiex, but
> build system is updated, I guess that distro is updated. But how could
> that affect to network? If libraries are missing, the connman won't be
> able to run, right?
You get a newer kernel, you get newer libraries (glibc, glib, ...)
and usually a slightly modified configuration caused due to the
updated of all components. So it's a complete new system.
> Attached log debug file set up CONNMAN_DHCP_DEBUG=1 and
> > CONNMAN_DHCPV6_DEBUG=1.
connmand[9133]: DHCP index 3: sending DHCP discover request
connmand[9133]: DHCP index 3: sending DHCP discover request
connmand[9133]: DHCP index 3: sending DHCP discover request
connmand[9133]: DHCP index 3: sending DHCP discover request
connmand[9133]: DHCP index 3: sending DHCP discover request
As you can see ConnMan is sending the DHCP requests but never sees a
DHCP respond frame. The Linux networking stack usually works fine, so
should at what the networking driver is doing.
Thanks,
Daniel
------------------------------
Date: Fri, 17 Jan 2020 08:45:13 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Why connmand consume such higher CPU resource?
To: JH <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Jan 16, 2020 at 10:07:15PM +1100, JH wrote:
> [ 136.249655] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f erro2
> [ 256.798536] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from
> 32
> [ 257.046699] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
> [ 257.933383] mwifiex_sdio mmc0:0001:1: info: trying to associate to
> 'JupiterI2
> [ 257.988831] mwifiex_sdio mmc0:0001:1: info: associated to bssid
> 34:08:04:12:y
> [ 258.106868] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
> [ 258.183731] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
> [ 320.566074] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
> [ 856.809338] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from
> 32
> [ 856.996441] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
> [ 857.862165] mwifiex_sdio mmc0:0001:1: info: trying to associate to
> 'JupiterI2
> [ 857.906284] mwifiex_sdio mmc0:0001:1: info: associated to bssid
> 34:08:04:12:y
> [ 857.993233] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
> [ 858.042788] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
>
> Could that mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error,
> result=0x2 caused the problem? I used the same kernel and the same
> mwifiex_sdio in connman 1.35.
Though I don't the driver, this looks very suspicious to me. Maybe ask
on the wifi mailing list what that means.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 21
***************************************
