[PATCH] Verify MFPC/MFPR capability setting of WPA SM

Jouni Malinen j
Sun Nov 16 07:44:59 PST 2014

On Sun, Nov 16, 2014 at 02:55:09PM +0000, Stepanov, Max wrote:
> >Could you please share a full wpa_supplicant debug log or wireless capture showing this?
> Sure. I'll send you the log file directly - it's too big for the list.


> Agree too, perhaps it's an older SW AP version, but that's exactly the point. Such APs are already available and used. They may make issues in regular WPA2 connection scenarios. If the end user cannot connect some AP with WPA2-PSK it's not so important to him which side (AP or STA) is right or wrong. You are right, perhaps it makes sense to consider this as an interop adhoc workaround.

I understand why we need to work around this issue and I just want to
make sure we do that properly and not by making wpa_supplicant

> Both commenting pmf=1 in Android's wpa_supplicant.conf or applying this patch not to set MFPC in the association request solved the issue on my side.

I do not consider either of those proper ways of working around the

> In hostap master branch the default wpa_supplicant.conf contains #pmf=0, however wpa_supplicant_template.conf contains pmf=1. This option was added by Dmitry on Sep 4. Patch 9ffd5129 (Android: set pmf=1 to default template). I guess this issue will be common for all Android builds.

It is.

> Please let me know if you need more info.

Could you please test if this commit without those other changes you
described here is enough to fix this for you?

commit 9f6a7cddc42811883d6035032854089475f2fc65
    Work around AP misbehavior on EAPOL-Key descriptor version


In other words, I would like to get confirmation that the specific AP
that you saw this issue with works fine if the station is still
including MFPC=1 in RSN element, but allows the AES-128-CMAC version of
descriptor version field (3) to be used.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list