You are not logged in.
Hi,
I want to log the MAC address and time tag of any received packets exactly when the router sends ACK to it. Unfortunately in mpdu_transmit_done function tx_details_type is never related to transmitted ACK!
Regards
Offline
The 'mpdu_transmit_done' context in any of the CPU_HIGH projects only applies to MPDUs. In other words, that context only applies to data and management frames that are created in CPU_HIGH and then passed down to CPU_LOW for transmission. ACKs and other control frames like RTS/CTS are not created by CPU_HIGH.
As of the latest 1.3 release of the 802.11 Reference Design, transmissions of control frames are indeed logged by default. This logging doesn't occur within 'mpdu_transmit_done' like it does for MPDUs. Take an ACK transmission as an example. When CPU_HIGH is notified of a reception of an MPDU that met the criteria to transmit an ACK, it implicitly knows than CPU_LOW created and transmitted an ACK a SIFS interval after the reception. Using this implicit knowledge, the mpdu reception context in CPU_HIGH logs the transmitted ACK frame as well.
Offline
S
Last edited by hadi (2015-Sep-14 09:43:35)
Offline
So somewhere in mpdu_rx_process acked packet could be recognizable? Actually I can not found exactly a point in mpdu_rx_process at which an acked packet counter become similar to what an protocole analyzer counts. I am not sure if checking unicast_to_me is enough?
chunter wrote:
The 'mpdu_transmit_done' context in any of the CPU_HIGH projects only applies to MPDUs. In other words, that context only applies to data and management frames that are created in CPU_HIGH and then passed down to CPU_LOW for transmission. ACKs and other control frames like RTS/CTS are not created by CPU_HIGH.
As of the latest 1.3 release of the 802.11 Reference Design, transmissions of control frames are indeed logged by default. This logging doesn't occur within 'mpdu_transmit_done' like it does for MPDUs. Take an ACK transmission as an example. When CPU_HIGH is notified of a reception of an MPDU that met the criteria to transmit an ACK, it implicitly knows than CPU_LOW created and transmitted an ACK a SIFS interval after the reception. Using this implicit knowledge, the mpdu reception context in CPU_HIGH logs the transmitted ACK frame as well.
Offline
unicast_to_me && fcs_good is sufficient to figure out whether a packet was ACKed or not. Alternatively, rather than have CPU_HIGH have to "guess" whether or not CPU_LOW sent a response from like an ACK or a CTS, we explicitly raise a flag in the mpdu_info struct of the received packet to notify CPU_HIGH that a response was sent. This flag is defined as "RX_MPDU_FLAGS_FORMED_RESPONSE" and you can see how we used it in the logging of ACK frames in wlan_mac_entries.c
Offline