On 02/03/2017 10:57 AM, Saurav Babu wrote:
> On 01/11/2017 02:04 PM, Patrik Flykt wrote:
>> On Wed, 2017-01-11 at 16:43 +0530, Saurav Babu wrote:
>>> There are few applications which require Wi-Fi specific informations
>>> like MAC Address, Frequency/Channel of AP. Is there any specific
>>> reason that these informations are not stored by connman?
> Can you elaborate a bit on your use case? I'd like to understand why you
> want that information. One thing which comes to my mind is that you want
> to show it to the user.
For WPS PBC and PIN connection wpa_supplicant allows BSSID to be passed as
argument. If BSSID is passed as argument to WPS Connection and any other device
tries to use PBC then negotiation is rejected by wpa_supplicant.
And the wifi plugin doesn't set the BSSID when doing WPS? If so, is that
something ConnMan can't figure out itself? I tried to understand what
happens in the supplicant.c file but well... hard to read.
Currently ConnMan doesn't provide any way to perform channel
based scan. It
always performs full channel scan which takes more time compared to single
channel scan. With knowledge of frequency application can decide to trigger
full channel or channel based scan for greater authority in connection
Instead a global scan you just want to scan for a service, is this correct?
And if I am get that right we would need to change the
net.connman.Technologly.Scan() API in the end. The Technology API has a
generic API without any device specific parts in. So adding there some
sort of channel information etc is breaking this. That would be a sad
thing to do :(
The only thing I can see is to pass in the Service D-Bus object path, e.g.
In this case you wouldn't even need to expose the channel and frequency
information because we could do the booking keeping inside ConnMan.