Just tag all RX packets as needing reorder processing for now.

This fixes two problems -

* All packets need to be processed here, not just aggregate ones - as any
  received frames (AMPDU or otherwise) in the given TID (traffic class id)
  will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
  somehow need to be tracked. Thus just tag them all for now; I'll figure out
  the why later.

Whilst I'm here, bump the stats counters whilst I'm at it.

This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.

1 files changed, 12 insertions, 5 deletions

diff --git a/sys/dev/ath/if_ath.c b/sys/dev/ath/if_ath.c
index ad4b998..cb651ae 100644
--- a/sys/dev/ath/if_ath.c
+++ b/sys/dev/ath/if_ath.c
@@ -3891,12 +3891,19 @@ rx_accept:
 			rs->rs_keyix == HAL_RXKEYIX_INVALID ?
 				IEEE80211_KEYIX_NONE : rs->rs_keyix);
 		sc->sc_lastrs = rs;
+		/* tag AMPDU aggregates for reorder processing */
+		/*
+		 * Just make sure all frames are tagged for AMPDU reorder checking.
+		 * As there seems to be some situations where single frames aren't
+		 * matching a node but bump the seqno. This needs to be investigated.
+		 */
+		m->m_flags |= M_AMPDU;
+
+		/* Keep statistics on the number of aggregate packets received */
+		if (rs->rs_isaggr)
+			sc->sc_stats.ast_rx_agg++;
+
 		if (ni != NULL) {
-			/* tag AMPDU aggregates for reorder processing */
-			if (rs->rs_isaggr) {
-				
-				m->m_flags |= M_AMPDU;
-			}
 			/*
 			 * Sending station is known, dispatch directly.
 			 */