Skip to content

Fix current_mode let statement to be after the adapter device is automatically powered on - #29

Closed
DreamTone wants to merge 1 commit into
e-tho:mainfrom
DreamTone:auto_power_on_fix
Closed

DreamTone wants to merge 1 commit into
e-tho:mainfrom
DreamTone:auto_power_on_fix

Conversation

@DreamTone

Copy link
Copy Markdown
Contributor

Issue:
Currently, if the adapter device is powered off and iwmenu is launched, iwmenu automatically powers on the adapter device. However, since current_mode is declared before the if !adapter.device.is_powered conditional, the menu remains on the Power On Adapter menu because current_mode doesn't reflect that the adapter device is now powered on. So, if you press Esc and relaunch iwmenu it then launches to the main menu. This is unexpected behavior as the adapter device is being powered on and the menu is stating that it's not.

Solution:
Re-sequence let current_mode = adapter.device.mode; to be after the if !adapter.device.is_powered conditional. This way, if the adapter device is powered off, when iwmenu is launched it powers on the adapter device and appropriately launches to the main menu.

Follow-Up PR:
I'm submitting an additional pull request to add a --no-auto-power-on argument so the user can decide if they want the device to power on automatically when iwmenu is launched. I find the default behavior to be undesirable for my use case. If I want the adapter device to be powered off, I don't want iwmenu turning it on by default, forcing me to power off the adapter device each time if I launch iwmenu. Adding a --no-auto-power-on argument maintains the current behavior by default unless the user chooses otherwise.

@e-tho

e-tho commented Aug 25, 2026

Copy link
Copy Markdown
Owner

This behavior isn't intentional, it is a bug. There's no need for an additional flag. iwmenu shouldn't automatically power on the adapter device. I'm closing this and the follow-up PR. Please reopen with a targeted fix.

@e-tho e-tho closed this Aug 25, 2026
@DreamTone

Copy link
Copy Markdown
Contributor Author

As I'm digging into this I think I need to check with you on the intent. I'm learning all this stuff as I'm going, so feel free to let me know where I'm off base.

There's the adapter (physical) and the device (logical). Both can be powered on and off with iwctl. If the adapter is powered off, the program exits with errors. If the device is powered off, the program can function fine.

For lines 38-44 in src/app.rs:

        if !adapter.device.is_powered {
            adapter
                .device
                .power_on()
                .await
                .with_context(|| "Failed to power on the adapter during initialization")?;
        }

Is the intent to turn on the adapter (not the device) without prompting the user. This seems like what the intent was based on the with_context string and that the current iteration of the project needs the adapter to be powered on to function. If this is the case then we need to replace it with:

        if !adapter.is_powered {
            adapter
                .power_on()
                .await
                .with_context(|| "Failed to power on the adapter during initialization")?;
        }

and add a function to src/iw/adapters.rs to turn the adapter on:

    pub async fn power_on(&self) -> Result<()> {
        self.adapter
            .set_power(true)
            .await
            .context("Failed to power on the adapter")
    }

Also, throughout the project there seems to be a lot of references to enabling and disabling the adapter but it's actually dealing with powering the device on and off.

If the idea is to give the user agency over the adapter power management (as well as powering on and off the device), then we'd need to add a power_off function and I think that brings us into modifying the menus and the code and strings to distinguish between the two.

Let me know what you're thinking. Like I said, I'm learning as I'm going here so if my thought process is off just tell me.

@DreamTone

Copy link
Copy Markdown
Contributor Author

I've thought it through and decided to run with an approach. I'll open a PR when I'm done and we can discuss.

@e-tho

e-tho commented Aug 26, 2026

Copy link
Copy Markdown
Owner

The auto power on behavior is a remnant from early development when there were no different navigation modes, and many features were unimplemented. In default mode (non-interactive), powering off should exit, while powering on should lead to the current iwd mode menu (Station/AP).

You're right about the device/adapter inconsistencies. The device-level control is correct for iwmenu, but the naming isn't. The Adapter properties aren't actually used either; another remnant from early development, thanks for bringing this up.

Since this required significant refactoring I've addressed it myself in recent commits. Feel free to check the changes if you're curious about the implementation, and to open other issues or PRs if you want to help improve the project.

@DreamTone

Copy link
Copy Markdown
Contributor Author

Hey, I took a look at your commits and we had similar thought processes. However, I wanted to make an attempt at implementing the adapter power on/off functionality into the project. I based it around your latest commits and submitted a new PR. We can discuss under that one. I hope you like the concept.

@DreamTone
DreamTone deleted the auto_power_on_fix branch August 28, 2026 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants