WiFi dialog: add new dialog to UI #1810
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jun 25, 2024
|
Superseded by #1813. |
jotaen4tinypilot
added a commit
that referenced
this pull request
Jul 5, 2024
Related #131, parts (a) and (b). This PR adds two scripts for enabling and disabling the WiFi network interface on the device, so that you can also access TinyPilot through a wireless network connection. I already discussed the basic approach last week with Charles (see comment and discussion below), because of his familiarity with networking/WiFi. Since then, I did more testing in various scenarios, and also already opened two subsequent draft PRs for the [backend](#1805) and [frontend](#1810). They are WIP still, but they may give a rough impression of how the WiFi feature will look in its entirety. Overall, it seems to be looking good, so I thought it might make sense to already start the review process. A few notes on the implementation: - We write into the `wpa_supplicants.conf` file directly to configure the WiFi connection, and we use the marker-section mechanism to manage the TinyPilot-specific part of the configuration. Depending on whether the WiFi network is password-protected or not, we either use the `wpa_passphrase` command, or we generate the config section manually. - I’m not sure it’s worth to validate the `--country` input value in the `enable-wifi` script: I’d plan to do validation in the backend later on, and the network service seems to behave graceful against invalid country codes. For the `--psk` flag, we have to do a basic length validation, because otherwise the `wpa_passphrase` command would fail. - For testing on device, you can use the `ifconfig` command to check whether the `wlan` network interface is up and active. (I.e., whether `ifconfig` outputs a `wlan` block, and whether that has a `inet`/`inet6` address assigned to it.) --- ### Original draft PR comment (2024-06-13) This PR is a draft for now, because I wanted to evaluate the technical approach of the underlying WiFi-related logic first, before investing time into the implementation of the application logic (i.e., the Python part and the UI). I saw that you @cghague have been involved into [our WiFi FAQ document](https://github.com/tiny-pilot/tinypilotkvm.com/blob/46696cc1698e1eb73051616423ab3c6b09a4f5e1/content/faq/enable-wifi/index.md), so I was hoping that you are maybe familiar with the technical domain. Could you look over the privileged scripts of this PR and give me some initial, high-level feedback about whether the proposed approach seems sensible to you? At this point, I’d mainly like to avoid going into a wrong direction, or to miss any potential caveats or other issues I may have forgotten to consider. A few notes on the implementation: - For the purposes of #131, we need to fully automate the logic for enabling and disabling WiFi, so that we can invoke both procedures from the Python backend programmatically. The `enable-wifi` script obviously would have to parse CLI arguments to parametrize the SSID, PSK, and country code. The `disable-wifi` script wouldn’t take any arguments. - I’ve successfully tested the scripts on my device, and so far they appear to work fine. By issuing `rfkill unblock wifi` and `wpa_cli -i wlan0 reconfigure`, it seems to be possible to effectuate the changes and activate WiFi without having to reboot the device. This would make things easier for us in the UI, but it would also be more convenient and snappier for the end-user. - My thinking was that it doesn’t make sense to use the `raspi-config` tool in the scripts, because that seems to be too limited. For example, we don’t want to just keep adding new WiFi configs to the `wpa_supplicant.conf` file, but we basically want to maintain *one* “TinyPilot-owned” custom WiFi config, which we then also can delete or modify in a targeted way. For this, it seemed more sensible to me to write into the `wpa_supplicant.conf` file directly, using the [marker-section technique](https://github.com/tiny-pilot/tinypilot/blob/9bbc056c6e4dcec1804b99b3cdcbd0bcdf1ca0dc/debian-pkg/opt/tinypilot-privileged/scripts/lib/markers.sh) that we already employ elsewhere. The downside is that this requires more low-levelled logic on our side. If you’d generally agree with the proposed approach and underlying reasoning, I’d proceed to wrap up this PR and to build the surrounding application logic. <a data-ca-tag href="https://codeapprove.com/pr/tiny-pilot/tinypilot/1804"><img src="https://codeapprove.com/external/github-tag-allbg.png" alt="Review on CodeApprove" /></a> --------- Co-authored-by: Jan Heuermann <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related #131, parts (d). Still work in progress for now.
