Discussion:
Question: connman and wifi tethering on uAP Devices (e.g. Marvell SD8787)
Andreas Kaufmann
2013-11-25 16:00:40 UTC
Permalink
Hi all,

i have a question regarding connman functionality on uAP devices like
Marvell SD8787 and hopefully someone reading the list can point me into the
right direction. I'm currently trying to use connman in a project for an
embedded device based on the Xilinx Zynq Platform. Based on an Eval-Board
of this platform and a second Eval-Board with a Marvell SD8787 Wifi-chipset
i'm trying to get the access point / ethernet bridging up and running for
this combination. Both boards communicate with each other using a SDIO
interface.
From the software side i'm using a Yocto-Project based rootfs and linux
kernel v3.8 with modifications for the hardware described above. Kernel is
configured according to the connman README (CONFIG_BRIDGE,
CONFIG_IP_NF_TARGET_MASQUERADE, CONFIG_NETFILTER, CONFIG_NF_CONNTRACK_IPV4,
CONFIG_NF_NAT_IPV4 all m or y). WPA supplicant v2.0 is used and also
configured as described in connman README (CONFIG_WPS, CONFIG_AP,
CONFIG_CTRL_IFACE_DBUS_NEW, CONFIG_BGSCAN_SIMPLE,
CONFIG_AUTOSCAN_EXPONENTIAL all y). Connman version used is v1.15.

In general the described setup seems to work. I'm able to connect to
another Wifi AP using the setup described above and connman. So station
mode is all fine. AP mode of the device/hardware seems to be working also.
I'm also able to enable AP using "iwpriv" based commands or the special
tool "uaputl". But i'm unable to get ethernet/wifi bridging/tethering to
work using connman. The AP doesn't come up and the kernel prints error
messages that the requested mode isn't supported by the device. Which is
partly true. The Wifi device (Marvell SD8787 IC) is registering 3
independent devices from the kernel driver which are mlan0
(infrastructure/station), uap0 (AP) and p2p0 (p2p client). From the device
driver i can see that each of this devices is limited in it's capabilities
to the role it's inteded for. Using the mlan0 device i'm able to connect as
a station to an external AP which works fine using connman and it seems
this is the default device for connman. But as far as i understood connman
is taking control of all these devices, so i assumed that wifi tethering
shouldn't be an issue as well. Although i'm unable to enable it properly using
"connmanctl" to setup AP SSID/Key and finally enabling wifi tethering. As
said above only feedback are kernel messages indicating that connman tries
to switch the mlan0 (station) device into AP mode.

Any idea/hint how to get such a setup running or where to look for a better
understanding? Thanks in advance

Andreas Kaufmann
Patrik Flykt
2013-11-27 09:33:07 UTC
Permalink
Hi,
Post by Andreas Kaufmann
From the software side i'm using a Yocto-Project based rootfs and linux
kernel v3.8 with modifications for the hardware described above. Kernel is
configured according to the connman README (CONFIG_BRIDGE,
CONFIG_IP_NF_TARGET_MASQUERADE, CONFIG_NETFILTER, CONFIG_NF_CONNTRACK_IPV4,
CONFIG_NF_NAT_IPV4 all m or y). WPA supplicant v2.0 is used and also
configured as described in connman README (CONFIG_WPS, CONFIG_AP,
CONFIG_CTRL_IFACE_DBUS_NEW, CONFIG_BGSCAN_SIMPLE,
CONFIG_AUTOSCAN_EXPONENTIAL all y). Connman version used is v1.15.
That is a correct configuration.
Post by Andreas Kaufmann
I'm also able to enable AP using "iwpriv" based commands or the special
tool "uaputl". But i'm unable to get ethernet/wifi bridging/tethering to
work using connman. The AP doesn't come up and the kernel prints error
messages that the requested mode isn't supported by the device. Which is
partly true.
'iwpriv' implies that your device uses the obsolete Wireless Extensions
interface with 'uaputl' being Marwell specific. If the driver supports
the nl80211 interface, neither of these utilities should be necessary.
If they are, there's not much that can be done to fix it. By default
nl80211 is tried first, and wireless extensions only as a fallback. From
where does the driver you are using come from, does it properly support
nl80211 and what is the result after running those commands?
Post by Andreas Kaufmann
The Wifi device (Marvell SD8787 IC) is registering 3
independent devices from the kernel driver which are mlan0
(infrastructure/station), uap0 (AP) and p2p0 (p2p client). From the device
driver i can see that each of this devices is limited in it's capabilities
to the role it's inteded for.
The problem here is that each of those devices are specific for a
certain functionality with the functionality either not being available
via wpa_supplicant D-Bus API or ignored by ConnMan. If it's the latter,
a fix is possible, if the former, wpa_supplicant needs serious fixing.
Post by Andreas Kaufmann
Using the mlan0 device i'm able to connect as
a station to an external AP which works fine using connman and it seems
this is the default device for connman.
This device is most likely the only one that is able to present useful
scan results which end up being expressed as services in ConnMan.
Post by Andreas Kaufmann
But as far as i understood connman
is taking control of all these devices, so i assumed that wifi tethering
shouldn't be an issue as well. Although i'm unable to enable it properly using
"connmanctl" to setup AP SSID/Key and finally enabling wifi tethering. As
said above only feedback are kernel messages indicating that connman tries
to switch the mlan0 (station) device into AP mode.
ConnMan does not know what functionality is associated with each device.
When tethering, ConnMan should try all WiFi devices in turn and enable
at least one of those capable of tethering. Something can go wrong here,
e.g. ConnMan doesn't figure out properly that the device does not
support AP mode or then the device itself misinforms upper layers of its
capability to act as an AP.
Post by Andreas Kaufmann
Any idea/hint how to get such a setup running or where to look for a better
understanding? Thanks in advance
Could you disable all technologies except WiFi, then (re)start connman
with connmand -n -d, scan wifi, connect to a network, disconnect, enable
tethering and send the log file?

Cheers,

Patrik

Loading...