Shill moved to android.googlesource.com, where to add WiFi P2P support?

[Aleksandar]

Hello,

As part of work on Miracast support for Chromium OS (chrome.displaySource API - Issue 242107) I'm implementing WiFi P2P discovery and provisioning support.

Apart from wpa_supplicant build configuration change (p2p), code changes went to

- shill,

- system_api,

- chromium's (chromeos/network, chromeos/dbus and extensions)

and oneliner in libbrillo.

Noticed that shill is for some time (it was in chromium.googlesource.com last year, I think) in android.googlesource.com (https://android.googlesource.com/platform/system/connectivity/shill).

AFAIK there is WiFi P2P support in Android already (not in Shill though) and if I continue adding WiFi P2P support to Shill, even it is under CrOS Miracast build time flag, it still looks,.. well, like worth clarifying.

I don't know why is Shill in android.googlesource.com. Regardless, 

1) should I put the support for WiFi P2P to Shill, or

2) create another process for CrOS that would handle WiFi P2P discovery and provisioning (launching dnsmasq process needed too).

Maybe, WiFi P2P is already under work for CrOS?

Hope you could advise me about this.

Thanks. Kind Regards,

Aleksandar

[ggg]

On Tuesday, February 23, 2016 at 3:38:30 PM UTC-8, Aleksandar wrote:

Hello,

As part of work on Miracast support for Chromium OS (chrome.displaySource API - Issue 242107) I'm implementing WiFi P2P discovery and provisioning support.

Apart from wpa_supplicant build configuration change (p2p),

FYI: wpa_supplicant ebuild is soon moving to a local git build (vs current tarball+patches). Any changes to the current version (based on hostap_2_3) will need to be reapplied to hostap_2_5 based code (which is already in-tree but needs more patches).

You can see current pending changes (WIP) with the following steps:

cd ~/src/third_party/chromiumos-overlay/

git fetch https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay refs/changes/81/323381/13 && git checkout FETCH_HEAD

cd ~/trunk/src/third_party/wpa_supplicant/

git fetch https://chromium.googlesource.com/chromiumos/third_party/hostap refs/changes/56/329056/1 && git checkout FETCH_HEAD

But as noted above, this is work-in-progress and a few details will change.

cheers,

grant

[Christopher Wiley]

Changes you wish to see in shill/libbrillo/other AOSP hosted repositories need to be submitted to android.googlesource.com.  Then you or someone on the chrome os team need to pull down those changes via an ebuild uprev for all effected packages.

I can't speak for your architectural questions.

wiley

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Paul Stewart]

WRT the architectural questions: feel free to provide the changes you have as a CL to AOSP in the manner that Christopher just mentioned.  I'll warn you that as originally envisioned, shill was only meant for client connectivity.  A separate process was created for AP functionality (apmanager), and logically, I'd assume that the same sort of model would be followed for P2P.

[Stojiljkovic, Aleksandar]

Hello,
There is an implementation idea I thought to run by you before prototyping.
Would it be OK not to implementing AOSP daemon for P2P and that chromium browser directly interacts with wpa_supplicant (and dnsmasq for dhcp)?

I would guess that there are security concerns to address but from the use case point of view it would be fine - P2P for WiFi Display (provisioning and connect) is only needed during current browser session (from that point of view there is no need to have it in AOSP daemon).

Thanks. Kind Regards,
Aleksandar

________________________________________
From: chromiu...@chromium.org [chromiu...@chromium.org]
Sent: Wednesday, February 24, 2016 8:45 PM
To: Christopher Wiley
Cc: ggg; Chromium OS dev; Peter Qiu; Samuel Tan
Subject: Re: [cros-dev] Re: Shill moved to android.googlesource.com, where to add WiFi P2P support?

WRT the architectural questions: feel free to provide the changes you have as a CL to AOSP in the manner that Christopher just mentioned. I'll warn you that as originally envisioned, shill was only meant for client connectivity. A separate process was created for AP functionality (apmanager), and logically, I'd assume that the same sort of model would be followed for P2P.

[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

On Wed, Feb 24, 2016 at 10:34 AM, 'Christopher Wiley' via Chromium OS dev <chromiu...@chromium.org<mailto:chromiu...@chromium.org>> wrote:
Changes you wish to see in shill/libbrillo/other AOSP hosted repositories need to be submitted to android.googlesource.com<http://android.googlesource.com>. Then you or someone on the chrome os team need to pull down those changes via an ebuild uprev for all effected packages.

I can't speak for your architectural questions.

wiley

On Wed, Feb 24, 2016 at 10:20 AM ggg <grun...@chromium.org<mailto:grun...@chromium.org>> wrote:


On Tuesday, February 23, 2016 at 3:38:30 PM UTC-8, Aleksandar wrote:
Hello,
As part of work on Miracast support for Chromium OS (chrome.displaySource API - Issue 242107) I'm implementing WiFi P2P discovery and provisioning support.
Apart from wpa_supplicant build configuration change (p2p),

FYI: wpa_supplicant ebuild is soon moving to a local git build (vs current tarball+patches). Any changes to the current version (based on hostap_2_3) will need to be reapplied to hostap_2_5 based code (which is already in-tree but needs more patches).

You can see current pending changes (WIP) with the following steps:

cd ~/src/third_party/chromiumos-overlay/
git fetch https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay refs/changes/81/323381/13 && git checkout FETCH_HEAD

cd ~/trunk/src/third_party/wpa_supplicant/
git fetch https://chromium.googlesource.com/chromiumos/third_party/hostap refs/changes/56/329056/1 && git checkout FETCH_HEAD

But as noted above, this is work-in-progress and a few details will change.

cheers,
grant

--
--

Chromium OS Developers mailing list: chromiu...@chromium.org<mailto:chromiu...@chromium.org>

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org<mailto:chromium-os-d...@chromium.org>.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org<mailto:chromiu...@chromium.org>

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org<mailto:chromium-os-d...@chromium.org>.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---

You received this message because you are subscribed to a topic in the Google Groups "Chromium OS dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-os-dev/4mDgID9FbUU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-os-d...@chromium.org<mailto:chromium-os-d...@chromium.org>.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Paul Stewart]

Why write it in AOSP? Android has it's own p2p implementation and
Brillo doesn't have that on its roadmap. You could just create a
daemon within the Chrome OS code base.

[Stojiljkovic, Aleksandar]

Hello,
Sorry, I could reformulate this question. After the discussion in this thread, it is clear that the daemon shouldn't be in android.googlesource.com.

However, with respect to browser and wpa_supplicant, the daemon would be on the same layer as APManager and shill (so I used AOSP, though not having the intention to contribute it to android.googlesource.com).

My question is about not writing the daemon at all - to put whole logic in browser under WiFi Display extension. so that chromium browser directly interacts with wpa_supplicant (and dnsmasq for dhcp).

Thanks. Kind Regards,
Aleksandar
________________________________________

From: Paul Stewart [ps...@google.com]
Sent: Thursday, March 10, 2016 11:16 PM
To: Stojiljkovic, Aleksandar
Cc: Christopher Wiley; ggg; Chromium OS dev; Peter Qiu; Samuel Tan

[Grant Grundler]

On Thu, Mar 10, 2016 at 1:32 PM, Stojiljkovic, Aleksandar <aleksandar....@intel.com> wrote:

...

My question is about not writing the daemon at all - to put whole logic in browser under WiFi Display extension. so that chromium browser directly interacts with wpa_supplicant (and dnsmasq for dhcp).

So all the portal capture, mesh networking (client steering), and other misc behaviors can be re-discovered and re-implemented?

One advantage of consolidating to one implementation for many different types of clients is the "ecosystem" those clients live in "learns" how to deal with the clients as well. Implementing a new client throws out not only the experience integrated into current implementations (of shill for example) AND forces the ecoesystem to learn yet-another-client-behavior set.

While this sounds like an argument FOR putting it all in Chrome, Chrome isn't always running and the WiFi is. To add an extension that monitors the Wifi/Connection state sounds reasonable. Replacing the connection management doesn't.

You can proceed as you see fit. But my impression is the bar is pretty high to justify forking (ie replacing) a new shill or apmanager implementation.

If the problem you are trying to solve is more valuable than the "cost" of forking, I expect people currently working on ChromiomOS and Android would be interested in hearing more about it. Have a more detailed description of the problem you are trying to solve?

cheers,

grant