Thanks for your advice. In my case, The = is definitely missing on the Tunnels page using the latest firmware. The screenshots were taken on the same monitor and Firefox 79 in full screen mode. You can clearly see, that it is not a matter of the size of the box. Even if I use the cursor to get to the end or ctrl+a and ctrl+c: there is no =at the end. Even tried it on an iPad, same result.
The = is also missing when I retrieve the key via nvram get oet1_public or oet1_peerkey0. So it is not just a cosmetic problem. Before the upgrade keys are correct. After the upgrade, all keys are missing the = at the end. Just tried to connect via iPad and iPhone using existing WireGuard settings (= at the end). Works! The WireGuard log on iOS shows that the expected key (without =) was found! What??
Trying to change the Settings on the iOS app (remove =) gives an error message that this is not a valid key in 32 bit and base64 encoding.
My conclusion: The upgrade somehow breaks / alters the stored key settings by deleting / overwriting the last byte in the NVRAM settings. But this does obviously not affect establishing the connection with “almost” correct keys.
I know this looks like I made it all up, but this is really as it is.
The screenshots were taken directly before and after the upgrade. I did not change anything else at all. I experienced this behavior before when upgrading to 44213. This is why I took the screenshots this time.
Sorry to bother you with this really strange behavior, but I am just curious what is going on here.
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Mon Aug 24, 2020 20:00 Post subject:
NFear wrote:
Hi egc,
Thanks for your advice. In my case, The = is definitely missing on the Tunnels page using the latest firmware. The screenshots were taken on the same monitor and Firefox 79 in full screen mode. You can clearly see, that it is not a matter of the size of the box. Even if I use the cursor to get to the end or ctrl+a and ctrl+c: there is no =at the end. Even tried it on an iPad, same result.
The = is also missing when I retrieve the key via nvram get oet1_public or oet1_peerkey0. So it is not just a cosmetic problem. Before the upgrade keys are correct. After the upgrade, all keys are missing the = at the end. Just tried to connect via iPad and iPhone using existing WireGuard settings (= at the end). Works! The WireGuard log on iOS shows that the expected key (without =) was found! What??
Trying to change the Settings on the iOS app (remove =) gives an error message that this is not a valid key in 32 bit and base64 encoding.
My conclusion: The upgrade somehow breaks / alters the stored key settings by deleting / overwriting the last byte in the NVRAM settings. But this does obviously not affect establishing the connection with “almost” correct keys.
I know this looks like I made it all up, but this is really as it is.
The screenshots were taken directly before and after the upgrade. I did not change anything else at all. I experienced this behavior before when upgrading to 44213. This is why I took the screenshots this time.
Sorry to bother you with this really strange behavior, but I am just curious what is going on here.
Could you be running out of nvram space?
If the peer key is really missing the = then you should not be able to make a connection.
The local public key is derived from the private key but not if the private key is missing the = then the local public key is not even calculated.
The local public key is derived from the private key but not if the private key is missing the = then the local public key is not even calculated.
Maybe it is just a clever implementation. WireGuard keys always end with an =. Thus, you can save memory by omitting the = when saving individual keys. The key calcualation should be independent of the = at the end. It is neither a "real" part of the key, nor a checkdigit, but an identifier. The real key seems to be the part before the =.
Joined: 09 Nov 2014 Posts: 314 Location: Bakersfield, CA
Posted: Thu Aug 27, 2020 12:51 Post subject:
Router/Version: 4x Netgear R7000
Firmware: DD-WRT v3.0-r44236 std (08/22/20)
Kernel: Linux 4.4.232 #911 SMP Fri Aug 21 08:45:00 +04 2020 armv7l
Previous: DD-WRT v3.0-r44213 std (08/18/20)
Mode: Two Gateways, Two Client Bridges
Reset: No
Status: Seems good to go so far! Will report back if something comes up _________________ Deployed Routers:
Netgear R7800 - 1x build 46979
- Gateway (USB /w Entware, CAKE QoS)
Netgear R7000 - 3x build 46979
Router: ASUS AU68
Firmware: Firmware: DD-WRT v3.0-r44236 std (08/22/20)
Kernel: Linux 4.4.232 #911 SMP Fri Aug 21 08:45:00 +04 2020 armv7l
Previous version: 44085
Mode: Gateway
reset: No
Status:
DNS Issues (DNS_PROBE_FINISHED_BAD_CONFIG) start showing up after about 24 hrs. Occurs both with and without SmartDNS resolver enabled. Multiple retries will eventually get a name resolved. Rebooting router seems to improve the situation for a while. DNSMasq is enabled.
Following DNS features Enabled:
DNSmasq
Cache DNSSEC data
Check unsigned DNSreplies
No DNS rebind
RFC 4039 Rapid commit support
Max cached entries=19500
NSLOOKUP returns immediately when using google and times out using router
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Mon Aug 31, 2020 16:36 Post subject:
NetSonic wrote:
Router Model / Version: Netgear r8000
Previous Firmware: --- (Tomato firmware)
Current Firmware: DD-WRT v3.0-r44251 std (08/27/20)
File: netgear-r8000-webflash.bin
Kernel: Linux 4.4.233 #936 SMP Thu Aug 27 17:44:00 +04 2020 armv7l
Reset: Yes. Once before, once after
Mode: Wireless - AP
Setup: Basic
Issues: In Setup > Networking > Assign to Bridge, wireless interfaces are missing from the "Interfaces" column. The result is that you cannot assign a wireless interface to a bridge you create. I am attaching an image to illustrate this problem.
