wpa_supplicant 2.4/2.5 issue with some Intel chipsets

[Peer, Ilan]

> -----Original Message-----
> From: Evangelos Foutras [mailto:evangelos at foutrelis.com]
> Sent: Sunday, December 27, 2015 15:26
> To: Peer, Ilan
> Cc: Jouni Malinen; hostap at lists.infradead.org
> Subject: Re: wpa_supplicant 2.4/2.5 issue with some Intel chipsets
> 
> On 27/12/15 14:29, Peer, Ilan wrote:
> > There is no specific description of the issues seen by the users but this is
> indeed possible. I've just sent 2 additional patches to handle this, can you give
> them a try?
> >
> > http://patchwork.ozlabs.org/patch/561147/
> > http://patchwork.ozlabs.org/patch/561146/
> >
> > Thanks in advance,
> >
> > Ilan.
> 
> I built test packages with patch 561146 and asked for user confirmation that it
> solves the issue at hand. So far, I have had one confirmation that it does!
> 
> Indeed, there is no single comprehensive report of the issue; my guess is
> based on the following clues found in the main task downstream [1]:
> 
> - The issue only manifests when using netctl-auto which spawns another
> process that attaches to wpa_supplicant; this is also the only scenario where
> the -W flag is passed to wpa_supplicant.
> 
> - Passing an invalid -m flag to wpa_supplicant works around the problem (I
> guess by failing to create a P2P interface?).
> 

Not sure how this solves things .. I would expect this still to fail even with -m. :)  Anyway, if you want to properly disable P2P operation, use p2p_disabled=1 in the configuration file of the main interface. This way you'll not have P2P Device interface initialized.

> Something also clicked when you said that that the "Could not read interface
> p2p-dev-wlp2s0 flags: No such device" message was harmless.
> 
> Cheers for the fix!
> 

Np :) 

Ilan.