Hi Janusz, Any chance you can check if the attached patch fixes the issue you reported? Thanks in advance, Ilan. > -----Original Message----- > From: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless- > owner@xxxxxxxxxxxxxxx] On Behalf Of Peer, Ilan > Sent: Tuesday, June 23, 2015 21:00 > To: chaitanya.mgit@xxxxxxxxx > Cc: linux-wireless@xxxxxxxxxxxxxxx; janusz.dziedzic@xxxxxxxxx > Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - > direct probe issue > > -----Original Message----- > From: Krishna Chaitanya > <chaitanya.mgit@xxxxxxxxx<mailto:Krishna%20Chaitanya%20%3cchaitanya.m > git@xxxxxxxxx%3e>> > To: "Peer, Ilan" > <ilan.peer@xxxxxxxxx<mailto:%22Peer,%20Ilan%22%20%3cilan.peer@intel.c > om%3e>> > Cc: Janusz Dziedzic > <janusz.dziedzic@xxxxxxxxx<mailto:Janusz%20Dziedzic%20%3cjanusz.dziedzic > @tieto.com%3e>>, linux-wireless@xxxxxxxxxxxxxxx <linux- > wireless@xxxxxxxxxxxxxxx<mailto:%22linux- > wireless@xxxxxxxxxxxxxxx%22%20%3clinux-wireless@xxxxxxxxxxxxxxx%3e>> > Subject: Re: AP + P2P_GO multichan tests with intel7260 as a P2P_CLIENT - > direct probe issue > Date: Tue, 23 Jun 2015 17:34:59 +0530 > > > > On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan > <ilan.peer@xxxxxxxxx<mailto:ilan.peer@xxxxxxxxx>> wrote: > >> >> > >> >> I suspect this is because of P2P_GO NoA? > >> >> Who should care about this direct probes tx when GO is not present? > >> >> > >> >> In case we didn't send direct probes - there is no problem and TC > >> >> works correctly > >> >> > >> > > >> > Interesting :) > >> > > >> > Any chance you can provide trace-cmd and sniffer capture? > >> > > >> > Normally, if we provided the FW with the BSSID information and TSF > >> > information for syncing, once the FW hears the 1st beacon with the > >> > NoA it should sync on it and not try to attempt to transmit any > >> > frames as long as the AP is absent. It might also be related to the > >> > fact that the probe requests are sent to broadcast address, but I > >> > need to further checks this. Anyway, having some data would help ;) > >> > > >> Thats exactly the point, if GO is in NoA FW will not transmit but > >> mac80211 timed-out for direct probe. > >> > >> So the question is should mac80211 even send the direct probe in this > >> case when GO is in NoA? > > > > I think that this should be the driver's/FW responsibility, as at this stage > mac80211 already configured all the information needed for the driver to > sync (assuming it heard a beacon/probe) and in addition mgd_prepare_tx() is > called to have the driver/FW prepare for a transmission of the mgmt. frame, > including synchronization with the P2P GO power state. > Agree, the actual transmission should definitely be in driver/FW but the > timeout for such frames are still at mac80211, so unless su it synchronizes the > timeouts to GO NoA period this "can" fail depending on the absence period of > GO. Default auth_timeout is 200ms. > > > I do not think that mac80211 should handle the synchronization, mostly since > it does not get the beacons from the AP we are associated with. As I > explained above, this should be the drivers/FW responsibility once they have > all the information they require. As such, I think that is expected from the > driver/FW to only send the frames when the P2P GO/AP is on the channel. > > Regards, > > Ilan. > > > > N r y b X ǧv ^ ){.n + { *ޕ , {ay ʇڙ ,j f h z w j:+v w j m zZ+ > ݢj" ! i
Attachment:
0001-iwlwifi-mvm-Use-the-AP-station-for-non_sta-transmit.patch
Description: 0001-iwlwifi-mvm-Use-the-AP-station-for-non_sta-transmit.patch
