Dropped frames (unauthorized port) in AP mode
Sun Jul 14 11:46:09 PDT 2013
* On 24.06.2013 04:35 PM, Mihai Moldovan wrote:
> It's getting stranger: the very same setup works fine with kernel version 3.0.2,
> but stopped working in-between. IIRC, about the time, when hostapd stopped
> creating a monitor interface and using that for AP mode. At the very same time,
> TX status support has been implemented in mac80211 by Johannes Berg (commit
> After reverting his commit, I was able to use hostapd on 3.5.x - with a monitor
> interface being used, so I suspect the kernel being broken in this respect.
> I haven't been able to revert the commit on top of 3.9.6 due to more
> sophisticated merge conflicts.
> Commit 73a3c6ffca0c0292289c4fc598402b4227c85faf by nbd disables monitor usage
> when detecting TX status support... I have crafted a trivial patch to enable
> monitor mode unconditionally for me:
> With this patch, my notebook is able to authenticate. So... what's the real
> culprit? :)
I've been pestering Ben off-list and gained some new insights.
He's using AR9380 cards extensively in his setups and I haven't seen any bug
reports yet, so tried to replicate his setup.
I tested my hostapd configuration with the exact kernel and hostapd he's
employing, to find out that STAs still weren't able to connect.
But there's one interesting and fatal difference in our hostapd configurations:
I am using hostapd's internal authenticator (for WPA/WPA2), while he is relying
on an external one.
As everything is working for him, but I have to workaround my issue by forcing
hostapd to create a monitor interface and our setups were identical (but in the
very machine, though both have been "normal" x86_64 machines), could the
internal authenticator be the root cause?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4506 bytes
Desc: S/MIME Cryptographic Signature
More information about the Hostap