The current implementation of esp_wifi_80211_tx() is fire and forget. The problem is that sometimes the device will employ RTS/CTS in order to deliver the arbitrary frame instead of a direct transmission on the line. While RTS/CTS is important to prevent collision, there can be confusion to the user about what was actually sent, or if the transmission was even successful.
Describe the solution you'd like.
esp_wifi_80211_tx() should have an optional, or required, callback which will report the status of the transmission. This callback should include information such as:
Was the transmission successful
was RTS / CTS used
was RTS / CTS successful in delivering the frame
Other useful bits that I would love to see:
Did the receiving device ACK (if that's possible within the current implementation)
What was the checksum of the final frame
what was the time on wire
how many total frames were sent in order to deliver the requested payload
What was the RTS frame, and details of the responding CTS (signal strength, channel, just like the rx_ctrl in a promiscuous callback)
Describe alternatives you've considered.
Allowing the user direct control over the use of RTS / CTS in order to ensure the exact frame is delivered as desired. The issue here is users may be confused when they are not able to ever successfully deliver a frame on a busy line.
Making the function blocking. When esp_wifi_80211_tx() is called, it could be a blocking function that will not continue execution until the frame is properly sent and the response could be in the form of esp_err_t in line with other functions. The idea of a blocking function isn't really desirable, and esp_err_t isn't really employable without blocking.
Is your feature request related to a problem?
The current implementation of
esp_wifi_80211_tx()
is fire and forget. The problem is that sometimes the device will employ RTS/CTS in order to deliver the arbitrary frame instead of a direct transmission on the line. While RTS/CTS is important to prevent collision, there can be confusion to the user about what was actually sent, or if the transmission was even successful.Describe the solution you'd like.
esp_wifi_80211_tx()
should have an optional, or required, callback which will report the status of the transmission. This callback should include information such as: Was the transmission successful was RTS / CTS used was RTS / CTS successful in delivering the frameOther useful bits that I would love to see: Did the receiving device ACK (if that's possible within the current implementation) What was the checksum of the final frame what was the time on wire how many total frames were sent in order to deliver the requested payload What was the RTS frame, and details of the responding CTS (signal strength, channel, just like the rx_ctrl in a promiscuous callback)
Describe alternatives you've considered.
Allowing the user direct control over the use of RTS / CTS in order to ensure the exact frame is delivered as desired. The issue here is users may be confused when they are not able to ever successfully deliver a frame on a busy line.
Making the function blocking. When
esp_wifi_80211_tx()
is called, it could be a blocking function that will not continue execution until the frame is properly sent and the response could be in the form ofesp_err_t
in line with other functions. The idea of a blocking function isn't really desirable, andesp_err_t
isn't really employable without blocking.Additional context.
related to this bug report https://github.com/espressif/esp-idf/issues/10668