Hello Avinash,
Thanks! That works for me. Would it be possible to add this to the
mwifiex page on wireless.kernel.org? As far as I know, this command is
completely undocumented within iw, and I know I'm not the only
Dreamplug owner experiencing this problem.
As for other issues, I'm seeing a hang in the TX queue on the device
after running an AP for a while, but I'm still gathering information
on that. I'll follow up with another thread.
Thanks,
Andrew
On Sat, Feb 1, 2014 at 9:48 PM, Avinash Patil <[email protected]> wrote:
> Hi Andrew,
>
> AP interface can be created using iw utility. Command is as follows:
>
> iw dev mlan0 interface add uap0 type __ap
>
> There onwards hostapd can be used to start mwifiex AP operations. Please let
> me know if you face any issues.
>
> Thanks,
> Avinashw
>
> On Feb 2, 2014 8:28 AM, "Andrew Wiley" <[email protected]> wrote:
>>
>> Hello linux-wireless,
>>
>> I'm trying to get AP mode to work on a Marvell Kirkwood-based
>> Dreamplug with an SD8787 SDIO wireless chipset.
>>
>> Originally, the mwifiex driver would create three interfaces when it
>> loaded - mlan0, uap0, and ptp0, for station mode, AP mode, and PTP
>> mode, respectively. That behavior was removed in commit 1211c (
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mwifiex?id=1211c961170cedb21c30d5bb7e2033c8720b38db
>> ) because NetworkManager was trying to use all of the interfaces
>> rather than just mlan0.
>>
>> As I understand it, the normal workflow for this is that hostapd
>> changes an interface from station mode to AP mode when it starts up,
>> but when it tries to do this on the mlan0 interface, nl80211 returns
>> Operation Not Supported. Depending on the version of hostapd, it
>> either bails out there or tries to continue and bails out later in
>> setup.
>>
>> If I revert the patch I linked above, the driver creates the uap0
>> interface and I can run an AP with hostapd (although it has some other
>> issues - more on that in a later post).
>>
>> What is the "correct" way to access AP mode with this driver? As far
>> as I'm aware, there are no userspace utilities to directly create an
>> AP-mode interface, and mwifiex doesn't seem to support the normal
>> workflow that hostapd is trying to do.
>>
>> Thanks,
>> Andrew
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Interesting.
I haven't seen any allocation failures in my kernel log, so I probably
have a different issue, but I'll keep an eye out.
My platform only has 512MB of RAM, so I suspect the only reason I'm
not seeing this is that I'm running an AP with no servers, so packets
are just forwarded through a layer-2 bridge rather than sent to
userspace applications.
On Sun, Feb 2, 2014 at 3:51 PM, James Cameron <[email protected]> wrote:
> On Sat, Feb 01, 2014 at 11:01:02PM -0600, Andrew Wiley wrote:
>> Hello Avinash,
>>
>> Thanks! That works for me. Would it be possible to add this to the
>> mwifiex page on wireless.kernel.org? As far as I know, this command is
>> completely undocumented within iw, and I know I'm not the only
>> Dreamplug owner experiencing this problem.
>>
>> As for other issues, I'm seeing a hang in the TX queue on the device
>> after running an AP for a while, but I'm still gathering information
>> on that. I'll follow up with another thread.
>
> I've also seen hangs, in both RX and TX, but mostly RX.
>
> The response to failing to alloc an skb is a bit weak in mwifiex, we
> noted this on OLPC XO-4 with the 8787. You can see more about the
> problem and some local fixes in our private branch:
>
> http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>
> http://dev.laptop.org/ticket/12694 (kernel 3.5)
>
> I did backport the latest mwifiex at the time, but it did not fix the
> issue, so I dug into it more.
>
> --
> James Cameron
> http://quozl.linux.org.au/
On Sat, Feb 01, 2014 at 11:01:02PM -0600, Andrew Wiley wrote:
> Hello Avinash,
>
> Thanks! That works for me. Would it be possible to add this to the
> mwifiex page on wireless.kernel.org? As far as I know, this command is
> completely undocumented within iw, and I know I'm not the only
> Dreamplug owner experiencing this problem.
>
> As for other issues, I'm seeing a hang in the TX queue on the device
> after running an AP for a while, but I'm still gathering information
> on that. I'll follow up with another thread.
I've also seen hangs, in both RX and TX, but mostly RX.
The response to failing to alloc an skb is a bit weak in mwifiex, we
noted this on OLPC XO-4 with the 8787. You can see more about the
problem and some local fixes in our private branch:
http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
http://dev.laptop.org/ticket/12694 (kernel 3.5)
I did backport the latest mwifiex at the time, but it did not fix the
issue, so I dug into it more.
--
James Cameron
http://quozl.linux.org.au/
Hi Andrew,
Will surely document this and other steps on mwifiex wiki page soon.
Please share timeout log as well.
Thanks,
Avinash Patil
On Sun, Feb 2, 2014 at 10:31 AM, Andrew Wiley <[email protected]> wrote:
> Hello Avinash,
>
> Thanks! That works for me. Would it be possible to add this to the
> mwifiex page on wireless.kernel.org? As far as I know, this command is
> completely undocumented within iw, and I know I'm not the only
> Dreamplug owner experiencing this problem.
>
> As for other issues, I'm seeing a hang in the TX queue on the device
> after running an AP for a while, but I'm still gathering information
> on that. I'll follow up with another thread.
>
> Thanks,
> Andrew
>
> On Sat, Feb 1, 2014 at 9:48 PM, Avinash Patil <[email protected]> wrote:
>> Hi Andrew,
>>
>> AP interface can be created using iw utility. Command is as follows:
>>
>> iw dev mlan0 interface add uap0 type __ap
>>
>> There onwards hostapd can be used to start mwifiex AP operations. Please let
>> me know if you face any issues.
>>
>> Thanks,
>> Avinashw
>>
>> On Feb 2, 2014 8:28 AM, "Andrew Wiley" <[email protected]> wrote:
>>>
>>> Hello linux-wireless,
>>>
>>> I'm trying to get AP mode to work on a Marvell Kirkwood-based
>>> Dreamplug with an SD8787 SDIO wireless chipset.
>>>
>>> Originally, the mwifiex driver would create three interfaces when it
>>> loaded - mlan0, uap0, and ptp0, for station mode, AP mode, and PTP
>>> mode, respectively. That behavior was removed in commit 1211c (
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mwifiex?id=1211c961170cedb21c30d5bb7e2033c8720b38db
>>> ) because NetworkManager was trying to use all of the interfaces
>>> rather than just mlan0.
>>>
>>> As I understand it, the normal workflow for this is that hostapd
>>> changes an interface from station mode to AP mode when it starts up,
>>> but when it tries to do this on the mlan0 interface, nl80211 returns
>>> Operation Not Supported. Depending on the version of hostapd, it
>>> either bails out there or tries to continue and bails out later in
>>> setup.
>>>
>>> If I revert the patch I linked above, the driver creates the uap0
>>> interface and I can run an AP with hostapd (although it has some other
>>> issues - more on that in a later post).
>>>
>>> What is the "correct" way to access AP mode with this driver? As far
>>> as I'm aware, there are no userspace utilities to directly create an
>>> AP-mode interface, and mwifiex doesn't seem to support the normal
>>> workflow that hostapd is trying to do.
>>>
>>> Thanks,
>>> Andrew
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html