Patchwork Dropped frames (unauthorized port) in AP mode

login
register
mail settings
Submitter Mihai Moldovan
Date June 24, 2013, 2:35 p.m.
Message ID <51C85919.7090704@ionic.de>
Download mbox | patch
Permalink /patch/253855/
State Not Applicable
Headers show

Comments

Mihai Moldovan - June 24, 2013, 2:35 p.m.
* 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:

        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
Mihai Moldovan - July 14, 2013, 6:46 p.m.
* 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
> 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.
>
> [...]
>
> 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?


Mihai
Ben Greear - July 15, 2013, 12:33 a.m.
On 07/14/2013 11:46 AM, Mihai Moldovan wrote:
> * 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
>> 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.
>>
>> [...]
>>
>> 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?

Can you just test with my exact configuration file that I sent previously?  We are not
actually using any external authenticator, at least for the bulk of our testing.

For that matter, have you tried setting up a non-authenticated configuration?

Thanks,
Ben
Mihai Moldovan - July 15, 2013, 1:38 a.m.
* On 15.07.2013 02:33 AM, Ben Greear wrote:
> Can you just test with my exact configuration file that I sent previously?  We
> are not
> actually using any external authenticator, at least for the bulk of our testing.
>
> For that matter, have you tried setting up a non-authenticated configuration?

Tested just that. Took your config and only modified it to include bridge=br0
and use wifi1 instead of vap0.

This network is unencrypted and my STA can connect. :)

Thus, I added/changed the following lines:

bridge=br0

#eap_server=0
#ieee8021x=0
wpa=2
wpa_passphrase=nurimdunkelnlaesstsichgutmunkeln
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

And that's working, too! No monitor interface, but WPA2 encrypted and actually
working.

So it's gotta be *some other* option I have in my config... let the testing
begin. Thanks just again! :)


Mihai
Mihai Moldovan - July 15, 2013, 2:20 a.m.
* On 15.07.2013 03:38 AM, Mihai Moldovan wrote:
> So it's gotta be *some other* option I have in my config... let the testing
> begin.

Got it! After checking every single option I've been using against Ben's config,
turning features off and back on, I was able to isolate the WEP entries as the
troublemaker.

Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd
started behaving normally, even without a monitor interface.

Is specifying both WPA and WEP options known to cause such problems? It did work
fine in the past, but now it doesn't.

If it's intended behavior and not actually a bug, hostapd should check for both
options being turned on and reject the config file, instead of starting in such
an unusable state. Jouni?

I would never have guessed this to be the culprit. Thank you very much for
pointing me in the right direction, Ben!


Mihai
Jouni Malinen - July 20, 2013, 1:25 p.m.
On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote:
> Got it! After checking every single option I've been using against Ben's config,
> turning features off and back on, I was able to isolate the WEP entries as the
> troublemaker.
> 
> Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd
> started behaving normally, even without a monitor interface.
> 
> Is specifying both WPA and WEP options known to cause such problems? It did work
> fine in the past, but now it doesn't.

What do you mean with working fine? What did you try to do with that
wep_key0 parameter if the network was configured for WPA? I don't think
WPA with static WEP would be supported.

> If it's intended behavior and not actually a bug, hostapd should check for both
> options being turned on and reject the config file, instead of starting in such
> an unusable state. Jouni?

Yes, wep_key# parameters should probably be rejected if wpa != 0. I
don't think that wep_default_key=0 would have any effect on the
functionality in your case, though.

That said, it could also be finally time to consider removing WEP
support from hostapd completely or at least do that for the default
build. I don't see any other use for WEP apart from being able to run
some test cases for station functionality to allow interoperability with
old networks..
Mihai Moldovan - July 20, 2013, 5:36 p.m.
* On 20.07.2013 03:25 PM, Jouni Malinen wrote:
> On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote:
>> Got it! After checking every single option I've been using against Ben's config,
>> turning features off and back on, I was able to isolate the WEP entries as the
>> troublemaker.
>>
>> Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd
>> started behaving normally, even without a monitor interface.
>>
>> Is specifying both WPA and WEP options known to cause such problems? It did work
>> fine in the past, but now it doesn't.
> What do you mean with working fine? What did you try to do with that
> wep_key0 parameter if the network was configured for WPA? I don't think
> WPA with static WEP would be supported.

Those WEP parameters were leftovers from an initial WEP configuration when not
all devices were yet supporting WPA.
Then, I enabled WPA, but kept the WEP entries as-were (if I ever had to disable
WPA again.) Hostapd came up with WPA support and ignored the defined WEP stuff.
Or so I thought.


> Yes, wep_key# parameters should probably be rejected if wpa != 0. I
> don't think that wep_default_key=0 would have any effect on the
> functionality in your case, though.

Oh but it does. This bug is easily reproducible with my card (at least), a WPA
configuration and:

auth_algs=3
wep_default_key=0
wep_key0=123456789a

Indefinitely, rejecting WEP parameters if wpa != 0 is a great idea and would fix
the issue.


> That said, it could also be finally time to consider removing WEP
> support from hostapd completely or at least do that for the default
> build. I don't see any other use for WEP apart from being able to run
> some test cases for station functionality to allow interoperability with
> old networks..

I guess only disabling WEP at build time wouldn't do a lot, as most distros
would be turning it on anyway. I'm not sure how much old hardware is out there
only supporting WEP (and thus the implications of removing WEP support), but I
guess an unencrypted network is just as good  as one encrypted with WEP (for
that matter, users should take matters into hand and for instance setup a VPN
with strong encryption to be used over the unencrypted connections only.)

WEP is probably causing more trouble than it's worth. If you're up to it, start
an RFC/poll on the mailing list and let especially people working with big
networks comment on it.


Best regards,



Mihai
Ben Greear - July 21, 2013, 11:04 p.m.
On 07/20/2013 06:25 AM, Jouni Malinen wrote:
> On Mon, Jul 15, 2013 at 04:20:47AM +0200, Mihai Moldovan wrote:
>> Got it! After checking every single option I've been using against Ben's config,
>> turning features off and back on, I was able to isolate the WEP entries as the
>> troublemaker.
>>
>> Right after commenting wep_default_key(=0) and wep_key0(=somekey), hostapd
>> started behaving normally, even without a monitor interface.
>>
>> Is specifying both WPA and WEP options known to cause such problems? It did work
>> fine in the past, but now it doesn't.
>
> What do you mean with working fine? What did you try to do with that
> wep_key0 parameter if the network was configured for WPA? I don't think
> WPA with static WEP would be supported.
>
>> If it's intended behavior and not actually a bug, hostapd should check for both
>> options being turned on and reject the config file, instead of starting in such
>> an unusable state. Jouni?
>
> Yes, wep_key# parameters should probably be rejected if wpa != 0. I
> don't think that wep_default_key=0 would have any effect on the
> functionality in your case, though.
>
> That said, it could also be finally time to consider removing WEP
> support from hostapd completely or at least do that for the default
> build. I don't see any other use for WEP apart from being able to run
> some test cases for station functionality to allow interoperability with
> old networks..

Well, I like the ability to run these old test cases...  At the least, please
don't remove the code entirely..but if you want to change the default build
options that seems fine.

Thanks,
Ben

>

Patch

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;