Skip to content
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

Expose esp_wifi_set_mode functionality (to disable access point after initialization) #2224

Open
Karuso33 opened this issue Sep 24, 2024 · 3 comments
Labels
package:esp-wifi Issues related to the esp-wifi package

Comments

@Karuso33
Copy link

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

pub fn set_configuration(&mut self, conf: Configuration) -> Result<(), WifiError> {
    let wifi_mode = WifiMode::try_from(&conf)?;
    esp_wifi_result!(unsafe { esp_wifi_set_mode(wifi_mode.into()) })?;
    self.config = conf;

    match &self.config {
        Configuration::None => {
            return Err(WifiError::InternalError(
                InternalWifiError::EspErrInvalidArg,
            ));
        }
        Configuration::Client(config) => apply_sta_config(config)?,
        Configuration::AccessPoint(config) => apply_ap_config(config)?,
        Configuration::Mixed(sta_config, ap_config) => {
            apply_ap_config(ap_config)?;
            apply_sta_config(sta_config)?;
        }
        Configuration::EapClient(config) => apply_sta_eap_config(config)?,
    };

    Ok(())
}

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).

@Karuso33 Karuso33 added the status:needs-attention This should be prioritized label Sep 24, 2024
@ProfFan
Copy link
Contributor

ProfFan commented Sep 26, 2024

@Karuso33 Are you trying to make the ApSta and then use the raw interface for TX/RX of raw frames? I am trying to do the same here.

@bjoernQ
Copy link
Contributor

bjoernQ commented Sep 27, 2024

Thanks for the suggestion!

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>)

@Karuso33
Copy link
Author

Karuso33 commented Sep 27, 2024

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 (?)).

@jessebraham jessebraham added package:esp-wifi Issues related to the esp-wifi package and removed status:needs-attention This should be prioritized labels Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:esp-wifi Issues related to the esp-wifi package
Projects
Status: Todo
Development

No branches or pull requests

4 participants