Hi Felix, Adrian, > /* This packet was aggregated but doesn't carry status info */ > if ((info->flags & IEEE80211_TX_CTL_AMPDU) && > !(info->flags & IEEE80211_TX_STAT_AMPDU)) > return; > > Any packet with IEEE80211_TX_CTL_AMPDU and not IEEE80211_TX_STAT_AMPDU > does not carry valid rate/retry information. Did you filter your debug > stuff accordingly? >
I thought* rate_control_tx_status()[hook to minstrel_rate_ht]* in * ieee80211_tx_status()* will return back to driver (using the condition you told above) without reaching the radiotap code, but I don' t know why it does not. I continued and printed the flag, and have found the following : I added another flag(first entry) in radiotap header to indicate 1 if IEEE80211_TX_CTL_AMPDU is set and IEEE80211_TX_STAT_AMPDU is not (the above condition) eg. [1,0,0,0,1] first is above cond, last flag is for aggregation. The driver code indicates, this will be true if the frame passes through ath_tx_rc_status() [which is only twice]. I had noticed that if I do this, I won't probably get the timestamp of rest of the frames given back to mac80211. device ,tsf , tx_flags, retx_count,succ rate, attempted bitrates, seq no,(queue+airtime)delay,dumb, frame size 64:a7:69:53:0b:15 159787172 [0, 0, 0, 0, 1] 0 52.0 [] 586 1233 2 1462 64:a7:69:53:0b:15 159787172 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 587 2697 2 1462 64:a7:69:53:0b:15 159848530 [0, 0, 0, 0, 0] 0 52.0 [] 588 1436 2 1462 64:a7:69:53:0b:15 159848892 [0, 0, 0, 0, 0] 0 52.0 [] 589 1722 2 1462 64:a7:69:53:0b:15 159849272 [0, 0, 0, 0, 0] 0 52.0 [] 590 1010 2 1462 64:a7:69:53:0b:15 159849931 [0, 0, 0, 0, 0] 0 58.5 [] 591 1602 2 1462 64:a7:69:53:0b:15 159850511 [0, 0, 0, 0, 0] 0 52.0 [] 592 1366 2 1462 64:a7:69:53:0b:15 159850864 [0, 0, 0, 0, 0] 0 52.0 [] 593 1631 2 1462 64:a7:69:53:0b:15 159851253 *[0, 0, 0, 0, 1] 0 52.0 []* 594 2796 2 1462 64:a7:69:53:0b:15 159851253 *[1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]]* *595* 1016 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] *597* 2578 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] *598* 1623 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] *599* 2312 2 1462 <- all invalid !? 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]]* 600* 182 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]]* 601* 2102 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]]* 602* 6424 2 1462 64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]]* 603* 513 2 1462 64:a7:69:53:0b:15 159899519 [0, 0, 0, 0, 0] 0 52.0 [] 604 24569 2 1462 64:a7:69:53:0b:15 159903297 [0, 0, 0, 0, 0] 0 52.0 [] 605 28311 2 1462 *64:a7:69:53:0b:15 159937368 [0, 0, 0, 0, 1] 0 52.0 [] 606 38496 2 1462* *64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 607 3645 2 1462* 64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 608 393 2 1462 64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 609 809 2 1462 64:a7:69:53:0b:15 159954617 [0, 0, 0, 0, 0] 0 65.0 [] 610 51231 2 1462 *64:a7:69:53:0b:15 159956668 [0, 0, 0, 0, 1] 0 52.0 [] 611 55867 2 1462* *64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 612 4501 2 1462* 64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 613 79511 2 1462 64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 614 6829 2 1462 64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 615 830 2 1462 64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5], [52.0, 5]] 616 1129 2 1462 This suggests that first frame (594,606,611) are valid and aggregated but the following frames are invalid. I will be very grateful to you if you can please tell how to interpret the frames which have the *aggregation *bit(last flag in tx_status flags ) *set* but *do not carry status info *and are delivered to monitor interface. The* sequence number *are* increasing* and never repeating ever again in trace If I remove these frames, it looks like there was no aggregation (I guess aggr of 1462 bytes ?), but why are those seq. numbers never re-used ? - Abhinav
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
