> Is this being recorded on transmit, or transmit completion? I'm > guessing this is transmit completion on the transmit side. > Is this information coming from the driver, or from some completion > status going up to mac80211? > > Partly from the driver (timestamp and tx aggr flag) and partly from the status going to mac80211 (the bitrate array, retx count) and partly from the mac header ( sequence number) All of them are stored in the radiotap or mac header for each frame delivered in userspace in monitor mode.
The data is recorded from transmit status(You might be referring to it as transmit complete) i.e net/mac80211/status.c The *attempted rates *array is extracted from *struct ieee80211_tx_info * which is part of skb control buffer.I don't really get how is this populated/copied from. The* timestamp* is got from *ath_tx_status*, which is later stored in the ieee80211_tx_info struct to be given to mac80211. Population of timestamp is done in driver (ath_tx_complete_buf() ) The *aggr flag *is populated using struct ath_buf field bf->bf_state.bf_type. > I can tell you what's going on with the hardware. I can't guarantee > that the driver or mac80211 isn't messing things up along the line. > > Can you tell what happens if the whole aggregate frame is tried and does not get transmitted. Does the hardware return it back to driver, and the driver 1)splits the aggregate frame into subframe and retries later 2) hardware does not return the aggregate buffer until its done transmitted it ? There's one TX status for each aggregate being transmitted. If there's > some per-buffer completion information being sent up to mac80211 about > the state of that frame, it _should_ be stamped with the completion > status from the single TX status that represents all the successfully > transmitted frames for that buffer. Yes, I have understood this part from your previous mails, and I am glad that holds true. In this case, I was fine with the above trace if the normal frame had the same timestamp, as it might be in the same buffer while sending. But the tx aggregate flag and different attempted bitrate shows something is wrong. > There's no way at all to get an A-MPDU transmission with different TX > rates for each sub-frame. The hardware just doesn't do it; there's no > possible way to get that information from a single TX completion / > status descriptor. So I'd go looking at what the ath9k driver is doing > to mark completion status in the face of completion and software > retransmit. It may be that something is messed up along the way and > it's storing the wrong timestamp, or the previous rate control > attempt, or something similar. > (I had an issue in FreeBSD where I was processing the rate control > information from the last descriptor in the last buffer, but not > taking a copy of it before I processed the aggregate - so if the final > aggregate succeeded, I'd end up looking at a descriptor from a > just-freed buffer. That caused all kinds of weird behaviour.) > > Sure, I was also confused if I am seeing the last descriptor value, but it was too complicated to know how to find out. I will try to dig more. Can someone confirm if there can be a discrepancy in the status sent to mac80211 and what driver does. I did not understand how the hooks to rate control (rc.c functions) so I could not confirm myself :( - Abhinav > > Adrian >
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
