On 18-09-14 13:46, Patrik Flykt wrote:
Hi,
On Thu, 2014-09-18 at 12:24 +0200, Olliver Schinagl wrote:
Well our specific use-case is, that a device is in 'listening' mode as
an Accesspoint, a device connects to it (first use wizard like thing)
to setup the local network. The the app then via dbus tells connman to
stop tethering and be a regular wifi device. To do this however, a
result of the available networks is required. So yes, tethering is
'abused' to have an accesspoint. But as mentioned below, irrelevant.
That sounds like a decent solution to the problem. You were perhaps
trying to verify that the network exists while being an Access Point?
I'd assume that if the local network cannot be found or connected during
the first use wizard lookalike stage, the device should return to its
Access Point state whereby the setup step can be retried?
Yeah, we are going this route now, start in AP mode and every 30?
seconds do a quick scan for available AccessPoints and then return to AP
mode. Should be reliable eough I hope ;) The only exception is when we
do not want to connect to any network, but have the device just actually
be an AP so that wireless clients can directly connect.
Since hostapd and WiFi scanning was verified by you earlier in the mail,
the WiFi device driver has the proper capabilities to perform both of
the requested tasks at the same timne. It is thus wpa_supplicant that is
the roadblock here. It apparently does not have the capabilities of
scanning while in AP mode.
I'm not sure I follow 100%. wpa_supplicant is invoked/implemented via
gsupplicant, correct?
gsupplicant is an internal abstraction that tries to make the use of
wpa_supplicant easier. gsupplicant doesn't do any processing on the wifi
handling itself.
Anyway, scanning using iw dev wlan0 scan when hostapd is running fails
actually, so it looks like the hardware cannot do it anyway? I guess
openwrt does it by stopping AP mode, scan and restart AP mode quickly
enough so that the client doesn't disconnect.
I was actually wrong on this one. There are these two lines in
plugins/wifi.c:
if (wifi->tethering)
return 0;
So scanning via wpa_supplicant is not even attempted, thus I was a bit
quick saying that wpa_supplicant isn't supporting scanning while being
an access point. But as you noticed scanning failed in the end even with
hostapd. So no matter what wpa_supplicant does or does not do in this
case is irrelevant for the outcome.
Well then if the driver does start to support this, I guess we'll have
to work on a connmand patch too.
Thanks again for your time!
Olliver
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
--
Met vriendelijke groeten, Kind regards, 与亲切的问候
Olliver Schinagl
Research & Development
Ultimaker B.V.
http://www.ultimaker.com
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
