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 is dbus mandatory (Louis Rannou)
2. Re: Why is dbus mandatory (Daniel Wagner)
3. Re: Weird UBIFS error to cause connmand crashed in UBIFS volume root
(Daniel Wagner)
4. Release 1.38 (Daniel Wagner)
5. [PATCH] iwd: Fix uninitialized access in tech_enable_tethering_cb()
(Daniel Wagner)
6. Re: [PATCH] iwd: Fix uninitialized access in tech_enable_tethering_cb()
(Daniel Wagner)
----------------------------------------------------------------------
Date: Mon, 17 Feb 2020 09:14:57 +0100
From: Louis Rannou <[email protected]>
Subject: Re: Why is dbus mandatory
To: [email protected], Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
Content-Type: multipart/alternative;
boundary=----TVD371H4S44TNIKEDSEVQ8A1EHH7TT
------TVD371H4S44TNIKEDSEVQ8A1EHH7TT
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hello Daniel, thanks for the answer=2E We also need GSM and I know ofono is=
nice=2E
I guess connman is more adapted on a target that are already using dbus=2E=
In our position, dbus is coming with glib and that's too much for us=2E
I'll check the openwrt netwok tool !
Thanks again,
Louis
Le 14 f=C3=A9vrier 2020 18:27:53 GMT+01:00, Daniel Wagner <wagi@monom=2Eor=
g> a =C3=A9crit=C2=A0:
>Hi Louis,
>
>On Fri, Feb 14, 2020 at 03:56:00PM +0100, Louis Rannou wrote:
>> I wonder why is dbus mandatory ? Is it just for the client and plugins =
or is
>> it part of the core ?
>
>The D-Bus APIs are part of the core=2E It's not an optional=2E
>
>> We would like to use connman but we'd like it to be as small as possibl=
e=2E
>> Could you say it's possible to get rid of dbus ?
>
>Sure it's possible to get rid of the D-Bus code, it's just work=2E But
>this would be something you have to do own your own=2E
>
>> I looked for technical documentation such as architecture, but I could =
not
>> find any=2E
>
>It's a design decision=2E The way to control and talk to ConnMan is via
>D-Bus=2E
>
>Is your target platform/device just using WiFi? If so you could use
>iwd directly for this=2E This would shrink the footprint considerable,
>even though you still need D-Bus=2E
>
>IIRC, the OpenWRT project has a network manager which is not depending
>on D-Bus and is designed for small devices=2E
>
>Thanks,
>Daniel
>_______________________________________________
>connman mailing list -- connman@lists=2E01=2Eorg
>To unsubscribe send an email to connman-leave@lists=2E01=2Eorg
------TVD371H4S44TNIKEDSEVQ8A1EHH7TT
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Hello Daniel, thanks for the answer=2E We also nee=
d GSM and I know ofono is nice=2E<br><br>I guess connman is more adapted on=
a target that are already using dbus=2E In our position, dbus is coming wi=
th glib and that's too much for us=2E<br><br>I'll check the openwrt netwok =
tool !<br><br>Thanks again,<br>Louis<br><br><div class=3D"gmail_quote">Le 1=
4 f=C3=A9vrier 2020 18:27:53 GMT+01:00, Daniel Wagner <wagi@monom=2Eorg&=
gt; a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;">
<pre class=3D"k9mail">Hi Louis,<br><br>On Fri, Feb 14, 2020 at 03:56:00PM =
+0100, Louis Rannou wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1e=
x;">I wonder why is dbus mandatory ? Is it just for the client and plugins =
or is<br>it part of the core ?<br></blockquote><br>The D-Bus APIs are part =
of the core=2E It's not an optional=2E<br><br><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; =
padding-left: 1ex;">We would like to use connman but we'd like it to be as =
small as possible=2E<br>Could you say it's possible to get rid of dbus ?<br=
></blockquote><br>Sure it's possible to get rid of the D-Bus code, it's jus=
t work=2E But<br>this would be something you have to do own your own=2E<br>=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex;=
border-left: 1px solid #729fcf; padding-left: 1ex;">I looked for technical=
documentation such as architecture, but I could not<br>find any=2E<br></bl=
ockquote><br>It's a design decision=2E The way to control and talk to ConnM=
an is via<br>D-Bus=2E<br><br>Is your target platform/device just using WiFi=
? If so you could use<br>iwd directly for this=2E This would shrink the foo=
tprint considerable,<br>even though you still need D-Bus=2E<br><br>IIRC, th=
e OpenWRT project has a network manager which is not depending<br>on D-Bus =
and is designed for small devices=2E<br><br>Thanks,<br>Daniel<hr>connman ma=
iling list -- connman@lists=2E01=2Eorg<br>To unsubscribe send an email to c=
onnman-leave@lists=2E01=2Eorg<br></pre></blockquote></div></body></html>
------TVD371H4S44TNIKEDSEVQ8A1EHH7TT--
------------------------------
Date: Mon, 17 Feb 2020 09:46:16 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Why is dbus mandatory
To: Louis Rannou <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Louis,
On Mon, Feb 17, 2020 at 09:14:57AM +0100, Louis Rannou wrote:
> Hello Daniel, thanks for the answer. We also need GSM and I know ofono is
> nice.
FYI, oFono is also depending on D-Bus.
> I guess connman is more adapted on a target that are already using dbus.
Indeed, ConnMan doesn't have many dependencies on the platform but one is D-Bus.
> In our position, dbus is coming with glib and that's too much for us.
Understood. glib is huge and the long time plan is to use ELL instead.
> I'll check the openwrt netwok tool !
As far I know, they don't use glib :)
Thanks,
Daniel
------------------------------
Date: Mon, 17 Feb 2020 09:57:46 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Weird UBIFS error to cause connmand crashed in UBIFS
volume root
To: JH <[email protected]>
Cc: connman <[email protected]>, linux-mtd
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Sun, Feb 16, 2020 at 08:24:04PM +1100, JH wrote:
> I have been playing kernel mont to UBIFS rootfs volume for several
> days, the kernel can now mount to UBIFS volume root, the system
> services were running fine except the connection manager connmand
> service failed, I restarted it again and again, the connman was always
> crashed and ubifs_read_node: bad node type. Despite the UBIFS errors,
> the system could be still running, I could type shell comands in
> console when connman was stopped.
>
> I am not clear if UBIFS errors caused connman failure or connman
> caused UBIFS error, and why it always failed in connman, was it
> coincident or was some special in connman man link to other things
> such as udev to cause the issues?
Have you enabled the stats file feature in ConnMan? It's enabled on
default. Try again with '--disable-stats' and check if it makes a
difference.
Background: ConnMan save networking stats into a ring buffer file. The
file write operations are done via a mmap'ed memory. To avoid data
loss a double buffering approach with an 'atomic' swap is used:
stats_file_unmap(history_file);
stats_file_unmap(temp_file);
close(temp_file->fd);
unlink(history_file->name);
err = link(temp_file->name, history_file->name);
unlink(temp_file->name);
close(history_file->fd);
stats_file_cleanup(history_file);
stats_file_cleanup(temp_file);
IIRC, f2fs is known not to work. Maybe there is also some limits on
ubifs as well.
Thanks,
Daniel
------------------------------
Date: Mon, 17 Feb 2020 10:09:45 +0100
From: Daniel Wagner <[email protected]>
Subject: Release 1.38
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi,
After almost a year, we have a new release of ConnMan. There were many
small contributions, many bug fixes. I'd like to thank all of you for
your support and contributions:
David Llewellyn-Jones, David Weidenkopf, Mickael
GARDET, Santtu Lakkala, Henrik Persson, Joakim Lotsengård, John
Keeping, Julien Massot, Marcel Holtmann, Marcus Folkesson, Matt Vogt,
Nicola Lunghi, Robert Tiemann, Slava Monich, Torstein Husebø, Vivien
Henriet, Yasser, [email protected]
I really like to thank Jussi Laakkonen for his contributions. He
improved the VPN code a lot. Jussi and I together made together 87% of
the changes.
There a couple new features: support for iwd and WireGuard.
Thanks,
Daniel
------------------------------
Date: Mon, 17 Feb 2020 10:22:44 +0100
From: Daniel Wagner <[email protected]>
Subject: [PATCH] iwd: Fix uninitialized access in
tech_enable_tethering_cb()
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
gcc reports with:
plugins/iwd.c: In function ‘tech_enable_tethering_cb’:
plugins/iwd.c:575:15: warning: ‘iwdap’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
575 | g_free(iwdap->bridge);
---
Argh! Why didn't gcc complain earlier?
plugins/iwd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/iwd.c b/plugins/iwd.c
index bf6a2c261041..65cdaf99cb2b 100644
--- a/plugins/iwd.c
+++ b/plugins/iwd.c
@@ -535,7 +535,7 @@ static void tech_enable_tethering_cb(const DBusError
*error, void *user_data)
{
struct tech_cb_data *cbd = user_data;
struct iwd_device *iwdd;
- struct iwd_ap *iwdap;
+ struct iwd_ap *iwdap = NULL;
DBG("");
--
2.25.0
------------------------------
Date: Mon, 17 Feb 2020 10:24:46 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] iwd: Fix uninitialized access in
tech_enable_tethering_cb()
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Mon, Feb 17, 2020 at 10:22:44AM +0100, Daniel Wagner wrote:
> gcc reports with:
>
> plugins/iwd.c: In function ‘tech_enable_tethering_cb’:
> plugins/iwd.c:575:15: warning: ‘iwdap’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> 575 | g_free(iwdap->bridge);
> ---
>
> Argh! Why didn't gcc complain earlier?
Patch applied
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 52, Issue 18
***************************************
