On 18-09-14 11:59, Patrik Flykt wrote:
Hi,
On Thu, 2014-09-18 at 09:27 +0200, Olliver Schinagl wrote:
One thing I have not been able to figure out yet however, if connman is
able to do a wifi scan while it is also running as accesspoint.
This depends basically on wpa_supplicant and/or the WiFi device driver.
If both of them are capable of scanning while doing their AP duties,
scan results will be received. Then again I'm not in the clear which use
case would demand such behavior as WiFi tethering should be run as long
as the user in the other end of the D-Bus connection wants to do that.
So suddenly switching tethering off in favor of connecting to a WiFi
network is perhaps not the best possible use case here. If this is
wanted, the proper way is to disable tethering and then (auto)connect.
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.
We did run some tests using hostapd and it seemed to work just fine, as
hostapd created a monitor device in addition to the regular wlan device.
I do see connman create a monitoring device, mon.wlan0, so scanning the
wifi while being an accesspoint shouldn't be a problem?
It may very well be a problem, as wpa_supplicant is used also for
tethering. Although coming from the same code base, wpa_supplicant
implements a subset of the functionality provided by hostapd, so I'm not
surprised that scanning works differently in both.
And running both hostapd and wpa_supplicant is a no go, as both of them
want to control the very same hardware. In addition, having ConnMan to
enable/disable them at run time is not something that can be done, as
ConnMan can be started with only enough permissions to get its stuff
done without any capabilities or even knowledge of how to stop/start
other services in the device in question.
Bringing up an accesspoint via tether works well enough.
connmanctl enable wifi
connmanctl tether wifi on testssid testpassphrase
Here the tether bridge, mon.wlan0 are all brought up.
I suspect the mon.wlan0 device is related to the monitor command?
Anyway, doing a scan wifi, the scan seems to wait for a bit, and then
returns with the following:
connmanctl scan wifi
Error /net/connman/technology/wifi: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the message
bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken.
Running connmand in the foreground with debugging yields the following
when starting the scan:
connmand[245]: src/technology.c:scan() technology 0x1cadba0 request from
:1.7
connmand[245]: plugins/wifi.c:wifi_scan() device 0x1caa1c0 wifi
0x1cac998 hidden ssid (null)
Is this a driver bug for the wifi device? (ath9k_htc) or a
bug/limitation of connman? We're using the git version of connman at
this moment.
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?
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.
Thanks for your time and help for now!
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
