I recently updated my GL-AX1800 router to firmware version v4.7.0, and I've encountered a very annoying issue in the VPN Dashboard when trying to switch WireGuard servers:
When attempting to activate a different server, the following error appears on the first try: "Invalid parameter, operation failed. [-32602]"
Only after clicking a second time does the new VPN server get activated – clearly a faulty behavior and quite frustrating.
With the previous version v4.6.8, switching servers worked flawlessly – just one click on the desired WireGuard server and it would switch without any issues.
Unfortunately, this is yet another GL.iNet update that doesn't work smoothly for me. I'm seriously considering switching to a different router brand that delivers reliable firmware updates without these kinds of bugs.
Hello Bruce,
Further analysis is unfortunately no longer possible for me at this time.
I have reverted the router to firmware version 4.6.8 and will stick with this stable and reliably working version for the time being.
When resetting the software and subsequently restoring a backup, I assumed that all settings – including the VPN server, etc. – would be preserved. Unfortunately, I was once again proven wrong.
The issue typically occurs when I attempt to switch from one active WireGuard server to another.
I do not disconnect the current connection, but instead directly select a different WireGuard server from the list and click “Apply”.
With firmware version 4.6.8, this was not a problem – any WireGuard server could be seamlessly replaced during active operation.
When I now select a new server from the list while another WireGuard server is still active, the following error message appears in approximately 70% of cases: Invalid parameter, operation failed. [-32602]
For reference, I’m using Firefox as my browser. The same behavior also occurs in Chrome.
Just for clarification: the Surfshark servers I’m switching between are manually created configurations, not ones imported via the newly added provider feature introduced in version 4.7.0.
Based on current observations, the issue does not occur when Surfshark servers are added using the built-in “Surfshark” provider introduced in version 4.7.0 and then switched during active operation.
