Errors when using Arcadyan TMO-G4AR gateway
Closed this issue · 4 comments
On my Chromebook with the latest chrome OS and the Arcadyan TMO-G4AR gateway that T-Mobile sent me, I get errors such as, for example, the one shown in the screen shot below. This one occurred after clicking Save when the 5GHz Power was lowered from 100% to 50%. The WiFi connection is dropped but re-establishes itself automatically. When it does so the setting is back to100%. BTW it would be nice if the power could be lowered to 10%. Is that possible?
I get similar errors when trying to change other parameters. Please let me know if you would like further details, copies of error messages, etc.
Yesterday's upgrade has fixed this particular error. That's appreciated. There are other errors such as the one I get when trying to turn off Band Steering.
I am new here, and I'm getting the same error with my Arcadyan TMO-G4AR. I was using the the Windows desktop build to lower the bandwidth on 2.4GHz to test. After console error, the GUI displayed all bands were off. See attachment below.
Console log:
dev.zwander.common.exceptions.TimeoutException: Request Timeout {status==408 headers==[content-length=[132],content-type=[application/json],date=[Sat, 13 Apr 2024 14:05:17 GMT],server=[lighttpd/1.4.69]] requestHeaders==[User-Agent=[homeisp/android/2.12.1],Authorization=[Bearer ****************************************],Accept=[application/json],Accept-Charset=[UTF-8]] requestBody== requestUrl==http://192.168.12.1/TMI/v1/network/configuration/v2?get=ap requestMethod==GET} { "result": { "error": "SetFailed", "message": "WiFi driver is busy. Please try again later.", "statusCode": 408 } } at dev.zwander.common.exceptions.StatusExceptionsKt.pickExceptionForStatus(StatusExceptions.kt:74) at dev.zwander.common.exceptions.StatusExceptionsKt.pickExceptionForStatus$default(StatusExceptions.kt:65) at dev.zwander.common.util.HTTPClient$DefaultImpls.setError(HTTPClient.kt:629) at dev.zwander.common.util.UnifiedClient.setError(HTTPClient.kt:977) at dev.zwander.common.util.HTTPClient$DefaultImpls.handleCatch$tryRequest(HTTPClient.kt:585) at dev.zwander.common.util.HTTPClient$DefaultImpls.access$handleCatch$tryRequest(HTTPClient.kt:490) at dev.zwander.common.util.HTTPClient$handleCatch$tryRequest$1.invokeSuspend(HTTPClient.kt) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at androidx.compose.ui.platform.FlushCoroutineDispatcher$dispatch$2$1.invoke(FlushCoroutineDispatcher.skiko.kt:62) at androidx.compose.ui.platform.FlushCoroutineDispatcher$dispatch$2$1.invoke(FlushCoroutineDispatcher.skiko.kt:57) at androidx.compose.ui.platform.FlushCoroutineDispatcher.performRun(FlushCoroutineDispatcher.skiko.kt:99) at androidx.compose.ui.platform.FlushCoroutineDispatcher.access$performRun(FlushCoroutineDispatcher.skiko.kt:37) at androidx.compose.ui.platform.FlushCoroutineDispatcher$dispatch$2.invokeSuspend(FlushCoroutineDispatcher.skiko.kt:57) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
The same thing used to happen on my chromebook under ChromeOS when trying to lower the 2.4GHz Power to 50%. However, when the WiFi connection re-established itself the Hint GUI displayed that both bands were on with the Power back to 100%. I say 'used to happen' because it no longer happens after I installed the April 4 upgrade from Google Play Store. You may want to try upgrading. Good luck.
The timeout error should be safe to ignore. Just manually refresh HINT Control to see updated values.
It's hard to handle this error since the WiFi driver can take up to a few minutes to finish updating its config. I've been working on dealing with it, but I don't think it'll ever be fully hidden unless I hardcode a 2-minute wait time like the T-Mobile app does.