Dropped frames (unauthorized port) in AP mode

[Jouni Malinen]

On Mon, Jun 24, 2013 at 12:12:32AM +0200, Mihai Moldovan wrote:
> The bridging setup is really basic and shouldn't cause any problems. I have
> turned off STP (it's the only network bridge anyway), other than that the bridge
> is managed by hostapd adding/removing wifi interfaces. Nothing sophisticated.

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.

> > Do you have another device you could use as a sniffer to capture the
> > frames between the devices? It would be useful to verify whether
> > EAPOL-Key 1/4 and 2/4 are actually transmitted or not.
> 
> I removed wifi0 from the setup and set it up to capture packets on channel 9,
> then had my notebook connect to wifi1, powered up by hostapd on channel 9 (and
> still included in the bridge).
> 
> The result is small and attached here.

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.

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

-- 
Jouni Malinen                                            PGP id EFC895FA