> -----Original Message----- > From: Evangelos Foutras [mailto:evangelos@xxxxxxxxxxxxx] > Sent: Sunday, December 27, 2015 15:26 > To: Peer, Ilan > Cc: Jouni Malinen; hostap@xxxxxxxxxxxxxxxxxxx > 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. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
