Bug: CSI not being recorded due to AR_CRCErr not being set on last frame

[Geosearchef]

AR_CRCErr is used to distinguish between being on the last subframe of e.g. a jumbogram. This flag being set means, we're on the last subframe (as mentioned by comment a few lines above), but as far as I can tell, it not being set doesn't necessarily mean we're not on the last subframe, it could also mean, there hasn't been a CRC error (AR_PostDelimCRCErr not set).

https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_mac.c#L611

Why do you use that for detecting the last subframe?

My experiments seem to confirm that. When I send ICMP echo requests or <200 frames using the send_Data tool, I see the AR_CRCErr == false case triggering but never with rs_more == 1, therefore not setting the valid flag in the CSI code and never recording the csi information.
When sending >1000 frames using send_Data, some of them trigger the second case, but the last ones always trigger the first case with AR_CRCErr set, therefore attempting to record CSI information (which again fails due to https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_csi.c#L251 but that's another issue). I suspect this is due to the amount of data being sent causing some frames to contain errors (being caught by the CRC).

Some clarification on why you distinguish those two cases in that way and how you detect a packet without CSI (e.g. beacon) would be nice (I can't seem to find documentation for rx_hw_upload_data, rx_hw_upload_data_valid and rx_hw_upload_data_type).

[Geosearchef]

Seems like the AR_CRCErr flag does indeed indicate an error detected by the CRC checksum.
From the datasheet for the AR9344 in the WDR4300:
https://datasheetspdf.com/pdf-file/825113/Atheros/AR9344/1

Page 105:

CRC error flag. If set, reception of the frame failed because the PCU detected an incorrect CRC value. Valid only if the frame_rx_ok flag is clear.