-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wifi dpp fixes (IDFGH-9445) #10812
Wifi dpp fixes (IDFGH-9445) #10812
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -180,12 +180,12 @@ static int esp_dpp_handle_config_obj(struct dpp_authentication *auth, | |
wifi_config_t *wifi_cfg = &s_dpp_ctx.wifi_cfg; | ||
|
||
if (conf->ssid_len) { | ||
os_memcpy(wifi_cfg->sta.ssid, conf->ssid, conf->ssid_len); | ||
os_strlcpy((char*)wifi_cfg->sta.ssid, (char*)conf->ssid, sizeof(wifi_cfg->sta.ssid)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd probably separate this stuff into two separate PRs. You have on one hand trying to fix ESP_ERR_DPP_TX_FAILURE and on the other hand trying to make it work to let you bootstrap and/or start_listen multiple times. I suspect the os_strlcpy fix is going to sale through more easily where as the MBO support is going to need a lot more careful thought to really understand what's going on there and why that would be relevant. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I still don't personally know why exactly MBO support seems to fix it as well as it does. And it doesn't help that once you get deep enough into wifi related stuff, there isn't much in the way of documentation or anything. |
||
} | ||
|
||
if (dpp_akm_legacy(conf->akm)) { | ||
if (conf->passphrase[0]) | ||
os_memcpy(wifi_cfg->sta.password, conf->passphrase, | ||
os_strlcpy((char*)wifi_cfg->sta.password, (char*)conf->passphrase, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This has a subtle bug in that if your first start_listen sequence yields a passphrase and your second one does not, you'll technically yield a wifi_config_t with a passphrase from the previous listen. I think the fix is overall more consistent if you wipe the wifi_cfg data structure on each call to start_listen. Same bug below with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually there are other existing bugs in this code that suggest wiping s_dpp_ctx.wifi_cfg on each invocation of esp_dpp_handle_config_obj is better. The caller even runs this function in a loop which seems clearly broken to me... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I must've missed this thanks to the two networks I tested with having the same passphrase, I'll have to look at wiping wifi_cfg. ty |
||
sizeof(wifi_cfg->sta.password)); | ||
if (conf->akm == DPP_AKM_PSK_SAE) { | ||
wifi_cfg->sta.pmf_cfg.required = true; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,2 @@ | ||
CONFIG_ESP_WIFI_MBO_SUPPORT=y | ||
CONFIG_ESP_WIFI_DPP_SUPPORT=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are trying to reproduce this issue and fix it. these are two separate features and should have no dependency on each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know they are very unrelated, however this change is the only one that's let dpp consistently work near perfectly, compared to barely working unless the listen channel was set to that of the ap and phone(dont know why its an issue since the qr has the channel + the esp sends on the correct channel anyways).
Without this fix,
esp_wifi_action_tx_req
would in most cases I tested, fail by sending theWIFI_EVENT_ACTION_TX_STATUS
event with a status=1, which in turn esp_dpp.c would send theESP_ERR_DPP_TX_FAILURE
event to the callback.Without this fix, it would take making the environmental conditions near perfect for me to get a moderate success rate, but with this fix, even going out of my way I cant intentionally cause the
WIFI_EVENT_ACTION_TX_STATUS
related error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw on 4.4.4 I could not reproduce MBO having an effect. What helped for me most was fixing the fact that retry doesn't work as it is supposed to in the example code (s_dpp_stop_listening is not reset on start_listen), then just spamming retry on my phone. It is possible this MBO feature does something, but it's gonna take some tough work to figure out why. What isn't up for debate tho is that DPP is highly unreliable for more than just me, and we definitely need to dig in and understand why.