Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, 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: Connman on Android/Brillo (Marcel Holtmann)
2. Re: [PATCH] timezone: Add support for setting timezone using
timedated (Marcel Holtmann)
3. Re: Add speed information to services (Marcel Holtmann)
4. Re: /etc/resolv.conf disable overwrite (Marcel Holtmann)
----------------------------------------------------------------------
Message: 1
Date: Sat, 27 Aug 2016 07:12:38 -0700
From: Marcel Holtmann <[email protected]>
To: [email protected]
Cc: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: Connman on Android/Brillo
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Naveen,
> > I had this talk with Marcel few weeks back about compiling connman on
> > Android/Brillo. This would surely give connman the penetration into
> > Android world and future IoT devices which are based of Brillo.
> >
> > I actually got it compiled and working. There are two challenges:
> >
> > a) Some of the libraries that are required by connman are missing.
> > For
> > my work I got those libraries compiled first.
> >
> > b) Changes in connman itself: Open source connman does not compile as
> > such for Android/Brillo. There are some changes needed in connman to
> > get this going. I would like to see if we can upstream these changes.
> >
> > The intent of this email is to discuss those changes. Following are
> > the changes needed:
> >
> > 1) Backtrace system call: In log.c from function print_backtrace we
> > call backtrace. It is a glibc API and is no present in bionic. There
> > is an equivalent function in bionic for doing this.
>
> Backtrace printing was moved to its own file, src/backtrace.c, in
> ConnMan 1.32, so this is just an automake check away.
>
> > 2) hard check for ns_initparse in libresolv.so: There is no
> > libresolv.so for android/Brillo. All these ns_* symbols are part of
> > libc.so. So hard check has to go. We may need to check in
> > configure.ac
> > whether we are compiling against glibc or bionic early on and do
> > stuff
> > differently.
>
> Yes, some automake magic needed.
>
> > 3) NTP code calls adjtime to adjust clock. This function is missing
> > in
> > bionic. We may need to find a similar function in bionic for doing
> > this.
>
> The adjtimex patch on the ml will probably solve this. I'll take a look
> at that patch nextish.
>
> > 4) struct in6_pktinfo is defined in connman code (file
> > gdhcp/common.h)
> > under #ifndef __USE_GNU. Now this structure is defined in bionic
> > header file libc/kernel/uapi/ipv6.h. Not sure what is the intent of
> > #ifndef __USE_GNU? Should this go away? Similarly struct in6_ifreq is
> > defined in inet.c file and it is also defined in the same bionic
> > header file. I had to comment out this definition to compile connman.
>
> See commit message for e8784053a0a680ec8943ff20559c6561cb5b9a96.
> For struct in6_ifreq it looks like very old code that should be fixed.
>
> > 5) Some of the structures which are needed for connman compilation
> > are
> > defined under #ifdef __USE_BSD in bionic header file. For Bionic
> > __USE_BSD is defined only if _GNU_SOURCE is defined. So for those
> > files in connman we have to define _GNU_SOURCE as the first line in
> > that file. Example is ipv4ll.c. I hope this should be OK.
>
> I'd like to keep the files as clean as possible. Looking at autoconf
> magic, it seems to be possible to use AC_DEFINE to add values to the
> generated config.h file, which is included first. config.h is used
> everywhere and should be the first file included. So could one add the
> needed defines in order to config.h with AC_DEFINE instead? And/or the
> use of bionic, if needed?
>
> > 6) GResolv structure in gresolv.c: struct __res_state is a member for
> > GResolv structure. This structure is defined in resolv.h file in
> > glibc. struct __res_state in bionic requires inclusion of two other
> > header files resolv_private.h and res_private. Also this structure is
> > defined very differently between bionic and glibc. This caused
> > changes
> > in gresolv.c, the way it accesses various members of this structure.
>
> Ok, sounds a bit more complicated. You should perhaps post an RFC patch
> for this so we have an idea of how complicated it becomes.
>
> > 7) Struct sockaddr_in6 defined differently b/w bionic and glibc.
>
> What is the difference here? Something that does not compile on both
> "platforms"?
>
> > 8) ETH_ALEN is not defined in bionic header file
>
> Should be easy once we know bionic is being used.
>
> > 9) Need to include resolv_params.h in resolver.c. This is because
> > "MAXDNSRCH" etc is defined in resolv_params.h in bionic.
>
> Automake/conf magic, I hope.
>
> > 10) Needed to remove "-lresolv -lrt" from Makefile.am.
>
> As above, I hope.
>
> > Some of these changes are easily doable if we can have #ifdef ANDROID
> > in code. Through configure.ac we can detect if we are compiling
> > against bionic or glibc and appropriately turn on this flag. Not sure
> > what your thought are on this.
>
> I'd go for configure.ac, it makes the code cleaner and uses
> autoconf/automake for it's intended purpose. Let's start with the easy
> parts first.
>
> Thanks for the heads up!
>
>
> Patrik
> Something like this: (it may not be syntactically correct)
> with_android=no
> AC_MSG_CHECKING([checking for android])
>
>
> case "${host}" in
>
>
>
> *android*)
>
> with_android=yes
>
> ;;
>
>
>
> *)
>
> AM_CONDITIONAL([BIONIC], [test "${with_android}" = "yes"])
this should be the last resort in handling it. BlueZ for Android can compile
either with glibc/musl or with Bionic. And I think we should get to the level
where we do not have huge difference.
That said, I recognize that Bionic is just plain ancient and missing anything
modern. Which is the biggest pain. Especially with networking capabilities it
seems it never caught up to anything recent. I would actually try to detect
every missing piece individually and not just use a big hammer like HAVE_BIONIC.
With that in mind, lets just get patches to the mailing list and together
figure out a way to make this least intrusive to the code base. It is not the
first time we dealt with Android specific, but this might be the most painful
one since ConnMan uses a lot of low-level stuff.
Regards
Marcel
------------------------------
Message: 2
Date: Sat, 27 Aug 2016 07:15:48 -0700
From: Marcel Holtmann <[email protected]>
To: Philip Withnall <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] timezone: Add support for setting timezone using
timedated
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Philip,
> If we are running under systemd, the ProtectSystem key in our .service
> file prevents us from writing to /etc/localtime. Instead, set the
> timezone by using org.freedesktop.timedate1 over D-Bus, if it is
> available. If it is not available, fall back to /etc/localtime.
>
> Signed-off-by: Philip Withnall <[email protected]>
> ---
> src/timezone.c | 213
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 210 insertions(+), 3 deletions(-)
how hard would it to build a connman_timezone_driver_register infrastructure?
Hard coding systemd D-Bus APIs and a fallback seems like the wrong approach. I
think we should have a plugin to overwrite default behavior. Similar to what we
do with proxies and other features.
Regards
Marcel
------------------------------
Message: 3
Date: Sat, 27 Aug 2016 07:23:32 -0700
From: Marcel Holtmann <[email protected]>
To: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Add speed information to services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jose,
> Nowadays most of the smartphones and laptops (Windows and Linux) provide the
> link speed information to the users, either to allow them to choose the most
> suitable network to connect to as well as (After having got connected) to
> show the current link speed. Unfortunately, this is something not provided by
> ConnMan yet.
the link speed or to be more precise the actual data rate is something that is
constantly changing and not really of massive use.
> Looking at the information we have inside ConnMan to implement such a
> feature, we found that we already have everything to do this. First of all,
> wpa_supplicant provides the list of BSS supported rates from which we could
> know if a BSS supports "b", "g" or "a", to distinguish between "g" or "a" we
> can just check the band for dual-band APs cases.
You do realize that dual-band (2.4 GHz and 5 GHz) APs are not a single BSS.
They are two BSS. They are actually two radios. One in 2.4 GHz and the other in
5 GHz and a switch from one to the other is actually roaming. So the use case
of detecting dual-band APs is mood. The two radios might be in the same casing,
but it would make no different if they are two cases standing next to each
other. And ConnMan would not be able to tell the difference.
> After that, the only missing information is to know whether "n" and "ac" are
> also supported, to do that we could take advantage of the IEs provided by the
> wpa_supplicant, there we just would have to check the presence of the VHT and
> HT capabilities.
> Finally, by combining information from BSSs using the same SSID we would be
> able to provide speed information supported by each service: "a", "b", "g",
> "n" and "ac".
The main question is what are you going to do with it. Since the provided
information during scanning are just pure informational. They have nothing to
do with the actual data rate that link operates in. And that can change any
time and normally it does. Any interference can trigger a change in data rate.
Unless the kernel is able to inform us about changes and wpa_supplicant
providing them in an asynchronous /event based fashion to ConnMan, there is no
point in exposing them. We can not poll wpa_supplicant for updates.
So I think first of all, link rate changes need to be propagated from the
kernel before we consider adding speed information to ConnMan.
Regards
Marcel
------------------------------
Message: 4
Date: Sat, 27 Aug 2016 07:25:05 -0700
From: Marcel Holtmann <[email protected]>
To: "Moberg, Patrik" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: /etc/resolv.conf disable overwrite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi Patrik,
> Is there anyway to tell Connman not to overwrite /etc/resolv.conf in version
> 1.33?
>
> I am starting Connman with --nodnsproxy.
what would be the use case here? /etc/resolv.conf is part of the networking
configuration. ConnMan needs to update it.
Regards
Marcel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 10, Issue 35
***************************************
