FTM sessions are rate-limited with apparent ban of station (IDFGH-6015)

[crackwitz]

Environment

• esp-idf v4.3.1
• ESP32-S2-DevKitM
• ESP32-S2-MINI-1

On startup, this is reported:

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
...
I (40) boot: chip revision: 0
...
I (430) phy_init: phy_version 1800,e7ef680,Apr 13 2021,11:45:08

Problem Description

When running the ftm example (on ESP32-S2) and requesting ftm -I -s ... repeatedly, eventually the request fails forever with status 2 (FTM_STATUS_CONF_REJECTED presumably). The softAP still responds to any other clients, unless they too exceed the rate limit.

I would prefer to run measurements as fast and as often as possible and get every available piece of information (thesis work). However, even when limiting the requests to one per 5.0 seconds, after a few minutes of requests, the AP seems to "ban" that client. Only resetting the AP allows that client to continue FTM sessions.

Expected Behavior

I expect the AP to have no limit on the number or rate of FTM requests and I expect the AP to not ban stations.

Actual Behavior

AP bans station after an unknown number or rate of FTM requests. Dozens of requests are possible though.

Steps to reproduce

1. run two ESP32-S2 with ftm example
2. set one to be softAP
3. keep running ftm sessions from the other
4. eventually it won't work anymore and the AP has to be reset

[crackwitz]

I've experimented with incrementing the station MAC using esp_wifi_set_mac before every FTM request, and initiating FTM every 1.0 seconds. That manages to circumvent the apparent "block" once or twice, but then even that stops working, and other clients are also blocked from FTM, which I didn't observe when I didn't increment MAC addresses.

It also seems as if some state is remembered through a reset because if I restart the "abuse" from similar MAC addresses, it locks up quicker... Incrementing MAC addresses on one client also appears to "unlock" other locked stations...

The module acting as AP doesn't report any events, nor does it panic and reset. Even after the apparent FTM ban, those stations can connect to the AP (which doesn't reset the FTM ban).

In summary, complex and sufficiently non-deterministic behavior, also not documented as far as I can see.

[wqiu-calgary]

I have experienced the same behaviours on both the ESP32-S2 and ESP32-C3 Dev boards. This severely hampers the usage of FTM feature. I have tried on google 802.11mc APs, and did not found such a rate limit.

I can accept a lower responding rate from the responder, but stop responding is definitely not acceptable

[khgoh99]

I testing with two ESP32-C3 with the example (one as the initiator and the other as responder) and have the same experience.

On top of it, I also found out that the distance result is different when the initiator is connected vs not connected to the responder SoftAP.

[crackwitz]

Can confirm, issue appears resolved. Thanks!

[nachiketkukade]

Welcome! The fix is merged in master, it should also be available with IDFv4.3.2