Stricter WiFi callback #4616
Merged
Stricter WiFi callback #4616
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
successful in the connection callback. Dry-coded, WIP. Re koreader#2183
|
Possibly needs testing on Cervantes, as @pazos suggested. Appears to behave on Kobo, but then I don't have connectivity/password issues, so the extent of my test was inverting the logic to kill wifi on a successful connection ;). The Kindle case should be harmless (and beneficial there too, because ET call home). |
|
Limit the whole thing to Kobo/Cervantes, the only two platforms where we load/unload kernel modules. Because the connection check could be actively harmful on platforms where WiFi handling is always asynchronous, as there's a good chance the callback will run before WiFi is properly brought up. |
mwoz123
pushed a commit
to mwoz123/koreader
that referenced
this pull request
Mar 29, 2020
* Double-checks that the connection was successful, and forcefully kills WiFi if it didn't, to avoid leaving stuff in an inconsistent state. Should fix koreader#2183 * Limit the turnOffWifi call to devices where it might make some sense to do
NiLuJe
added a commit
to NiLuJe/koreader
that referenced
this pull request
Apr 19, 2021
successful authentication. Fully tearing down Wi-Fi was a bit optimistic, as the AP list can technically still be up, so the user might want to try again and/or connect to another AP. Fix koreader#5912, regression since koreader#4616. The reasoning behind koreader#4616 doesn't really apply anymore anyway, as the Wi-Fi prompt now handles this inconsistent state properly. The whole codepath should be *extremely* rare anyway (and/or require super-broken network conditions).
Frenzie
pushed a commit
that referenced
this pull request
Apr 19, 2021
successful authentication. Fully tearing down Wi-Fi was a bit optimistic, as the AP list can technically still be up, so the user might want to try again and/or connect to another AP. Fix #5912, regression since #4616. The reasoning behind #4616 doesn't really apply anymore anyway, as the Wi-Fi prompt now handles this inconsistent state properly. The whole codepath should be *extremely* rare anyway (and/or require super-broken network conditions).
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.
Double-checks that the connection was successful, and forcefully kills WiFi if it didn't, to avoid leaving stuff in an inconsistent state.
Should fix #2183