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: /etc/resolv.conf disable overwrite (Moberg, Patrik)
2. Re: [PATCH 2/3] src/proxy.c: modify the proxy_lookup ()
supporting non-browser schemes (David Woodhouse)
3. RE: Add speed information to services
(Blanquicet-Melendez Jose (MM))
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Aug 2016 07:25:54 +0000
From: "Moberg, Patrik" <[email protected]>
To: Miguel Bernal Marin <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: /etc/resolv.conf disable overwrite
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks.. I found the link creation under systemd tmpfiles.d as well and created
my own patch.
The use case is when you for security reasons always want to use the same DNS
server manually defined by the user/system.
Cheers,
Patrik Moberg
-----Original Message-----
From: Miguel Bernal Marin [mailto:[email protected]]
Sent: den 28 augusti 2016 17:31
To: Moberg, Patrik; [email protected]
Subject: Re: /etc/resolv.conf disable overwrite
> Is there anyway to tell Connman not to overwrite /etc/resolv.conf in
> version 1.33?
>
Connman uses systemd tmpfiles to overwrite /etc/resolv.conf, you can edit
/usr/lib/tmpfiles.d/connman_resolvconf.conf to avoid /etc/resolv.conf be
overwriten (remove +, on L+)
As others said connman needs to update resolv.conf, use this with cation.
Clear Linux uses this patch
https://github.com/clearlinux-pkgs/connman/blob/master/0001-create-resolv.conf-link-when-lauched.patch
but this is a particular case.
--
Regards,
Miguel Bernal Marin Open Source Technology Center
https://clearlinux.org Intel Corporation
------------------------------
Message: 2
Date: Mon, 29 Aug 2016 08:42:03 +0100
From: David Woodhouse <[email protected]>
To: Atul Anand <[email protected]>, [email protected]
Subject: Re: [PATCH 2/3] src/proxy.c: modify the proxy_lookup ()
supporting non-browser schemes
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Mon, 2016-08-22 at 10:54 +0100, David Woodhouse wrote:
> On Sun, 2016-08-21 at 21:44 +0530, Atul Anand wrote:
> > As discussed, the proxy lookup for browser and non browser schemes
> should
> > be handled in an order as follows:
> > A request for a "browser" protocol would match the following
> configs
> > order of preference (if they exist):
> > ?? Matching "Domains", BrowserOnly==TRUE
> > ?? Matching "Domains", BrowserOnly==FALSE
> > ?? Domains==NULL, BrowserOnly==TRUE
> > ?? Domains==NULL, BrowserOnly==FALSE
> >?
> > A request for a non-browser protocol would match the following:
> > ?? Matching "Domains", BrowserOnly==FALSE
> > ?? Domains==NULL, BrowserOnly==FALSE (except if a config exists
> with
> > ?? Matching "Domains", BrowserOnly==TRUE, in which case we need to
> > ?? return NULL).
> > ---
>
> This version looks much better; thanks.
Atul, you'll need to repost the series of three patches for Patrik to
pick up please.
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20160829/e5bb6b6f/attachment-0001.bin>
------------------------------
Message: 3
Date: Mon, 29 Aug 2016 08:14:26 +0000
From: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
To: Marcel Holtmann <[email protected]>
Cc: "[email protected]" <[email protected]>, "MANIEZZO Marco
(MM)" <[email protected]>
Subject: RE: Add speed information to services
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Marcel,
> > 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.
Please look at my last comment.
> > 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.
You are right, they are actually two BSS but both using the same SSID,
therefore both will belong to the same network; this is how wpa_supplicant
handles this situation and consequently also ConnMan. As a consequence, a
dual-band AP will be seen by ConnMan as a single network with two BSS, one on
2.4GHz and another on 5GHz; does not matter whether they are in the same casing
or not. Then, the idea would be to combine the capabilities of both BSS and
doing so the network (Service) will show both capabilities, for instance "a"
and "g". Is this what you mean? Or on the contrary what you mean is that
ConnMan will not be able to distinguish to which of the two BSS user wants to
connect to, "a" or "g" for instance. If it is what you mean, you are right, but
in any case this is not a very common case where the idea would be to leave
ConnMan makes the decision based on the strength as it has done so far. We
don't want to complicate the choice of the user by adding the desired band in
such a
case.
> > 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.
We agreed with you. In fact, we had already done the same analysis, the actual
data rate computation depends on too many variables (Some of them even
continually changing) and provide a trusty value is not so easy. That is the
reason why in the email I only mentioned IEEE standards "a", "b", "g", "n" and
"ac". I think I used the wrong word from the very beginning, the actual data
rate is not what we were thinking to provide to the user but the supported IEEE
standard.
> So I think first of all, link rate changes need to be propagated from the
> kernel before we consider adding speed information to ConnMan.
After having clarify what we would like to do, we just would like to add that
the scope of this modification is in the scan/connection phase, where by
providing this information the user can realize what would be the most suitable
network he/she should get connected by comparing the IEEE standards supported
by the available networks in range. Instead, providing the actual data rate
after user is already connected is not the scope.
Regards,
Jose Blanquicet
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE!
www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited.
If you have received this communication by mistake, please forward the message
back to the sender at the email address above, delete the message from all
mailboxes and any other electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or
error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 10, Issue 38
***************************************
