From mboxrd@z Thu Jan 1 00:00:00 1970 From: Till Wollenberg Date: Mon, 15 Dec 2014 17:40:43 +0100 Subject: [ath9k-devel] Chip glitch for RSSI value ? In-Reply-To: References: <20141211171426.4dd8f20a@fusen> <5489E02A.9090908@uni-rostock.de> Message-ID: <548F0F0B.206@uni-rostock.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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. 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? Best regards Till