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: Search domain persistence (Patrik Flykt)
2. RE: API to get List of Connected STA's to an AP's
(Lamsoge, Abhijit)
3. Re: connman-vpnd does not reconnect after resume (Vasiliy Tolstov)
4. Re: R: [RFC] Wi-Fi Protected Setup (WPS) connection (Patrik Flykt)
5. Re: [PATCH] PacRunner:Domains are looked up to match the host
(Atul Anand)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Jun 2016 14:12:04 +0300
From: Patrik Flykt <[email protected]>
To: Sven Schwedas <[email protected]>, [email protected]
Subject: Re: Search domain persistence
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-06-03 at 17:08 +0200, Sven Schwedas wrote:
> On 1.32 (possibly also older versions, haven't checked) I'm seeing an
> annoying problem: Search domains persist across networks and reboots
> and DHCP search domains of the currently active network are only
> appended. After roaming between a few networks, this creates an
> absolute mess of an /etc/resolv.conf. Is this intended behaviour? How
> can I disable this if so?
You must be running connmand with --nodnsproxy, right? The intended
behavior is that without dnsproxy only the current search domain gets
written into /etc/resolv.conf, so this behavior must be a bug.
This is 1.32 from upstream, i.e. not packaged by a distro? Can you list
the search domains (Domains and?Domains.Configuration from connmanctl
services XXXX) for each service and the resulting /etc/resolv.conf when
you move between networks?
Cheers,
Patrik
------------------------------
Message: 2
Date: Fri, 10 Jun 2016 11:25:53 +0000
From: "Lamsoge, Abhijit" <[email protected]>
To: Patrik Flykt <[email protected]>, "[email protected]"
<[email protected]>
Subject: RE: API to get List of Connected STA's to an AP's
Message-ID:
<3261e8fc74193743a7498db5c1deb85ebd3d5...@hikawsexmb01.ad.harman.com>
Content-Type: text/plain; charset="us-ascii"
________________________________________
From: Patrik Flykt [[email protected]]
Sent: Friday, June 10, 2016 4:36 PM
To: Lamsoge, Abhijit; [email protected]
Subject: Re: API to get List of Connected STA's to an AP's
On Thu, 2016-06-09 at 12:42 +0000, Lamsoge, Abhijit wrote:
> Hi Patrick/All,
>
> I have a few queries after long time.
>
> 1) Does connman support list of connected station/client to AP?
> No.
> 2) If yes, how we can access list of connected station ?
> 3) If no, then how/where we can implement this feature?
> Good question.
> I think it's quiet an important feature if it is not supported in
> connman.
> What is the planned use case for this?
-- we intend to get the connected devices to our AP on the system where connman
is running.
The actual use case for this, is to update on the UX, at runtime the latest
list of users connected to it's AP, as it keeps getting modified all the time.
For Ex. Like a Router's webpage, needs to show STA's connected to it.
Abhijit
------------------------------
Message: 3
Date: Fri, 10 Jun 2016 14:50:55 +0300
From: Vasiliy Tolstov <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: connman <[email protected]>, Daniel Wagner <[email protected]>
Subject: Re: connman-vpnd does not reconnect after resume
Message-ID:
<cacaajqvidnm96jc+0kksgcmv_imany6vi42i4xayrdccjja...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2016-06-10 12:07 GMT+03:00 Patrik Flykt <[email protected]>:
> Due to unknown reasons this can happen, and I have seen it sometimes in
> the past with openconnect. Does a reconnect solve your problem in all
> cases?
Yes. Mostly after resume i need only connmanctl connect XXXX
> If yes, there is something going on between the VPN daemon and
> connman-vpnd that doesn't properly work or convey the state(s) the VPN
> daemon is in. Which needs more investigation, of course.
--
Vasiliy Tolstov,
e-mail: [email protected]
------------------------------
Message: 4
Date: Fri, 10 Jun 2016 14:53:48 +0300
From: Patrik Flykt <[email protected]>
To: Tomasz Bursztyka <[email protected]>, "MANIEZZO
Marco (MM)" <[email protected]>,
"[email protected]" <[email protected]>
Cc: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
Subject: Re: R: [RFC] Wi-Fi Protected Setup (WPS) connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi Marco,
On Thu, 2016-06-09 at 16:07 +0200, Tomasz Bursztyka wrote:
> Hi Marco,
>
> > Thank you very much for your feedback. For this proposal we based
> > on this assumption: we are talking about DBUS interfaces, these are
> > not directly the interface the end user will need to understand, in
> > between there must be and application for shell/graphical UI =>
> > here the developer may not be a WiFi expert, so we put all the
> > parameters of StartWPS and CancelWPS optional (except
> > authentication), and connman will try to figure out an automatic
> > behavior => this already goes in the direction you proposed
> > ?
> > On the other hand the automatic behavior may not suit all cases and
> > an expert developer may know how to manage several WiFi interfaces
> > (in our case three, STA, P2P and AP) => in this case the optional
> > parameters can come in handy.
> > ?
> > ?Ifname" : optional, meaning it can be empty, but with it we don?t
> > need other methods when the UI needs to choose between STA-WPS or
> > AP-WPS, or there is a P2P interface that can be used also as an
> > alternative STA or AP with WPS
> ?
> Still, ConnMan never uses ifnames as an entry point for a decision.
> Actually, the only place where you will see an interface name is in
> the description of a Service entry (Ethernet dict attribute).
> This is enforced, you can't change that rule :) we don't want users
> or UI code to mess up with interfaces directly.
>
> Make it work for 1 device first.?
> For P2P, you could use an alternate method called "Pair()" maybe. The
> role is decided during pairing anyway (if I remember well? this is so
> far away...).
>
> Let's see how to solve that for 2+ device later.
> (devices could be ordered by their support: the device which supports
> more technologies would be the first, etc...
> ConnMan would loop on them, each time StartWPS() - or Pair if
> supported - failed. Just a quick idea.)
I suppose this will be used after setting 'Tethering' true for a
technology. I think ConnMan can pick up a/the tethering WiFi device
which supports WPS once WPS is requested. Then no ifname is needed.
The P2P and STA only interfaces should be identifiable, there exists
code that does try to figure out AP support when tethering (see
e.g.?452fa8db3eb7e88fe93c93569f21884697f2d2c6 and where it ended up
after?db79090b895f23544d54abbf230efadbae9ec13b).
> > "Type" and "Pin" you are proposing to have only one parameter
> > ?authentication? but when the device with connman is enrollee it
> > must show a PIN to the user, not receive one: then we need to have
> > two parameters (Type, PIN)
> ?
> We never supported the registrar side on current WPS support in
> ConnMan (as far as I remember at least).
> So if the Agent is requesting about WPS, up to the UI to provide a
> PIN the user would use if user wants to use PIN method.
For the AP case an empty PIN should once again mean "pushbutton", while
a PIN with a value is, well, a pin.
> > like we propose, or if you prefer only one (Authentication) it must
> > be parsed in the following way:
> > -????????? A string like ?PIN? which means the connman must provide
> > a PIN to the GUI so that the user can enter it in the other device
> > (normally the AP)
> > -????????? A string containing a number like ?12345678? which means
> > this is the PIN to be used
> > -????????? Empty: means use PBC
The pin needs to be set beforehand, there are no Agent method calls to
be done for this. And after setting a pin that same entity can
call?StartWPS to get the procedure into a running state.
> > ?role? ? optional, meaning it can be empty, but while for the STA I
> > agree with you it mostly is an enrollee, the AP is a more
> > complicated system; why not offer the possibility to the developer
> > to choose the role if he wants (or if he needs)?
> ?
> AP mode in ConnMan is a very simplistic one. Actually, wpa_s does not
> provide much feature there as well (compared to hostapd).
> You could stick with registrar and that's it.
>
> If you want to differentiate, you could add a configuration entry in
> main.conf (like APWPSMode=<registrar/enrollee> ? registrar would be
> default)
> Less stuff to expose through DBus at least.? I would be surprised
> people really care about such option anyway.
Setting the precise role seems to be unnecessary for now. It can be
added once there is evidence that it won't work without. I'm not sure
anybody can master more than a pin and calling start and stop here :-)
> Hope it clarifies things.
I hope my comments do so too.
Cheers,
Patrik
------------------------------
Message: 5
Date: Fri, 10 Jun 2016 21:49:22 +0530
From: Atul Anand <[email protected]>
To: David Woodhouse <[email protected]>
Cc: Tomasz Bursztyka <[email protected]>,
[email protected]
Subject: Re: [PATCH] PacRunner:Domains are looked up to match the host
Message-ID:
<CABYWKtkLvpLnuXrY_BZ=kst06j4c_or2ckzzvsszhfechst...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Looks ok now? char limit has been considered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Pacrunner-Domains-are-looked-up-to-match-host-of-URL.patch
Type: text/x-patch
Size: 15597 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20160610/68f8da4b/attachment.patch>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 8, Issue 13
**************************************
