Open jkrwdf opened 2 months ago
Hello! Thanks for reporting this. I'll look into a fix for this.
Thanks to OP for the hint with escaping the special characters xD I could've thought about it myself because I often do it in C# 😂
@zaneschepke I guess you could handle it by defining your own matching pattern (f.e. instead of "!" the end user has to use "((!))") and before evaluating the wildcard escape the normally used ones for example with " \" (excluding own matching pattern) and after that replace "((!))" again with "!". Just my first thought about how it could be handled without confusing the end user too much.
Yesterday I updated to version 3.6.0 which addresses this issue by introducing a new switch "Use name wildcards" by which the user can choose whether the content of the "Trusted wifi names" is literal strings (switch "off") or may contain (regex)-syntax (switch "on") and in this case a help-page explains how to handle special characters in the wifi name.
This issue can therefore be closed.
A tiny remark may be allowed: I had solved my issue by using a wildcard and maintained FOOBAR*
.
After the upgrade, I immediately noted that without me doing anything, the tunnel was unwantedly coming up.
Reason is that the new switch "Use name wildcards" is delivered by default with state "off", and that affects everyone who adapted his settings after the last update in September. Eventually in this situation (first start after upgrade, and wifi names contain wildcards) a toast-message would be useful.
Describe the bug Since the update to version 3.5.2, my home network was no longer recognized as trusted and the auto-tunnel kicked in. My home network is named
FOOBAR (5 GHz)
I believe the bug happens because with the new version, wildcard support based on regex was implemented, and the round brackets have a meaning there.
Experiment: When I change my trusted network entry in WG tunnel to either
FOOBAR*
FOOBAR \(5 GHz\)
it works again.
Smartphone (please complete the following information):