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: Using NTP To Set System Time (Jeff Gray)
2. Re: Using NTP To Set System Time (Daniel Wagner)
3. Re: miracast connections using connman disconnect after 30
mins (DHCP renewal problem?) (Daniel Wagner)
4. Re: [PATCH] Fix D-Bus autostart service file name (Daniel Wagner)
5. Re: [PATCH] plugins/pacrunner.c: do not configure our domains
(Daniel Wagner)
6. Re: [PATCH] plugins/pacrunner.c: do not configure our domains
(David Woodhouse)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Jul 2017 18:01:24 +1000
From: Jeff Gray <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Using NTP To Set System Time
Message-ID:
<CAHb0zt=0TgR=4h9xyavhauktptobzlag9dbvpme+a8m2ocj...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On 21 July 2017 at 17:40, Daniel Wagner <[email protected]> wrote:
> It could be that ntpd does behave slightly different when it is running on
> an older kernel. Maybe it uses a different set of flags? Just speculating
> here. If you have strace on your box you might see how adjtimex() is called.
strace shows that settimeofday is called instead. Busybox must be
using a #define adjtimex in some systems (the system detection code is
complex to support many different environments).
I checked the uclibc & kernel I am using both do support adjtimex. So
it _should_ work. This may be tricky to diagnose.
I could look at the code in Busybox & patch ntp.c to call settimeofday
as well. I know it's not as nice as adjtimex for NTP, but at least I
know it works.
------------------------------
Message: 2
Date: Fri, 21 Jul 2017 10:19:49 +0200
From: Daniel Wagner <[email protected]>
To: Jeff Gray <[email protected]>
Cc: [email protected]
Subject: Re: Using NTP To Set System Time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 07/21/2017 10:01 AM, Jeff Gray wrote:
> On 21 July 2017 at 17:40, Daniel Wagner <[email protected]> wrote:
>> It could be that ntpd does behave slightly different when it is running on
>> an older kernel. Maybe it uses a different set of flags? Just speculating
>> here. If you have strace on your box you might see how adjtimex() is called.
>
> strace shows that settimeofday is called instead. Busybox must be
> using a #define adjtimex in some systems (the system detection code is
> complex to support many different environments).
Ah, yes, busybox does a lot of 'interesting' quirks :)
> I checked the uclibc & kernel I am using both do support adjtimex. So
> it _should_ work. This may be tricky to diagnose.
And you might end up porting back patches for the kernel.
> I could look at the code in Busybox & patch ntp.c to call settimeofday
> as well. I know it's not as nice as adjtimex for NTP, but at least I
> know it works.
Indeed, this is the fastest way to get it going. Obviously, the question
is if the clock drifts and ConnMan wants to adjust it, is the other call
to adjtimex() working or not?
Thanks,
Daniel
------------------------------
Message: 3
Date: Fri, 21 Jul 2017 14:16:31 +0200
From: Daniel Wagner <[email protected]>
To: "Carl D. Blake" <[email protected]>, [email protected]
Subject: Re: miracast connections using connman disconnect after 30
mins (DHCP renewal problem?)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Carl,
On 07/21/2017 12:22 AM, Carl D. Blake wrote:
> I've been using connman in an application involving doing miracast
> connections. I've been using libwds and connman 1.34 as well as
> wpa_supplicant V2.6.
>
> I'm encountering a problem where I can establish a miracast connection
> with an android device, but after 30 mins. the entire connection drops.
> This is the messages I see when that happens:
>
> ---------------------------------------------
>
> Jul 14 22:54:48 cr-400-2ac2 wpa_supplicant[945]: wlan0: Failed to
> initiate sched scan
> Jul 14 23:17:01 cr-400-2ac2 CRON[1523]: (root) CMD ( cd / && run-parts
> --report /etc/cron.hourly)
> Jul 14 23:20:01 cr-400-2ac2 connmand[926]: Peer DHCP server: Received
> REQUEST NIP 0
> Jul 14 23:20:01 cr-400-2ac2 kernel: [ 1884.087547] DHCP - REQUEST [RX]
> Jul 14 23:20:03 cr-400-2ac2 kernel: [ 1886.228326] DHCP - REQUEST [RX]
> Jul 14 23:20:11 cr-400-2ac2 kernel: [ 1894.311831] DHCP - REQUEST [RX]
> Jul 14 23:20:28 cr-400-2ac2 kernel: [ 1911.745592] DHCP - REQUEST [RX]
> Jul 14 23:19:48 cr-400-2ac2 wpa_supplicant[945]: message repeated 5
> times: [ wlan0: Failed to initiate sched scan]
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: p2p-wlan0-1:
> AP-STA-DISCONNECTED b6:ef:39:39:5b:df p2p_dev_addr=b6:ef:39:39:db:df
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: AP-STA-DISCONNECTED
> b6:ef:39:39:5b:df p2p_dev_addr=b6:ef:39:39:db:df
> Jul 14 23:20:29 cr-400-2ac2 cpn: * Source unavailable
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: P2P-GROUP-REMOVED
> p2p-wlan0-1 GO reason=REQUESTED
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: p2p-wlan0-1: interface
> state ENABLED->DISABLED
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: p2p-wlan0-1:
> AP-DISABLED
> Jul 14 23:20:29 cr-400-2ac2 wpa_supplicant[945]: p2p-wlan0-1:
> CTRL-EVENT-DISCONNECTED bssid=02:04:4b:58:aa:c0 reason=3
> locally_generated=1
> Jul 14 23:20:28 cr-400-2ac2 connmand[926]: message repeated 3 times:
> [ Peer DHCP server: Received REQUEST NIP 0]
> Jul 14 23:20:29 cr-400-2ac2 connmand[926]: p2p-wlan0-1 {RX} 367084
> packets 399923565 bytes
> Jul 14 23:20:29 cr-400-2ac2 connmand[926]: p2p-wlan0-1 {TX} 156 packets
> 19838 bytes
> Jul 14 23:20:29 cr-400-2ac2 connmand[926]: p2p-wlan0-1 {update} flags
> 102403 <UP,LOWER_UP>
> Jul 14 23:20:29 cr-400-2ac2 connmand[926]: p2p-wlan0-1 {newlink} index
> 10 address 02:04:4B:58:AA:C0 mtu 1500
> Jul 14 23:20:29 cr-400-2ac2 connmand[926]: p2p-wlan0-1 {newlink} index
> 10 operstate 5
> Jul 14 23:20:29 cr-400-2ac2 connman-vpnd[940]: p2p-wlan0-1 {update}
> flags 102403 <UP,LOWER_UP>
> Jul 14 23:20:29 cr-400-2ac2 connman-vpnd[940]: p2p-wlan0-1 {newlink}
> index 10 address 02:04:4B:58:AA:C0 mtu 1500
> Jul 14 23:20:29 cr-400-2ac2 connman-vpnd[940]: p2p-wlan0-1 {newlink}
> index 10 operstate 5
> Jul 14 23:20:29 cr-400-2ac2 kernel: [ 1912.126009] [07-14 23:20:29.280]
> wl_notify_connect_status_ap: event WLC_E_DEAUTH_IND(6) status 0 reason 3
This is the out of tree module for Edison's bcm43340? Anyway, the reason
code says 3, which is according the spec (if my 802.11 spec reading foo
hasn't left me completely):
"Deauthenticated because sending STA is leaving (or has left)
IBSS or ESS"
Table 8-36.
> -----------------------------------------
>
> I originally thought it had something to do with miracast and asked this
> question at that site, but the people there thought it might be an issue
> with connman.
>
> It seems like there might be some issue with DHCP renewal. Does anybody
> know what's happening here?
It doesn't look like DHCP, because the wireless driver receives a
DEAUTH. Why this is happening? I have no clue. Maybe it is possible to
increase the verbosity of the driver and you might see what is going on.
Maybe ConnMan is also doing something wrong but I would first check if
the driver is behaving according the specification. If it is this
version I found on github[1] I wouldn't be surprised if there are still
bugs in it. Just one commit and no changes since 2015.
Thanks,
Daniel
[1] https://github.com/01org/edison-bcm43340
------------------------------
Message: 4
Date: Fri, 21 Jul 2017 15:05:39 +0200
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Fix D-Bus autostart service file name
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julien,
On 07/20/2017 09:11 AM, Julien Massot wrote:
> From: Julien Massot <[email protected]>
>
> Fix:
> dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.Spawn.ServiceNotFound: Bus name not found in
> system service directory
I've read up on this topic and you are correct. The D-Bus activation
file needs to be named properly.
"""
The service filename of "org.me.test.service" is then searched for in
/usr/share/dbus-1/system-services or other specified directories.
"""
https://dbus.freedesktop.org/doc/system-activation.txt
I'll add this to the commit message.
> ---
> Makefile.am | 2 +-
> configure.ac | 2 +-
> src/{pacrunner.service.in => org.pacrunner.service.in} | 0
> 3 files changed, 2 insertions(+), 2 deletions(-)
> rename src/{pacrunner.service.in => org.pacrunner.service.in} (100%)
>
> diff --git a/Makefile.am b/Makefile.am
> index dd231ef..a3f178c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -8,7 +8,7 @@ dbusconf_DATA = src/pacrunner.conf
>
> dbusdatadir = @DBUS_DATADIR@
>
> -dbusdata_DATA = src/pacrunner.service
> +dbusdata_DATA = src/org.pacrunner.service
> endif
>
> gdbus_sources = gdbus/gdbus.h gdbus/mainloop.c gdbus/watch.c \
> diff --git a/configure.ac b/configure.ac
> index c68adae..1577c86 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -150,4 +150,4 @@ AC_ARG_ENABLE(datafiles,
> AC_HELP_STRING([--disable-datafiles],
> [enable_datafiles=${enableval}])
> AM_CONDITIONAL(DATAFILES, test "${enable_datafiles}" != "no")
>
> -AC_OUTPUT(Makefile src/pacrunner.service libproxy/libproxy-1.0.pc)
> +AC_OUTPUT(Makefile src/org.pacrunner.service libproxy/libproxy-1.0.pc)
> diff --git a/src/pacrunner.service.in b/src/org.pacrunner.service.in
> similarity index 100%
> rename from src/pacrunner.service.in
> rename to src/org.pacrunner.service.in
>
------------------------------
Message: 5
Date: Fri, 21 Jul 2017 15:29:55 +0200
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] plugins/pacrunner.c: do not configure our domains
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Julien,
On 07/20/2017 09:09 AM, Julien Massot wrote:
> From: Julien Massot <[email protected]>
>
> My guess is that there is a confusion between our domains,
> and the proxy domains.
>
> The domain configured for the service have no link to the
> proxy domain.
>
> PacRunner says that array{string} Domains [optional]
>
> Domain names and IP range for which this proxy
> configuration shall be valid.
>
> So for example a proxy servers may be valid to access website
> under the domain example.com to be able to reply to request for
> url: http://www.example.com/site/test.html host: www.example.com
> but not for http://ipv4.connman.net/online/status.html ipv4.connman.net.
>
> Just remove this Domain parameter since we don't know for which
> domain the proxy server is relevant, assume it's for any domain.
I have a hard time following your explanations. Maybe you can elaborate
a bit.
Anyway, CreateProxyConfiguration is used to create a new proxy
configuration if I got the right. And we add method, domainname and
nameserver to proxy configuration. So why are method and nameserver okay
and the domainname for the default_service not? I am really confused.
Thanks,
Daniel
------------------------------
Message: 6
Date: Fri, 21 Jul 2017 15:40:24 +0200
From: David Woodhouse <[email protected]>
To: Daniel Wagner <[email protected]>, Julien Massot
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] plugins/pacrunner.c: do not configure our domains
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Fri, 2017-07-21 at 15:29 +0200, Daniel Wagner wrote:
> Hi Julien,
>
> On 07/20/2017 09:09 AM, Julien Massot wrote:
> >
> > From: Julien Massot <[email protected]>
> >
> > My guess is that there is a confusion between our domains,
> > and the proxy domains.
> >
> > The domain configured for the service have no link to the
> > proxy domain.
> >
> > PacRunner says that? array{string} Domains [optional]
> >
> > Domain names and IP range for which this proxy
> > configuration shall be valid.
> >
> > So for example a proxy servers may be valid to access website
> > under the domain example.com to be able to reply to request for
> > url: http://www.example.com/site/test.html host: www.example.com
> > but not for http://ipv4.connman.net/online/status.html ipv4.connman.net.
> >
> > Just remove this Domain parameter since we don't know for which
> > domain the proxy server is relevant, assume it's for any domain.
> I have a hard time following your explanations. Maybe you can elaborate?
> a bit.
>
> Anyway, CreateProxyConfiguration is used to create a new proxy?
> configuration if I got the right. And we add method, domainname and?
> nameserver to proxy configuration. So why are method and nameserver
> okay?and the domainname for the default_service not? I am really
> confused.
For a proxy configuration, the 'domains' list is a list of domains for
which this proxy shall be used.
If you configure a proxy for "example.com" then it will not be used for
requests outside that domain.
If you happen to be within the example.com network and you have
'example.com' as a default search domain ? and if that network has a
proxy configured ? that does NOT mean that you should only ever use the
proxy for requests within 'example.com'. Which is what this patch seems
to fix.
If you don't support split tunnelling, and you only ever support one
active network, you should basically *never* be configuring a domain
list in proxy configurations you give to PacRunner.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20170721/1482a666/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 21, Issue 12
***************************************
