Getting to ap mode has been a struggle due to closed source firmware, vendor-modified driver… I am going to reiterate the whole story here, so if you just want the solution simply skip to the end of this post.
The wandboard has a bcm4329 which is a design by Broadcom and therefore requires a binary firmware and a compatible driver.
A few months ago, someone posted a thread asking for ap mode on the wandboard because the chip apparently supporty it but the backported brcfmac with the firmware delivered by linux-firmware or the one in wandboard-firmware doesn’t.
Mr. Tapani (he’s with the wandboard-project) then asked their manufacturer for a better firmware and/or a better driver and finally received a response (though hindered by a forwarding chain… business reasons of course).
The packaged they received was later posted in the forums and it included a firmware and a the “bcmdhd” driver which should support the ap mode.
After some trouble compiling the kernel (which needed a kernel patch) I got it to compile and inserted the module. Using hostapd, I even got it to run as an ap (it was visible on my android phone) and was able to connect and ping afterwards. It all worked on open mode, but after I added encryption it stopped working. With enabled WPA/WPA2, the ap was still visible, but you could not connect to it.
Tapani replied to the manufacturer and received new instructions (README as a PNG File…) involving a mysterious ‘wl’ utility. I tried the instructions from the PNG and tried to improvise using the manual I found here, but I did not have any success with it (ap wasn’t even visible).
Afer all that, I’ve realized that the brcmfmac driver (which is completely open source but relies on the binary firmware) does actually include ap support! The version used in the wandboards 3.0.35 kernel (which is still the stable release for i.MX6 devices :/) is backported by Tapani from 3.5rc7 and is too old to support ap mode though :/
I tried using the (early) 3.10.17 kernel which includes a new brcmfmac driver and it actually worked! Even with WPA2 I was able to connect, authenticate and ping on the newly established connection! Sadly though, this driver was not available on 3.0.35.
But there is help for the older kernel after all: The backports-project allow you to compile and run drivers from the most recent linux (3.13 in this case) to run on kernels as old as 2.6.xx (in the case of brcmfmac it’s 2.6.29). This allowed me to compile the driver from 3.10.17 and run it on 3.0.35! And here we go again, ap mode worked!
The problem with this method was, that I had not tried to have any actual traffic on the wandboard (more than just a simple ping, iperf for example). Heavy traffic resulted in loads of
[ 5630.178929] brcmfmac: brcmf_sdio_buffrw: sg request length 964 is not 512 aligned
on serial and huge connection problems on client side.
But as I have come this far, I just could not resign and tried the newer version from 3.13 (again, using the backports-project). Again, ap mode worked with WPA2 and this time the error message was gone! I was actually able to sustain like 10mbit over the wandboards ap!
I wrote down my build-instructions using a Archlinux PKGBUILD file which you can find here. It downloads the 3.13-stable kernel source, the 3.13-compatible version of backports and compiles the modules ‘compat/compat.ko’,’net/wireless/cfg80211.ko’, ‘drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko’ and ‘drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko’ and adds them to the updates/ folder of your kernel. It also extracts the firmware from the archive Tapani posted and puts it in the respective /usr/lib/firmware/brcm location for the brcmfmac driver.
Afer running a depmod and then modprobe’ing the brcmfmac module, your wandboard will now support ap mode (via hostapd).
If you need more build instructions, just drop me a note.