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.
> 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.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
