On 15 December 2014 at 08:40, Till Wollenberg <till.wollenb...@uni-rostock.de> wrote: > Hi! > > * On 12.12.2014 00:05 Adrian Chadd wrote: >> >> I _think_ that the only valid timestamp/rssi is is the final frame in >> an aggregate, not the intermediary frames. Did you correlate your >> checking with whether it was an aggregate or not, and if it's an >> aggregate, whether it's first, middle or final? > > > Thank you for pointing this out! I checked some of the frames without signal > information in my dataset. In all cases, these frames belong to a row of > frames with identical source and destination addresses, and more important, > with identical MAC timestamp. > > However, in some cases the first frame of a row carries a signal value while > all others do not, and in some cases the very last frame carries a signal > value while all others do not. > > There are also cases with a row of frames having identical MAC timestamps, > but no frame has a signal value.
Hm, interesting. Ok, so can you paste examples of these? I'd be interested in the state of the PHY errors and other potential causes of error. > It seems aggregated frames are de-aggregated somewhere on the chip or in the > driver before they appear on the monitor mode interface. Do you know if it > is possible (at least in theory) to pass A-MPDU and/or A-MSDU frames "as > they are", i.e. without de-aggregation, up to a monitor mode interface? I don't think there's a way to disable the A-MPDU logic. I can double-check with the hardware contacts I have, but I'm still trying to finish chasing up the last couple of wtf's from the AR9380. :P -adrian _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
