Fix for TMOHS1 and CT2MHS01 dropping Wifi AP after 10 min#951
Fix for TMOHS1 and CT2MHS01 dropping Wifi AP after 10 min#951cooperq merged 1 commit intoEFForg:mainfrom
Conversation
338c75c to
59067a7
Compare
|
Do either of those devices not have their own admin UI where this setting can be changed? That's how I deal with it on tplink. |
I didn't see one, although admittedly it's been a while since I checked the default interface the thing ships with. My concern is mostly for folks who install this, then don't read a ton of documentation and just think it's broken and dump it. |
cooperq
left a comment
There was a problem hiding this comment.
I would like to make sure that this feature isn't already supported in the native UI before we merge this code. This does add some amount of complexity that we don't necessarily need to add if we are able to fix it in the native settings and could just add that to the documentation.
59067a7 to
07eda5b
Compare
|
@cooperq I reverted the files I changed and instead added documentation as well as screenshots (and a hint in the installer) indicating where the users can set the wifi timeout using native settings. |
Both devices ship with a Wi-Fi Standby timer that turns off the AP after ~10 minutes with no clients, blocking remote access to Rayhunter until a power cycle. Previous attempt (this PR's earlier commits) added a Rayhunter config toggle to flip gWlanAutoShutdown in WCNSS_qcom_cfg.ini, but the same setting is already exposed in each device's native admin UI under Settings -> Sleep -> Wi-Fi Standby, so a code change is not needed. Replace the config toggle with: - Device-page walkthroughs with screenshots of each native UI setting - FAQ entry for "can't reach the web UI after leaving it alone" - Post-install hint from the tmobile/wingtech installers pointing at the docs and the setting location
07eda5b to
e198040
Compare
Pull Request Checklist
cargo fmt.You must check one of:
When these two devices don't have any clients on their wifi AP after 10 minutes they shutdown the wifi. This presents an issue since then the user can't access the device without manual intervention. I added a checkbox (near where the colorblind checkbox is) in the config section that will change a config value to prevent the wifi from shutting down if there's no clients. It's off by default, and only shows on those 2 models.
I tested it on both the devices by deploying the change, waiting 10 minutes without connecting and confirmed that this fixes the issue. Based on a review of issues it looks liek this is a potential fix for #466. If the user was on their home wifi rather than the devices wifi and it took 10 minutes they could see what appears to be a device which doesn't have wifi available (and had a failed install due to the timeout issue I'm fixing in another PR).
I DID use Claude to add the quick button on the web GUI, although I've deployed this and exercised the web GUI myself.