-----Original Message----- From: Krishna Chaitanya <chaitanya.mgit@xxxxxxxxx<mailto:Krishna%20Chaitanya%20%3cchaitanya.mgit@xxxxxxxxx%3e>> To: "Peer, Ilan" <ilan.peer@xxxxxxxxx<mailto:%22Peer,%20Ilan%22%20%3cilan.peer@xxxxxxxxx%3e>> Cc: Janusz Dziedzic <janusz.dziedzic@xxxxxxxxx<mailto:Janusz%20Dziedzic%20%3cjanusz.dziedzic@xxxxxxxxx%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��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
