Hi Matthijs, As Daniel said, through Technology API you will not be able to specify exactly which device will be used for Tethering. However, when you enable Tethering on WiFi Technology, only one selected device will actually go in AP mode. That selection is done by an algorithm on WiFi plugin which is based on reported (By the driver) and detected (By ConnMan/wpa_supplicant) AP mode capabilities. Therefore, if your driver reports to wpa_supplicant that wlan0 only supports STA and wlan1 supports STA and AP mode then ConnMan will always use wlan1 for tethering. Then, your next scan will only return results coming from wlan0, which is what I understood you want. On the contrary, if both devices report AP mode capabilities, then ConnMan will use the first device it has on memory and unfortunately this is not under control. ConnMan's idea is to hide lower level things like actual interfaces. I partially agree, this approach aims to keep things simple but unfortunately it harms complex systems with more than one device per Technology where we would like to have control over which role they will play. This does not only affect Tethering, we found the same problem on the RFC we have been working on for WPS connections. We have a similar scenario here, we have one single Marvell WiFi chipset which exposes three devices and we are currently using ConnMan to manage STA, AP and P2P connections in parallel. However, even though Marvell produces WiFi chipset used by WFA for testing, the driver does not perfectly report devices' capabilities. Therefore, I think we should start thinking on some solution for these kind of complex systems. I hope that maintainers also start considering this because, for example, sometimes we have had to hard-code interface names and that's really sad :(. Regards, Jose Blanquicet

Hi Daniel, On Tue, Jan 3, 2017 at 6:02 PM, Daniel Wagner <wagi(a)monom.org&gt; wrote: OK, actually our initial idea would be to insert some kind of "intelligence" inside ConnMan in order to make it select the most suitable device for enabling Tethering based on current devices state. Doing so, D-Bus APIs would not be affected at all. Not exactly the order of the scanning but the order on which devices were created in WiFi plugin and then stored into devices list (iface_list). The reason is that when Tethering is trying to be enabled, WiFi plugin moves across iface_list looking for the first device which supports AP mode based on the algorithm I mentioned in the previous email. Therefore, if both devices support AP then the first on iface_list will be picked. I would like to clarify something, most of WiFi chipset providers guarantee a certain performance and simultaneous role support if devices are used in specific roles. Then, in cases like Matthijs's, it would not be actually incorrect if driver reports that both devices support AP mode. But let's consider Matthijs's provider guarantees best performance when wlan1 is used as AP, that would be indeed one of the main reasons one would want to specify the device to be used for Tethering. Well, for a static configuration where WiFi devices have the same capabilities, your proposal would indeed solve the issue. But what about different capabilities? Let's consider a system with two WiFi devices (wlan0, wlan1) where any simultaneous role is guarantee by WiFi chipset provider (Of course, according to each device capabilities), e.g. STA||AP, STA||P2P, AP||P2P, and so on. Therefore, you are requested to provide any of those combinations at any time. Consider the following devices capabilities: - wlan0 supports STA and AP mode. - wlan1 supports STA, AP and P2P mode. In such a scenario, what would one put in the Tether config file? Maybe disabled Tethering for wlan0 in order to use it only as STA could be an option but then if user first enables Tethering, ConnMan will use wlan1 and then you cannot provide P2P connections anymore because wlan1 is busy. If instead, you let both devices as enabled in Tether config file, then ConnMan could have wlan1 before wlan0 in iface_list thus it will always use wlan1 when user enables Tethering and again we have the same problem as before; we are not able to provide P2P and AP simultaneously if user enables Tethering before establishing a P2P connection. In order to avoid the restriction described above, I would suggest to add a certain kind of priority to STA/AP devices over STA/AP/P2P devices. Doing so, in previous example, one should let both devices as enabled in Tether config file and then ConnMan will consider STA/AP devices always before trying to use STA/AP/P2P ones and such a restriction is gone; after user enabled Tethering we can still provide P2P connections. What do others think? Suggestions/Comments? Regards, Jose Blanquicet

Hi Jose and Daniel, My 2 cents below, The other day when sending the initial email of this thread, the reason for me to started looking at Connman for the AP was that we already use it for the rest of the networking. But now that I know that Connman doesn't do it, there is no problem in getting the feature implemented with hostapd and dnsmasq. So, a question someone perhaps needs to answer before going all too deep into this, is if it is really for ConnMan to manage such complex systems? Looking at our device, the AP setup is so static that I don't see the benefit in using Connman. Over the hostapd + dnsmasq alternative I mean. While for the internet going connections, the `normal` Ethernet and/or Wifi STA, ConnMan does offer a benefit. And, for us, I much prefer ConnMan development to focus on stability, providing for a 101% reliable internet connection always. Over adding features like this that is. Perhaps it does become a bit more complex when there is only one wlan interface. Then we'd want it to be an AP when unconfigured, and have a user be able to configure its STA mode while connected to the AP. Just like for example Sonos seems to do. That's indeed what our chipset provider (RT) does: they recommend wlan1 for AP. Can it not work with interface names, ie. wlan0, wlan1? We are using embedded devices, and requiring mac addresses into the config file would mean sedding them in there are boot or something like that. Though I see the idea when wanting to use P2P as well, for our use case, the setup is best to be static. There is no need for priorities, and for example when debugging it's a lot easier to see what's going on when one knows by heart what wlan0 is used for, same for wlan1. Best regards, Matthijs