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: Propagate only property changes of the connected BSS
(Jose Blanquicet)
2. Re: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue (Daniel Wagner)
3. Re: How to start PacRunner ? Systemd vs dbus auto start
(Julien Massot)
4. Re: Using NTP To Set System Time (Daniel Wagner)
5. Re: How to start PacRunner ? Systemd vs dbus auto start
(Daniel Wagner)
6. Re: How to start PacRunner ? Systemd vs dbus auto start
(Julien Massot)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Jul 2017 06:48:09 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Propagate only property changes of the connected BSS
Message-ID:
<cafc8ijkrjq6r2lxf3cnkukdzry3wt8cx8onzbq+p1chmuhn...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Good morning Daniel,
On Thu, Jul 20, 2017 at 4:58 PM, Daniel Wagner <[email protected]> wrote:
>> Please read the commit message of the patch before this to get
>> contextualised.
>>
>> An additional reason behind this patch is to resume the discussion about the
>> supported IEEE standards 8021.11. Some time ago, we proposed the idea of add
>> a
>> new Service's property which provides information about the supported IEEE
>> std
>> 802.11 (a, b, g, n, ac, ...) by a WiFi network. At that time, Marcel exposed
>> the
>> reasons why he did not agree about the way we wanted to implement it. Now,
>> after
>> having got more experience on ConnMan we rebuild the idea but the aim of the
>> modification remains the same; we want to add this information in order to
>> provide to the user more precise information about the performances he could
>> achieve and ease him to decide which is the most suitable network, if he can
>> choose.
>>
>> To develop this proposal, we would like to follow what is done for the signal
>> strength, it means to update this new Service property with what the best
>> BSS of
>> the corresponding WiFi network supports. It would make complete sense
>> because at
>> the end, that would be the BSS to which we will connect. Therefore, each
>> time a
>> best BSS is updated because there is another with higher signal strength then
>> the supported IEEE standards will also be updated thus we will always show
>> reliable information.
>>
>> What do you think?
>
>
> I've read the commit message and also this here. It sounds quite reasonable
> to me. So I wondering what Marcel's arguments were. Do you happen to have a
> pointer for me so that I can find the mails?
Here the archives [1], I would say that the discussion did not start
so well because I initially used the wrong concept when I said "actual
data rate"; that's not what we actually want to do because such
computation depends on too many variables, some of them even
continually changing as we said at that time. Now, it is clear that
what we want is to show the IEEE standards 8021.11: a, b, g, n, ac.
In addition, at that time we wanted to merge the capabilities of all
the BSSs belonging to a WiFi network. Now instead, we want to follow
the implementation done by the signal strength property thus to show
the capabilities of the best BSS of such WiFi network.
I hope it is now much more clear and we could agree in a way to
develop it. We are open to any suggestion and comment.
[1] https://lists.01.org/pipermail/connman/2016-August/000960.html
> I'll give the patch some testing :)
Thanks,
Jose Blanquicet
------------------------------
Message: 2
Date: Fri, 21 Jul 2017 09:31:50 +0200
From: Daniel Wagner <[email protected]>
To: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi,
The first thing I noticed, is that we do not extract the DNS settings
correctly. oFono sends 10.105.16.254 and 10.105.144.254. I starred at
the oFono code base and also at ConnMan and I don't see what's going
wrong.
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb()
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() APN:
internetd.gdsp
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() PDP type 0
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() IP addr:
10.249.97.226
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() Gateway:
10.249.97.225
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() Gateway
netmask: 255.255.255.252
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() Primary DNS:
10.105.16.254
Jul 21 05:47:02 alen-iot-gateway ofonod[176]:
../ofono-1.20/drivers/qmimodem/gprs-context.c:get_settings_cb() Secondary DNS:
10.105.144.254
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Interface wwan0
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() index 6
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Method static
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Address 10.249.97.226
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Netmask 255.255.255.252
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Gateway 10.249.97.225
Jul 21 05:47:02 alen-iot-gateway connmand[175]:
../connman-1.34/plugins/ofono.c:extract_ipv4_settings() Nameservers
10.105.144.254 10.105.144.254
Could you add some printfs to the extract_nameservers() in
plugins/ofono.c? And you might also want to run
ofono/test/monitor-ofono so that you can see what oFono sends
to ConnMan.
Address: 10.249.97.226 00001010.11111001.01100001.111000 10
Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11
=>
Network: 10.249.97.224/30 00001010.11111001.01100001.111000 00 (Class A)
Broadcast: 10.249.97.227 00001010.11111001.01100001.111000 11
HostMin: 10.249.97.225 00001010.11111001.01100001.111000 01
HostMax: 10.249.97.226 00001010.11111001.01100001.111000 10
Hosts/Net: 2 (Private Internet)
Looking through the log, it looks like ConnMan does all the math
correctly.
One thing which looks inconsistent in your first report is:
ofono_start_gsm.sh[192]: Interface is wwan0
ofono_start_gsm.sh[192]: IP address is 10.249.29.20
ofono_start_gsm.sh[192]: Gateway is 10.249.29.21
ofono_start_gsm.sh[192]: Nameserver is 10.105.144.254
Destination Gateway Genmask Flags
Metric Ref Use Iface
0.0.0.0 10.166.199.10 0.0.0.0 UG 0
0 0 wwan0
10.105.144.254 10.166.199.10 255.255.255.255 UGH 0
0 0 wwan0
10.166.199.8 0.0.0.0 255.255.255.252 U 0
0 0 wwan0
10.166.199.10 0.0.0.0 255.255.255.255 UH 0
0 0 wwan0
The gateway should be 10.249.29.21 and not 10.166.199.10.
The next three lines are adding a host routing for the DNS
server and maybe timeserver. At least the first line
is the DNS server but again the gateway is wrong.
dhclient gets set a complete different gateway:
Destination Gateway Genmask Flags Metric
Ref Use Iface
0.0.0.0 10.166.250.1 0.0.0.0 UG 0
0 0 wwan0
10.166.250.0 0.0.0.0 255.255.255.240 U 0
0 0 wwan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0
0 0 eth0
192.168.1.255 0.0.0.0 255.255.255.255 UH 0
0 0 eth0
10.166.250.1 with a different netmask!
First thing I would do is to verify what the oFono modem is
doing. If that one extracts the wrong information and passes
that to ConnMan it would explain your problem. The
code in oFono is pretty new
475b789f3de9 ("qmi: retrieve GPRS context parameters")
Thanks,
Daniel
------------------------------
Message: 3
Date: Fri, 21 Jul 2017 09:34:15 +0200
From: Julien Massot <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: How to start PacRunner ? Systemd vs dbus auto start
Message-ID:
<CADGp=qeckiwxycqn1-+8jm+czajjbbpf0ngajctzadn2zr0...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, Jul 20, 2017 at 6:52 PM, Daniel Wagner <[email protected]> wrote:
> Hi Julien,
>
>
> On 06/21/2017 03:52 PM, Julien Massot wrote:
>>
>> Hi all,
>>
>> I'm currently integrating PacRunner,
>> but I don't see any recommended solution to start it.
>>
>> PACRunner ship a dbus autostart file in:
>> /usr/share/dbus-1/system-services/pacrunner.service
>> BTW the path is not correct, I will send a patch to have
>> "org.pacrunner.service".
>>
>> And PacRunner doesn't ship any systemd unit file, so my guess was that
>> ConnMan will start it through dbus if a proxy server is set manually, or
>> if wpad
>> discover a pac/wpad file.
>>
>> But ConnMan plugins doesn't call PacRunner if the daemon is not running,
>> and explicitely ask to not start the daemon.
>>
>>
>>
>> static void destroy_proxy_configuration(void)
>> ..
>> line 237: dbus_message_set_auto_start(msg, FALSE);
>>
>>
>> static void default_service_changed(struct connman_service *service)
>> ..
>> line 267: if (!daemon_running)
>> return;
>>
>> So from my point of view, shipping a systemd unit file is not the best
>> solution,
>> since starting pacrunner on boot is a waste of time.
>>
>> And ConnMan pacrunner plugin,
>> should try to autostart PacRunner if we connect to a network which
>> have a proxy configured or discovered.
>>
>> Last solution should be that on a first call of libproxy pacrunner
>> starts but it look like a bad solution since most likely connman will
>> not send the proxy
>> configuration yet.
I did some test and PACRunner starts on first call to libproxy or
pacrunner dbus API,
with dbus autostart.
And it seems to work, PACRunner get his configuration from connman,
before replying to the request.
>
>
> I haven't really a clue what the dependencies are. Isn't there already some
> integration in some distributions? At least we got some patches from distros
> on PacRunners. Maybe there are some pointers how it might work.
>
> Thanks,
> Daniel
--
*This email and any attachment thereto are confidential and intended solely
for the use of the individual or entity to whom they are addressed.If you
are not the intended recipient, please be advised that disclosing, copying,
distributing or taking any action in reliance on the contents of this email
is strictly prohibited. In such case, please immediately advise the sender,
and delete all copies and attachment from your system.This email shall not
be construed and is not tantamount to an offer, an acceptance of offer, or
an agreement by SoftBank Robotics Europe on any discussion or contractual
document whatsoever. No employee or agent is authorized to represent or
bind SoftBank Robotics Europe to third parties by email, or act on behalf
of SoftBank Robotics Europe by email, without express written confirmation
by SoftBank Robotics Europe? duly authorized representatives.*
------------------------------
*Ce message ?lectronique et ?ventuelles pi?ces jointes sont confidentiels,
et exclusivement destin?s ? la personne ou l'entit? ? qui ils sont
adress?s.Si vous n'?tes pas le destinataire vis?, vous ?tes pri? de ne pas
divulguer, copier, distribuer ou prendre toute d?cision sur la foi de ce
message ?lectronique. Merci d'en aviser imm?diatement l'exp?diteur et de
supprimer toutes les copies et ?ventuelles pi?ces jointes de votre
syst?me.Ce message ?lectronique n'?quivaut pas ? une offre, ? une
acceptation d?offre, ou ? un accord de SoftBank Robotics Europe sur toute
discussion ou document contractuel quel qu?il soit, et ne peut ?tre
interpr?t? comme tel. Aucun employ? ou agent de SoftBank Robotics Europe
n'est autoris? ? repr?senter ou ? engager la soci?t? par email, ou ? agir
au nom et pour le compte de la soci?t? par email, sans qu?une confirmation
?crite soit donn?e par le repr?sentant l?gal de SoftBank Robotics Europe ou
par toute autre personne ayant re?u d?l?gation de pouvoir appropri?e.*
------------------------------
Message: 4
Date: Fri, 21 Jul 2017 09:40:52 +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
Hi Jeff,
On 07/21/2017 05:21 AM, Jeff Gray wrote:
> Looking at the output, they are quite similar, so it is a mystery why
> it would not be working in connman. I have to consider that if ntp is
> working for others in connman, it might be something unusual about my
> embedded system. It is running an old 2.6.33 kernel, so maybe there is
> a subtle incompatibility.
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.
Thanks,
Daniel
------------------------------
Message: 5
Date: Fri, 21 Jul 2017 09:44:08 +0200
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: [email protected]
Subject: Re: How to start PacRunner ? Systemd vs dbus auto start
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 07/21/2017 09:34 AM, Julien Massot wrote:
> I did some test and PACRunner starts on first call to libproxy or
> pacrunner dbus API,
> with dbus autostart.
> And it seems to work, PACRunner get his configuration from connman,
> before replying to the request.
Sounds reasonably to me. This works after your patch from yesterday?
I would really appreciate if you could add to commit message when we
broke the autostart feature. That makes it much simpler for me to
understand why the patch is needed :)
Thanks,
Daniel
------------------------------
Message: 6
Date: Fri, 21 Jul 2017 10:00:00 +0200
From: Julien Massot <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: How to start PacRunner ? Systemd vs dbus auto start
Message-ID:
<CADGp=QfdD7xr4vN2zPY6XQxCkUBt52B=c576t+gf1nsl4er...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, Jul 21, 2017 at 9:44 AM, Daniel Wagner <[email protected]> wrote:
> On 07/21/2017 09:34 AM, Julien Massot wrote:
>>
>> I did some test and PACRunner starts on first call to libproxy or
>> pacrunner dbus API,
>> with dbus autostart.
>> And it seems to work, PACRunner get his configuration from connman,
>> before replying to the request.
>
>
> Sounds reasonably to me. This works after your patch from yesterday?
> I would really appreciate if you could add to commit message when we broke
> the autostart feature. That makes it much simpler for me to understand why
> the patch is needed :)
Yes exactly, the autostart fix is needed,
I'm not a dbus expert so either it's broken since the begining, with this commit
8fd30c02676ecdab0380b6bfe7f20317c2726234
or dbus is now more restrictive on service file name.
--
*This email and any attachment thereto are confidential and intended solely
for the use of the individual or entity to whom they are addressed.If you
are not the intended recipient, please be advised that disclosing, copying,
distributing or taking any action in reliance on the contents of this email
is strictly prohibited. In such case, please immediately advise the sender,
and delete all copies and attachment from your system.This email shall not
be construed and is not tantamount to an offer, an acceptance of offer, or
an agreement by SoftBank Robotics Europe on any discussion or contractual
document whatsoever. No employee or agent is authorized to represent or
bind SoftBank Robotics Europe to third parties by email, or act on behalf
of SoftBank Robotics Europe by email, without express written confirmation
by SoftBank Robotics Europe? duly authorized representatives.*
------------------------------
*Ce message ?lectronique et ?ventuelles pi?ces jointes sont confidentiels,
et exclusivement destin?s ? la personne ou l'entit? ? qui ils sont
adress?s.Si vous n'?tes pas le destinataire vis?, vous ?tes pri? de ne pas
divulguer, copier, distribuer ou prendre toute d?cision sur la foi de ce
message ?lectronique. Merci d'en aviser imm?diatement l'exp?diteur et de
supprimer toutes les copies et ?ventuelles pi?ces jointes de votre
syst?me.Ce message ?lectronique n'?quivaut pas ? une offre, ? une
acceptation d?offre, ou ? un accord de SoftBank Robotics Europe sur toute
discussion ou document contractuel quel qu?il soit, et ne peut ?tre
interpr?t? comme tel. Aucun employ? ou agent de SoftBank Robotics Europe
n'est autoris? ? repr?senter ou ? engager la soci?t? par email, ou ? agir
au nom et pour le compte de la soci?t? par email, sans qu?une confirmation
?crite soit donn?e par le repr?sentant l?gal de SoftBank Robotics Europe ou
par toute autre personne ayant re?u d?l?gation de pouvoir appropri?e.*
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 21, Issue 11
***************************************
