On Tue, Jun 23, 2015 at 5:25 PM, Peer, Ilan <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 it synchronizes the timeouts to GO NoA period this "can" fail depending on the absence period of GO. Default auth_timeout is 200ms. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
