Hi Jose and Daniel,
My 2 cents below,
On Tue, Jan 3, 2017 at 6:02 PM, Daniel Wagner <wagi(a)monom.org> wrote:
>> 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.
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.
>> We have a similar scenario here, we have one single Marvell
>> 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 :(.
> Agreed, that is really sad. I am not against supporting more complex stuff.
> We just need to be very careful not to clutter the D-Bus APIs.
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.
> So if I understood you correctly, one major problem is that the device
> picked for AP is depending on the order of scanning results. Well,
> that is indeed a bit funky.
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's indeed what our chipset provider (RT) does: they recommend wlan1 for AP.
that would be indeed one of the main reasons one would want to
device to be used for Tethering.
> I wonder if it would be possible to 'annotate' via the config files
> which device is used for tethering. This is just a quick and dirty
> $ cat /var/lib/connman/example.config
> Type = wifi
> MAC = 01:02:03:04:05:06
> Tethering = enabled
> Type = wifi
> MAC = 01:02:03:04:05:07
> Tethering = disabled
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.
> Instead handling the config information via the ConnMan core, the wifi
> plugin could itself look for a config file. We have this also done for
> the session plugin. It looks for a config itself.
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?
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
Best regards, Matthijs