Custom firmware build for R7800 v. 1.0.2.47SF

[vladlenas]

New version of Voxel custom firmware build: 1.0.2.47SF.

Changes (vs 1.0.2.46SF):

1. Latest QoS DB is included into firmware (23 Oct 2017).
2. Disk mount scheme is changed to correct problems with folder browser in NETGEAR Downloader (reported by cordezz).
3. e2fsprogs package is upgraded 1.43.8->1.43.9.
4. ethtool package is upgaded 4.13->4.15.
5. libubox package is upgraded 2018-01-07->2018-02-08.
6. netatalk package is upgraded 2.2.1->2.2.6
7. Some "clip-art" changes in WebGUI.

The link is:

https://www.voxel-firmware.com

P.S. Voxel is still terribly busy, and there is no time to read and answer questions.
Thank you for understanding!!!

 

[RogerSC]

Sorry that Voxel is over-committed, hope he gets through this period without getting too stressed out.

This firmware release is working well for me. And it's nice to have a little something different to look at in the web admin GUI. It really needs to be updated/revised in some areas...a big one is the mess of an "Attached Devices" list that's there now. It's way too spread out if you have a lot of clients. I also like the dd-wrt method of having two lists, one list is static and lists all the current client leases. The other is a list of the currently active clients. All that the Netgear "Attached Clients" list shows is currently active clients, which is a shorter, constantly changing list. Without the list of all client leases, the currently active client list is very hard to use. It would be very easy to blend this into the current list, you could simply have a choice between "tiled" list as it is now, or "detailed" list, which would be just one text line per client.

Lots of work could be put in on the web admin interface GUI if there's ever time to do it. Nonetheless, .47SF is running well for me *smile*.

Thanks!

 

[stealth_lee]

Sorry, a quick newbie question here.
Does updating to V1.0.2.47SF, overwrites the user created OpenVPN server *.crt, *.key, dh*.pem files?
Maybe I overlooked something but I experience this with past versions.
Is there any way to updating Voxel's new firmware that will keep OpenVPN server cert/key files and not to overwrite with default ones?

 

[Alex Wood]

Hi
Just wanted to report that upgrading to V1.0.2.47SF unfortunately has turned off support for Nat Loopback\Nat Hairpinning (the ability to use your external dynamic dns url that points to an internal device on your network instead of using the internal ip address it example.com:12345\myservice instead of 192.168.1.2 and is quite handy if you need to use only one address and access the service from outside and inside your network, like for personal cloud storage, etc).
I'm going to reset to factory settings and see if that fixes it (it did the first time I ever used Voxel's firmware), but I was wondering if anyone could suggest ways of doing the following (just to save having to re-enter info after ever reset to factory settings):
Is there a way to save ONLY the following config info:

• Port Forwards and Assigned Service Names
  
• DHCP Reservations\static IP addresses and their assigned device names
  
• WiFi SSIDs and Passwords
• Maybe Attached Devices: Device Type,Type and Priority

Just this info can take hours to re-enter and is the same no matter what the firmware revision, so should be safe to reapply whatever. Whereas applying a full backup of your config between firmware revisions can apply settings hidden in the background.
Alex
PS editing the cfg file would be great too, but after googling for an hour I see that is not possible (the binary file is unreadable in notepad++, unrecognised by linux 'file' and unmountable in linux or viewable by parted)

 

[Voxel]

Sorry that Voxel is over-committed, hope he gets through this period without getting too stressed out.

Thank you. I am sorry for my disappearing: not planned overload, I have to release two articles for a journal (in my main job). Thanks to vladlenas who published this thread. Now time frame, so I am back .

Probably I've missed something, so guys, write here in this thread again...

Voxel.

 

[Voxel]

Just wanted to report that upgrading to V1.0.2.47SF unfortunately has turned off support for Nat Loopback\Nat Hairpinning

I am not sure, but probably you are mistaken. I can use my port forwarding addressing to external IP. It works for me with external IP (incoming port is different from the port in LAN), but not if using LAN.

I was wondering if anyone could suggest ways of doing the following (just to save having to re-enter info after ever reset to factory settings):
Is there a way to save ONLY the following config info:

• Port Forwards and Assigned Service Names
  
• DHCP Reservations\static IP addresses and their assigned device names
  
• WiFi SSIDs and Passwords
• Maybe Attached Devices: Device Type,Type and Priority

There is a way I use for my own needs, but it requires telnet/ssh and some manual job with nvram command. All these settings are kept in nvram. To get e.g. your Port Forward you should run:

nvram show | grep forwarding

you will see your forwarding rules, for example:

forwarding1=HTTP↔to↔Server TCP 80 80 80 80 192.168.10.100 0 1

Now to restore this forwarding1 after reset you just need to run from command prompt:

nvram set "forwarding1=HTTP↔to↔Server TCP 80 80 80 80 192.168.10.100 0 1"

and after all such settings just run "nvram commit" to make your changes permanent.
I have a script which restores all my selective settings (editing the output of "nvram show" command).

Values in nvram you may need:

nvram show | grep reservation
nvram show | grep sysDNS
nvram show | grep wla_ssid
nvram show | grep wl_ssid
nvram show | grep wla_wpa2_psk
nvram show | grep wl_wpa2_psk

I just stored all such values in the text file and edited it to make a script which restores these settings to do not do a manual job.

Voxel.

 

[cordezz]

Hi Voxel,
I repost the ftp problem from https://www.snbforums.com/threads/c...r-r7800-v-1-0-2-46sf.44387/page-2#post-382537 here again. With the 1.0.2.47SF it doesnt work either.

Now another problem:
I cant create folders via ftp connection on my usb devices (no matter if fat usb stick oder ntfs hdd), the ftp client says "operation not permitted". But I can creat new files on the usb device or rename or move folders
I tried it with or without read/write access password in the adv. settings, restartet the router... no change.
Creating folders via nfs works, but that isnt an option for me, because my backup progamm in my smartphone uses ftp.

Could anybody please check if that is a general problem? I think some time ago it worked...

I found the config file of the ftp server and I think that everything is set correctly:

root@R7800:/tmp$ cat proftpd.conf
ServerName              NETGEAR-R7800
ServerType              standalone
UseReverseDNS           off
Umask                   022
Port                    21
MaxInstances            30
AllowOverwrite          on
AuthOrder               mod_auth_unix.c
ScoreboardFile          /tmp/run/proftpd.scoreboard
PidFile                 /tmp/run/proftpd.pid
UseEncoding             UTF-8 UTF-8
DefaultServer           on
<IfModule mod_delay.c>
        DelayEngine off
</IfModule>
<Global>
        AllowOverwrite          on
        User                    root
        Group                   root
        DefaultRoot             ~
        <Directory /tmp/ftpadmin/shares/USB_1>
        AllowOverwrite    on
                <Limit DIRS>
                        DenyAll
                        AllowUser admin
                </limit>
                <Limit Read>
                        DenyAll
                        AllowUser admin
                </Limit>
                <Limit Write>
                        DenyAll
                        AllowUser admin
                </Limit>
        </Directory>
        <Directory /tmp/ftpadmin/shares/Medienserver>
        AllowOverwrite    on
                <Limit DIRS>
                        DenyAll
                        AllowUser admin
                        AllowUser guest
                </limit>
                <Limit Read>
                        DenyAll
                        AllowUser admin
                        AllowUser guest
                </Limit>
                <Limit Write>
                        DenyAll
                        AllowUser admin
                        AllowUser guest
                </Limit>
        </Directory>
</Global>
        Include /tmp/ftp_anony.conf
DefaultAddress    192.168.178.5

/EDIT: I just restored factory defaults with Voxels 1.0.2.46SF and the problem still exists. After a downgrade to the official 1.0.2.44 folder creation via ftp works. Updated again to 1.0.2.46SF and cant create folders :/

 

[Voxel]

Now another problem:
I cant create folders via ftp connection on my usb devices (no matter if fat usb stick oder ntfs hdd), the ftp client says "operation not permitted". But I can creat new files on the usb device or rename or move folders
I tried it with or without read/write access password in the adv. settings, restartet the router... no change.
Creating folders via nfs works, but that isnt an option for me, because my backup progamm in my smartphone uses ftp.

Could anybody please check if that is a general problem? I think some time ago it worked...

You problem is related to permissions. There are two users for FTP: admin and guest. And admin is not the root user. So when you started to use EXT4, the owner of your folders on your disk is root. And admin (or guest) have no rights to create/change/rename folders/files because of their owner is root.

You should for example enter by telnet/ssh to router login, make the folder on your disk e.g. "FTP-backup" and change its owner to admin.

cd /mnt/sda1
mkdir FTP-backup
chown admin.admin FTP-backup

after that you can create/change/rename etc any files/folder in /mnt/sda1/FTP-backup directory by FTP using admin login.

NTFS or FAT do not keep such permissions. But this is Linux, so current "problems" with permissions are good for security reasons.

Voxel.

 

[cordezz]

You problem is related to permissions. There are two users for FTP: admin and guest. And admin is not the root user. So when you started to use EXT4, the owner of your folders on your disk is root. And admin (or guest) have no rights to create/change/rename folders/files because of their owner is root.

That was my first thought, too.
But my hdd is still formatted in NTFS and I tried a FAT32 usb-stick, too. It is still the same problem.
When I flash the official Netgear firmware it works.

 

[Voxel]

That was my first thought, too.
But my hdd is still formatted in NTFS and I tried a FAT32 usb-stick, too. It is still the same problem.
When I flash the official Netgear firmware it works.

I would not recommend to use FAT32/NTFS/HFS/HFS+ for a disk permanently attached to router. It is Linux and its native filesystems are EXT2/3/4. I faced several crashes of filesystem formatted as HFS when it was used with this router.

Changing owner to admin works with EXT4 (I tested right now, through FTP access by admin).

Voxel.

 

[cordezz]

I can see on my ntfs hdd the user root for all folders. And I can change it to admin.admin, but that does not solve the problem (obviosly because it is not ext4 but ntfs).
I know that ext4 is recommend, but at least fat32, which has no permission management should work. That is really strange...

 

[limbus]

Hi Voxel

I am using build V1.0.2.47SF on r7800 with openvpn-client running, everything is ok. But after rebooting the router, I have to start the openvpn-client manually (by using telnet commands).
Is it possible to get the openvpn-client to start running automatically, after a reboot?

 

[Voxel]

Hi Voxel

I am using build V1.0.2.47SF on r7800 with openvpn-client running, everything is ok. But after rebooting the router, I have to start the openvpn-client manually (by using telnet commands).
Is it possible to get the openvpn-client to start running automatically, after a reboot?

You should check openvpn client log. By design client should be started right after reboot automatically. So something is wrong. Log will help to understand what.

Voxel.

 

[limbus]

You should check openvpn client log. By design client should be started right after reboot automatically. So something is wrong. Log will help to understand what.

Voxel.

USB file looks like this:

/openvpn-client/



.opvn file looks like this:

client
dev tun
proto udp
remote dk.mullvad.net 1194
resolv-retry infinite
keepalive 10 60
nobind
persist-key
persist-tun
cipher AES-256-CBC
auth sha1
tls-client
remote-cert-tls server
comp-lzo
verb 1
reneg-sec 0
auth-user-pass /etc/openvpn/config/client/auth.txt
crl-verify /etc/openvpn/config/client/mullvad_crl.pem
ca /etc/openvpn/config/client/mullvad_ca.crt
disable-occ


Log look like this:

Wed Dec 20 01:00:05 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [L
ZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Wed Dec 20 01:00:05 2017 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Wed Dec 20 01:00:05 2017 NOTE: the current --script-security setting may allow
this configuration to call user-defined scripts
Wed Dec 20 01:00:05 2017 RESOLVE: Cannot resolve host address: dk.mullvad.net:1
194 (Name or service not known)
Wed Dec 20 01:00:05 2017 RESOLVE: Cannot resolve host address: dk.mullvad.net:1
194 (Name or service not known)
Wed Dec 20 01:00:05 2017 Could not determine IPv4/IPv6 protocol
Wed Dec 20 01:00:05 2017 SIGUSR1[soft,init_instance] received, process restarti
ng
Wed Dec 20 01:00:10 2017 NOTE: the current --script-security setting may allow
this configuration to call user-defined scripts
Wed Dec 20 01:00:10 2017 RESOLVE: Cannot resolve host address: dk.mullvad.net:1
194 (Name or service not known)
Wed Dec 20 01:00:10 2017 RESOLVE: Cannot resolve host address: dk.mullvad.net:1
194 (Name or service not known)
Wed Dec 20 01:00:10 2017 Could not determine IPv4/IPv6 protocol
Wed Dec 20 01:00:10 2017 SIGUSR1[soft,init_instance] received, process restarti
ng
Wed Dec 20 01:00:15 2017 NOTE: the current --script-security setting may allow
this configuration to call user-defined scripts
/var/log/openvpn-client.log
root@R7800:/$ /etc/init.d/openvpn-client start
Please wait...
Error: OpenVPN client start failed.
root@R7800:/$
root@R7800:/$ more /var/log/openvpn-client.log

 

[limbus]

After reboot

First i got this:

Wed Dec 20 01:00:15 2017 Restart pause, 5 second(s)
Wed Dec 20 01:00:20 2017 NOTE: the current --script-security setting may allow
this configuration to call user-defined scripts
Wed Dec 20 01:00:20 2017 TCP/UDP: Preserving recently used remote address: [AF_
INET]185.206.224.119:1302
Wed Dec 20 01:00:20 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Wed Dec 20 01:00:20 2017 UDP link local: (not bound)
Wed Dec 20 01:00:20 2017 UDP link remote: [AF_INET]185.206.224.119:1302
Wed Dec 20 01:00:20 2017 TLS: Initial packet from [AF_INET]185.206.224.119:1302
, sid=a3dc0e6a 09956150
Wed Dec 20 01:00:20 2017 VERIFY ERROR: depth=0, error=CRL is not yet valid: C=N
A, ST=None, L=None, O=Mullvad, CN=dk4.mullvad.net, emailAddress=info@mullvad.ne
t
Wed Dec 20 01:00:20 2017 OpenSSL: error:14090086:lib(20):func(144):reason(134)
Wed Dec 20 01:00:20 2017 TLS_ERROR: BIO read tls_read_plaintext error
Wed Dec 20 01:00:20 2017 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 20 01:00:20 2017 TLS Error: TLS handshake failed
Wed Dec 20 01:00:20 2017 SIGUSR1[soft,tls-error] received, process restarting
Wed Dec 20 01:00:20 2017 Restart pause, 5 second(s)
Error: OpenVPN client start failed.
Wed Dec 20 01:00:24 2017 SIGTERM[hard,init_instance] received, process exiting


Then i try to manually start via telnet: "/ect/init.d/openvpn-client start"

And i got this:

Wed Dec 20 01:00:20 2017 Restart pause, 5 second(s)
Error: OpenVPN client start failed.
Wed Dec 20 01:00:24 2017 SIGTERM[hard,init_instance] received, process exiting
Fri Mar 2 23:55:44 2018 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [L
ZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Mar 2 23:55:44 2018 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Fri Mar 2 23:55:44 2018 NOTE: the current --script-security setting may allow
this configuration to call user-defined scripts
Fri Mar 2 23:55:44 2018 TCP/UDP: Preserving recently used remote address: [AF_
INET]82.103.140.213:1302
Fri Mar 2 23:55:44 2018 Socket Buffers: R=[163840->163840] S=[163840->163840]
Fri Mar 2 23:55:44 2018 UDP link local: (not bound)
Fri Mar 2 23:55:44 2018 UDP link remote: [AF_INET]82.103.140.213:1302
Fri Mar 2 23:55:44 2018 TLS: Initial packet from [AF_INET]82.103.140.213:1302,
sid=f9c99e43 18a2af34
Fri Mar 2 23:55:44 2018 WARNING: this configuration may cache passwords in mem
ory -- use the auth-nocache option to prevent this
Fri Mar 2 23:55:44 2018 VERIFY WARNING: depth=1, unable to get certificate CRL
: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net, emailAddress=info@mu
llvad.net
Fri Mar 2 23:55:44 2018 VERIFY WARNING: depth=2, unable to get certificate CRL
: C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA, emailAddress=info@mullvad.ne
t
Fri Mar 2 23:55:44 2018 VERIFY OK: depth=2, C=NA, ST=None, L=None, O=Mullvad,
CN=Mullvad CA, emailAddress=info@mullvad.net
Fri Mar 2 23:55:44 2018 VERIFY OK: depth=1, C=NA, ST=None, L=None, O=Mullvad,
CN=master.mullvad.net, emailAddress=info@mullvad.net
Fri Mar 2 23:55:44 2018 VERIFY KU OK
Fri Mar 2 23:55:44 2018 Validating certificate extended key usage
Fri Mar 2 23:55:44 2018 ++ Certificate has EKU (str) TLS Web Server Authentica
tion, expects TLS Web Server Authentication
Fri Mar 2 23:55:44 2018 VERIFY EKU OK
Fri Mar 2 23:55:44 2018 VERIFY OK: depth=0, C=NA, ST=None, L=None, O=Mullvad,
CN=dk1.mullvad.net, emailAddress=info@mullvad.net
Fri Mar 2 23:55:44 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-A
ES256-GCM-SHA384, 4096 bit RSA
Fri Mar 2 23:55:44 2018 [dk1.mullvad.net] Peer Connection Initiated with [AF_I
NET]82.103.140.213:1302
Fri Mar 2 23:55:45 2018 SENT CONTROL [dk1.mullvad.net]: 'PUSH_REQUEST' (status
=1)
Fri Mar 2 23:55:50 2018 SENT CONTROL [dk1.mullvad.net]: 'PUSH_REQUEST' (status
=1)
Fri Mar 2 23:55:50 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-g
ateway def1 bypass-dhcp,dhcp-option DNS 10.16.0.1,route-ipv6 0000::/2,route-ipv
6 4000::/2,route-ipv6 8000::/2,route-ipv6 C000::/2,route-gateway 10.16.0.1,topo
logy subnet,socket-flags TCP_NODELAY,ifconfig-ipv6 fdda:d0d0:cafe:1302::1000/64
fdda:d0d0:cafe:1302::,ifconfig 10.16.0.2 255.255.0.0,peer-id 0,cipher AES-256-
GCM'
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: --socket-flags option modified
Fri Mar 2 23:55:50 2018 NOTE: setsockopt TCP_NODELAY=1 failed
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: route options modified
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: route-related options modified
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option option
s modified
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: peer-id set
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Mar 2 23:55:50 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Mar 2 23:55:50 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Mar 2 23:55:50 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialize
d with 256 bit key
Fri Mar 2 23:55:50 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialize
d with 256 bit key
Fri Mar 2 23:55:50 2018 GDG6: remote_host_ipv6=n/a
Fri Mar 2 23:55:50 2018 TUN/TAP device tun0 opened
Fri Mar 2 23:55:50 2018 TUN/TAP TX queue length set to 100
Fri Mar 2 23:55:50 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Mar 2 23:55:50 2018 /sbin/ifconfig tun0 10.16.0.2 netmask 255.255.0.0 mtu
1500 broadcast 10.16.255.255
Fri Mar 2 23:55:50 2018 /sbin/ifconfig tun0 add fdda:d0d0:cafe:1302::1000/64
Fri Mar 2 23:55:50 2018 /etc/openvpn/ovpnclient-up.sh tun0 1500 1553 10.16.0.2
255.255.0.0 init
Fri Mar 2 23:55:50 2018 /sbin/route add -net 82.103.140.213 netmask 255.255.25
5.255 gw 192.168.59.1
Fri Mar 2 23:55:51 2018 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.1
6.0.1
Fri Mar 2 23:55:51 2018 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10
.16.0.1
Fri Mar 2 23:55:51 2018 add_route_ipv6:/2 -> fdda:d0d0:cafe:1302:: metric -1
) dev tun0
Fri Mar 2 23:55:51 2018 /sbin/route -A inet6 add ::/2 dev tun0
Fri Mar 2 23:55:51 2018 add_route_ipv6(4000::/2 -> fdda:d0d0:cafe:1302:: metri
c -1) dev tun0
Fri Mar 2 23:55:51 2018 /sbin/route -A inet6 add 4000::/2 dev tun0
Fri Mar 2 23:55:51 2018 add_route_ipv6(8000::/2 -> fdda:d0d0:cafe:1302:: metri
c -1) dev tun0
Fri Mar 2 23:55:51 2018 /sbin/route -A inet6 add 8000::/2 dev tun0
Fri Mar 2 23:55:51 2018 add_route_ipv6(c000::/2 -> fdda:d0d0:cafe:1302:: metri
c -1) dev tun0
Fri Mar 2 23:55:51 2018 /sbin/route -A inet6 add c000::/2 dev tun0
Fri Mar 2 23:55:51 2018 Initialization Sequence Completed

~
(END)
llvad.net
Fri Mar 2 23:55:44 2018 VERIFY WARNING: depth=2, unable to get certificate CRL
:
Done!
Starting Firewall...
Done!

root@R7800:/$


And then I can verify that ip has changed



But when i reboot router - same procedure occurs

 

[kamoj]

At reboot you try to connect before the router has got correct time.
This is a common problem with this and other Netgear routers.

Voxel has introduced an nvram parameter that you can try out: vpn_client_delay
See https://www.snbforums.com/threads/custom-firmware-build-for-r7800-v-1-0-2-44sf.42882/

To use it, login via telnet and issue these two commands:
nvram set vpn_client_delay=120
nvram commit

The effect is that the OpenVPN connection will wait 2 minutes for time to sync before connecting.

PS
1). I have an alternative solution to the problem, but I have not tested it enough yet.
2). You can manually check time with the command : date
3). Another similar error occurs for some VPN-providers (eg Banhof) if you try to log in repeated times
within too short interval. Ask Mullvad what the minimum time between logins is!

View attachment 12173
Wed Dec 20 01:00:20 2017 VERIFY ERROR: depth=0, error=CRL is not yet valid: C=N
A, ST=None, L=None, O=Mullvad, CN=dk4.mullvad.net, emailAddress=info@mullvad.ne
t
...

Then i try to manually start via telnet: "/ect/init.d/openvpn-client start"

And i got this:
Fri Mar 2 23:55:44 2018 VERIFY OK: depth=0, C=NA, ST=None, L=None, O=Mullvad,
CN=dk1.mullvad.net, emailAddress=info@mullvad.net

View attachment 12173

But when i reboot router - same procedure occurs

 

[gobble]

Had to RMA my R7800, it kept rebooting randomly. Have had the new one a couple of months and happy the issue isn't there, so want to get back on this, but I can't remember if going from stock to Voxel you need to reset afterwards?

 

[Voxel]

At reboot you try to connect before the router has got correct time.
This is a common problem with this and other Netgear routers.

Voxel has introduced an nvram parameter that you can try out: vpn_client_delay
See https://www.snbforums.com/threads/custom-firmware-build-for-r7800-v-1-0-2-44sf.42882/

To use it, login via telnet and issue these two commands:
nvram set vpn_client_delay=120
nvram commit

The effect is that the OpenVPN connection will wait 2 minutes for time to sync before connecting.

PS
1). I have an alternative solution to the problem, but I have not tested it enough yet.
2). You can manually check time with the command : date
3). Another similar error occurs for some VPN-providers (eg Banhof) if you try to log in repeated times
within too short interval. Ask Mullvad what the minimum time between logins is!

The problem is rather in DNS resolving. I.e. not ready yet. But remedy is correct using delay. BTW it is better to use dnscrypt-proxy for OpenVPN client...

BTW, kamoj, welcome back! Don't you wish to test my beta: version is exactly with changes for OpenVPN client. I hope speed will be improved. Plus OpenVPN 2.4.5 and e.g. such updates as new dropbear.

Voxel.

 

[Voxel]

if going from stock to Voxel you need to reset afterwards?

If from the stock 1.0.2.44 reset is not needed.

Voxel.

 

[kamoj]

Sure, that sounds super! I will test of course.

The problem is rather in DNS resolving. I.e. not ready yet. But remedy is correct using delay. BTW it is better to use dnscrypt-proxy for OpenVPN client...

BTW, kamoj, welcome back! Don't you wish to test my beta: version is exactly with changes for OpenVPN client. I hope speed will be improved. Plus OpenVPN 2.4.5 and e.g. such updates as new dropbear.

Voxel.