You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to initialize the Wifi interface in ApSta mode and later disable the access point (and switch to Sta mode). This is so that the device can be accessed via the access point to configure it. Afterwards, the access point should disappear and be inaccessible (this is especially relevant because the "obvious hack" of making the AP hidden with a password does not work in esp-wifi, as it does not support password protected APs right now).
As far as I can tell, this is possible in esp-idf through esp_wifi_set_mode. I propose to change WifiController::set_confguration so that it just infers the mode from the configuration that was passed in, i.e. something like this
I think this approach also somewhat simplifies the amount of validation (see here) that has to be done in set_configuration.
I did try out this change locally and it seems to work and do what it should (though I am not deeply familiar with esp-wifi or esp-idf, so this might be subtly broken).
The text was updated successfully, but these errors were encountered:
I think we could allow to degrade from ApSta to either Ap or Sta but we cannot allow going from Ap to Sta, Sta to Ap etc. since the user doesn't have access to the device/interface
But we should do that by either consuming the ap-device/ap-interface or the sta-device/sta-interface since otherwise the user could try to continue using them.
Maybe something like shutdown_access_point(interface: Interface, device: WifiDevice<'d, WifiApDevice>)
As I said, I am not deeply familiar with the code base, so take everything I say with a grain of salt. But I think it might actually be kind of fine to let the user keep control of the WifiApDevice, even when the Ap is shut down. When the user tries to send data over that device esp_wifi_send_data is eventually called, and that just calls into the C library (esp_wifi_internal_tx). And I think that call would just fail more or less silently (the failure is logged, but not returned to the caller; the error is 12294 - ESP_ERR_WIFI_STATE).
While failing silently is not ideal, it is pretty much the same situation that the user currently faces when trying to send data in Sta mode, while not connected to an access point (that also returns 12294 - ESP_ERR_WIFI_STATE). And I feel like if that behavior is okay in Sta mode, then it would also not be the worst thing to have this behavior for Ap mode as well.
I think that this is realistically the best solution there is here. Especially since it is not possible to "get back" the WifiApDevice once an embassy-net Stack has been constructed (there is no .into_inner() or similar, maybe there should be (?)).
I would like to initialize the Wifi interface in ApSta mode and later disable the access point (and switch to Sta mode). This is so that the device can be accessed via the access point to configure it. Afterwards, the access point should disappear and be inaccessible (this is especially relevant because the "obvious hack" of making the AP hidden with a password does not work in esp-wifi, as it does not support password protected APs right now).
As far as I can tell, this is possible in esp-idf through
esp_wifi_set_mode
. I propose to changeWifiController::set_confguration
so that it just infers the mode from the configuration that was passed in, i.e. something like thisI think this approach also somewhat simplifies the amount of validation (see here) that has to be done in
set_configuration
.I did try out this change locally and it seems to work and do what it should (though I am not deeply familiar with esp-wifi or esp-idf, so this might be subtly broken).
The text was updated successfully, but these errors were encountered: