Dropped frames (unauthorized port) in AP mode

[Mihai Moldovan]

* On 24.06.2013 12:43 PM, Jouni Malinen wrote:
> How long after starting hostapd did you try to connect? Just to make
> sure there are no issues with bridge ports not being ready, I'd wait 10
> seconds even if STP is turned off.

I generally waited about 30 seconds after starting hostapd, been doing stuff
like reading/flushing dmest right after starting it. But even if hostapd runs
for hours, the result is the same.

Moreover, I tried to get the bridge out of the equation and removed the bridge
parameter entirely from hostapd.conf, then tried connecting with a station
again. Interestingly, my kernel is still dropping some frame and the ethertype
of that frame is still 0x0006, so this doesn't look like a bridging issue. The
only device within the bridge this time around was eth(er)0, which shouldn't be
"connected" to the wifi devices anymore.


> That looks pretty strange.. Based on the length and timing of the
> frames, the EAPOL-Key msg 1/4 from the AP could be encrypted. This
> should not be the case unless some very strange key configuration was
> somehow applied by something else than hostapd. This seems to imply that
> EAPOL frames are getting through TX path since otherwise there should be
> no unicast Data frames here, though.

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
a729cff8ad5120d0d5172ec28a3843d1cb458f79).

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.

Thus my idea: can I disable usage of TX status and the new monitorless AP mode
and instead have hostapd work "in the old way" for the time being?

I'd still like to have the kernel bug fixed, but in the meantime have a working
hostapd version.


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:

diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index f705a0c..6b44f46 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -3189,7 +3189,7 @@ static int wpa_driver_nl80211_capa(struct
wpa_driver_nl80211_data *drv)
         * If poll command and tx status are supported, mac80211 is new enough
         * to have everything we need to not need monitor interfaces.
         */
-       drv->use_monitor = !info.poll_command_supported || !info.data_tx_status;
+       drv->use_monitor = 1; //!info.poll_command_supported ||
!info.data_tx_status;

        if (drv->device_ap_sme && drv->use_monitor) {
                /*


With this patch, my notebook is able to authenticate. So... what's the real
culprit? :)

dmesg is still showing a dropped frame, but this does indeed seem to be harmless
(ethertype == ... line patched in by myself):
wifi1: Allocated STA f8:1e:df:dd:01:f7
wifi1: moving STA f8:1e:df:dd:01:f7 to state 2
wifi1: moving STA f8:1e:df:dd:01:f7 to state 3
wifi1: Inserted STA f8:1e:df:dd:01:f7
wifi1: dropped frame to f8:1e:df:dd:01:f7 (unauthorized port)
wifi1: ethertype == "0x6", sdata->control_port_protocol == "0x888e"
wifi1: Rx A-MPDU request on f8:1e:df:dd:01:f7 tid 0 result 0
wifi1: moving STA f8:1e:df:dd:01:f7 to state 4


>> I'm seeing a lot of null packets going from my notebook, is that normal?
> It looks unnecessary in this specific case, but maybe it is some kind of
> reaction to Beacon frames and related to power saving (but that station
> did not seem to go sleep mode within this period).

Maybe that's related to SMPS being deactivated. That's fine though, let's ignore
this. :)



Mihai