I think I may have solved this. After pounding my head against a wall for weeks trying to build newer drivers with no success, I stumbled upon two wpa_cli commands that appear to work. What prompted me to try these was an obscure comment about using a P2P GO in an embedded environment such as a printer. wpa_cli -iwlan0 p2p_ext_listen wpa_cli -iwlan0 p2p_listen 600 Issuing these commands before attempting to bring up the P2P GO will keep the GO up and running. I need to do a bit more testing on this but what I'd like to know from the WPA gurus out there is why this works and is there a way to preconfigure wpa_supplicant to launch with these two settings. I don't see these in the documentation for wpa_supplicant.conf so is it possible to put these in the.conf file or do I have to do this in a script? Or is it possible to recompile wpa_supplicant with these two settings as the default? On Mon, Apr 22, 2019 at 6:43 AM Jouni Malinen <j@xxxxx> wrote: > > On Fri, Apr 19, 2019 at 02:23:46PM -0700, Blair Burtan wrote: > > So, my question to the gurus out there is why would allowing > > wpa_supplicant to initiate scanning bork the P2P GO system? Did I > > uncover an obscure bug here? > > That sounds like a driver specific issue that would need someone > familiar with the particular driver to take a look at what is needed to > enable GO and what cannot happen for that GO to continue operating (the > other issue you mentioned about GO stopping). If wpa_supplicant debug > log does not show any errors or warnings related to this, it sounds like > the driver does not really support these concurrent operations properly > and it just happens to work under certain conditions. > > -- > Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
