RE: Router web-gui Authentication with admin & saving to browser (bug)
Software version: 1.2103.00.0338
Browsers: Safari, Firefox, Chrome, Vivaldi, Edge, Firedragon
OS Tested: MacOS 11.6.3 Big Sur - Windows 10 (current updates) - Linux
NOTE: The nature of this behavior ONLY presents when one saves the admin authentication information in the browser. If the admin account authentication information is NOT saved to the browser this behavior is not seen. I have not seen other reports of this behavior but it only very recently surfaced for me due to the need to make a couple of changes. I previously had NO issue with the saved information and the one obvious factor that stands out to me is the newer 0338 code in the router.
First encountered with Safari on MacOS 11.6.3 & Firefox with 1.2103.00.0338
Characteristics: If the admin user credentials are saved in either of these two browsers there will be a prompt that presents to save updated authentication each time the authenticated “admin” leaves a given configuration level/interface. i.e. global admin level, 2.4Ghz channel config level, 5GHz channel configuration level. The prompt will present incorrect information populated in the user and password fields. NOTE: The behavior is worse in Safari as once the problem presents if you close out of the 192.168.12.1 web-gui interface and try to even authenticate as user admin to make changes it will NOT let you in. If you check the saved credentials they will appear correct but will no longer work for some reason.
Note: If you enter the 2.4Ghz or 5Ghz channel configuration and exit the window will open requesting to save the updated authentication information. (This will vary between the exit of the 2.4Ghz and 5Ghz config)
When exiting the 2.4Ghz channel config to navigate to say 5GHz the window prompts with no username and the password field is populated with the WPA Key associated with the SSID for the 2.4GHz channel.
When exiting the 5GHz channel configuration the window prompts with the username = (whatever is the value of the Max Users Field) [With the .0338 code it will be 128] The password field will be populated with the value of the WPA Key. Like you would ever want to do this?
I know the supported Max number of clients by T-Mobile is 64 not 128 so I changed the values from 128 to 64. Upon doing this change I could see the user value change from 128 to 64 so i knew where the mysterious value came from. I figured if it pulled the WPA Key up for password the username had to come from another incorrect pointer value.
I have confirmed the behavior with both Safari and Firefox on MacOS 11.6.3 & with Firefox on a Windows 10 client (current with all updates). The W10 client is too old for W11 & I have no desire to go there so I cannot report behavior on Windows 11. With Garuda Linux Dragonized with the Firedragon browser using the authentication save and autofill the problem does not present. Garuda has Arch linux under the hood and Firedragon is a tuned up version of Firefox. This is a bit of an outlier but an interesting data point. Running Linux Mint 20.2 Uma base and using Firefox with the authentication save/autofill the problem does present.
While on a call to T-Mobile support I ran testing with Vivaldi and Edge on the Windows 10 client without saving any authentication information to the browser. Both browsers worked with the T-Mobile web-gui client and did not present the behavior. I did NOT confirm if they would do so with saved authentication. I do expect it is highly probable the same behavior would surface. Since I have seen this behavior with MacOS, Windows 10 & Linux with different browsers I suspect the common factor to be the T-Mobile web-gui software version 1.2103.00.0338.
Remediation/Workaround:
If the authentication is saved in the browser remove it and completely restart the browser. Do not save the user “admin” authentication to the browser and the problem will not present.
