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. [PATCH] iwd: Translate iwd security type (Daniel Wagner)
2. Re: [PATCH] Fix Security property for iwd wifi networks
(Daniel Wagner)
3. Re: [PATCH] iwd: Translate iwd security type (Daniel Wagner)
4. Wrong date (JH)
5. Re: Wrong date (JH)
6. Re: Why connmand consume such higher CPU resource? (JH)
----------------------------------------------------------------------
Date: Sat, 25 Jan 2020 13:00:34 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH] iwd: Translate iwd security type
To: [email protected]
Cc: David Weidenkopf <[email protected]>, Daniel Wagner
<[email protected]>
Message-ID: <[email protected]>
iwd's network type strings need to be translated to the WiFi.Security
strings.
Reported by David Weidenkopf
---
plugins/iwd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/iwd.c b/plugins/iwd.c
index 7821c51ba30b..0d1d24dc5b62 100644
--- a/plugins/iwd.c
+++ b/plugins/iwd.c
@@ -772,7 +772,7 @@ static void add_network(const char *path, struct
iwd_network *iwdn)
connman_network_set_blob(iwdn->network, "WiFi.SSID", iwdn->name,
strlen(iwdn->name));
connman_network_set_string(iwdn->network, "WiFi.Security",
- iwdn->type);
+ security_remap(iwdn->type));
connman_network_set_string(iwdn->network, "WiFi.Mode", "managed");
if (connman_device_add_network(iwdd->device, iwdn->network) < 0) {
--
2.25.0
------------------------------
Date: Sat, 25 Jan 2020 13:02:32 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] Fix Security property for iwd wifi networks
To: David Weidenkopf <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi David,
On Fri, Jan 24, 2020 at 09:53:58PM +0000, David Weidenkopf wrote:
> Found a problem where 8021x networks Security property was
> empty. This seems to fix it. Not sure if this is correct.
>
> diff --git a/plugins/iwd.c b/plugins/iwd.c
> index 7821c51b..0d1d24dc 100644
> --- a/plugins/iwd.c
> +++ b/plugins/iwd.c
> @@ -772,7 +772,7 @@ static void add_network(const char *path, struct
> iwd_network *iwdn)
> connman_network_set_blob(iwdn->network, "WiFi.SSID", iwdn->name,
> strlen(iwdn->name));
> connman_network_set_string(iwdn->network, "WiFi.Security",
> - iwdn->type);
> + security_remap(iwdn->type));
Yes, this is the correct fix. I've just send out a patch. This patch
is somehow munged up.
Thanks,
Daniel
------------------------------
Date: Sat, 25 Jan 2020 13:06:53 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] iwd: Translate iwd security type
To: [email protected]
Cc: David Weidenkopf <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi David,
On Sat, Jan 25, 2020 at 01:00:34PM +0100, Daniel Wagner wrote:
> iwd's network type strings need to be translated to the WiFi.Security
> strings.
>
> Reported by David Weidenkopf
I applied it after changing it to you as author.
Thanks,
Daniel
------------------------------
Date: Sun, 26 Jan 2020 09:15:26 +1100
From: JH <[email protected]>
Subject: Wrong date
To: Yocto discussion list <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<CAA=hcwsxzwo8suo5+dnhyuf6yvxh3d3h+fnufww1-emxakk...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
I build the image from Yocto thud and running it in imx6, usually I
got right the date, but today I got a weird wrong date:
# date
Wed Jan 15 08:13:14 UTC 2020
What could cause that problem and how to fix it? The WiFi also got a
wrong IP address 169.254.124.128, it was because failed DHCP response,
I believe that WiFi issue was also caused by the wrong date.
How does the Yocto sync the date? Does it run NTP to sync the date?
Thank you.
Kind regards,
- jh
------------------------------
Date: Sun, 26 Jan 2020 10:29:01 +1100
From: JH <[email protected]>
Subject: Re: Wrong date
To: Yocto discussion list <[email protected]>
Cc: connman <[email protected]>
Message-ID:
<CAA=hcwqhv+z9nv2q+qeccju4k9bwqwfz_ebc5qdhj6zguzl...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
It failed to start systemd-timesyncd.service:
# systemctl status systemd-timesyncd.service -l
* systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded
(8;;file://solar/lib/systemd/system/systemd-timesyncd.service/lib/systemd/system/systemd-timesyncd.service8;;;
enabled;)
Active: failed (Result: exit-code) since Sat 2020-01-25 23:26:12 UTC; 10s ago
Docs:
8;;man:systemd-timesyncd.service(8)man:systemd-timesyncd.service(8)8;;
Process: 11799 ExecStart=/lib/systemd/systemd-timesyncd
(code=exited, status=238/STATE_DIRECTORY)
Main PID: 11799 (code=exited, status=238/STATE_DIRECTORY)
Jan 25 23:26:12 solar systemd[1]: systemd-timesyncd.service: Service
has no hold-off time (RestartSec=0), scheduling restart.
Jan 25 23:26:12 solar systemd[1]: systemd-timesyncd.service: Scheduled
restart job, restart counter is at 5.
Jan 25 23:26:12 solar systemd[1]: Stopped Network Time Synchronization.
Jan 25 23:26:12 solar systemd[1]: systemd-timesyncd.service: Start
request repeated too quickly.
Jan 25 23:26:12 solar systemd[1]: systemd-timesyncd.service: Failed
with result 'exit-code'.
Jan 25 23:26:12 solar systemd[1]: Failed to start Network Time Synchronization.
root@solar:~# [ 1825.848150] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd
0x23f error, result=0x2
Manually corrected the date, but the WiFi IP address is still got
wrong IP address
On 1/26/20, JH <[email protected]> wrote:
> Hi,
>
> I build the image from Yocto thud and running it in imx6, usually I
> got right the date, but today I got a weird wrong date:
>
> # date
> Wed Jan 15 08:13:14 UTC 2020
>
> What could cause that problem and how to fix it? The WiFi also got a
> wrong IP address 169.254.124.128, it was because failed DHCP response,
> I believe that WiFi issue was also caused by the wrong date.
>
> How does the Yocto sync the date? Does it run NTP to sync the date?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
------------------------------
Date: Sun, 26 Jan 2020 17:13:34 +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=hcwqy++uhlpqkdyiv7trdc7z5tlwrbvlrbqpxjz4-12q...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Daniel,
On 1/17/20, Daniel Wagner <[email protected]> wrote:
> On Fri, Jan 17, 2020 at 09:14:15PM +1100, JH wrote:
>> On 1/17/20, Daniel Wagner <[email protected]> wrote:
>> > No it's not a new feature. Local link support is in since the early days
>> > of ConnMan.
>> I have been running 1.35 for a year, we never got the local link if
>> the WiFi was not able to be connected.
I was wrong to say I did not see the default IP in 1.35, I just found
the same problem in 1.35 that the image was built from thud, initially
I thought that was caused by the wrong date, but after manuyally fixed
the date, the IP address is still in 169.254.x.x, that is an old Yocto
build system.
> If ConnMan doesn't get an DHCP lease it always does IPv4LL when the
> interface is up and running. Maybe you disconnected before the IPv4LL
> state machine was triggered.
>
>> > 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.
>>
>> Not a new kernel, let me make it clear, it is the same kernel for both
>> 1.35 and 1.37, glibc, glib more have new versions, but I don't think
>> the network configuration would be modified.
So the same problem appeared in 1.35 that used old Yocto libraries and
kernel, it was usually all good in terms of WiFi network IP
allocation. It approved that the same problem in 1.37 is not related
to the change of libraries. But I could not figure out what is the
problem and how to fix it.
> I don't think the libraries are the source of the problem. There is a
> change in the kernel/driver behavoir as I read the logs. Maybe new
> firmware?
>
>> > 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.
>>
>> So that was the problem, that no DHCP response caused failure of WiFi
>> IP address, right? I'll do an investigation and debug to check why
>> there was no DHCP response.
>
> Yes, you should see a DCHP response frame.
Hmm, still mysterious, any clue what could cause that problem?
Thank you Daniel,
- jh
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 51, Issue 32
***************************************
