What's new

[384.14_Alpha - builds] Testing all variants.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.

octopus

Part of the Furniture
https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0

Keep in mind its early testbuild without any support.
https://asuswrt.lostrealm.ca/download

Alpha 1
RT-AC68U for now. - 384.14_alpha1-g8e96494aae Have some bug(s)
RT-AC68U new build. - 384.14_alpha1-gad8d31dff5 Merge with GPL 384_81049 (from RT-AC68U)
RT-AC88U new build. - 384.14_alpha1-gb2338312cd

Alpha 2 -1

RT-AC68U
RT-AC88U
RT-AC3100
RT-AC86U
RT-AX88U

Alpha 2-2
RT-AC68U
RT-AC88U
RT-AC3100
RT-AC86U
RT-AX88U


Change log Alpha 2-1
- UPDATED: RT-AC68U, RT-AC88U, RT-AC3100 to GPL 384_81116.
- UPDATED: RT-AC86U to GPL 384_81116 + binary blobs from 384_81049

- NOTE: There is currently no builds available for the RT-AC87U,RT-AC3200 or RT-AC5300
due to lack of updated compatible components from Asus.

- UPDATED: RT-AX88U to GPL 384_6436.
- UPDATED: nano 4.4
- UPDATED: OUI database to 2018-08-17 version
- UPDATED: Curl 7.66.0
RT-AX88U to match other models.
- CHANGED: Moved /usr/bin/ip to /usr/sbin/ip on the RT-AC86U and
models.
- FIXED: Backported various httpd fixes to RT-AX88 from other


Change log Alpha1

384.14 (xx-xxx-xxxx)
- NEW: Implement option to prevent Firefox's automatic usage of DoH.
By default, this will only apply if you have DNSPrivacy
enabled, or if you have DNSFilter enabled with a global
filter, to ensure that Firefox will not bypass either of
these. You can also have this override applied all the
time, or completely disable it.

- UPDATED: miniupnpd 20190824
- UPDATED: dnsmasq 2.80-74-gdefd6b1 (themiron)
- UPDATED: OpenSSL 1.0.2 to 1.0.2t (themiron)
- UPDATED: OpenSSL 1.1.1 to 1.1.1d (themiron)
- CHANGED: Made webui SSL certificate generation compliant with
IOS 13 and MacOS 10.15 new requirements.
- CHANGED: Rewrote the faketc script used to inject Codel into
Adaptive QoS as a C program for improved performance.
- CHANGED: Moved /bin/ip to /sbin/ip on the RT-AC86U and RT-AX88U
to match other models.
- FIXED: Webui wouldn't notify when running dangerously low on
free nvram (feature was lost at some point in the past)
- FIXED: Non-working link to YandexDNS on the webui for
Russian models.
 
Last edited:
Yesterday I compiled the last commits and since then I have issues with VPN (384.14 alpha1):
It says : Configuration Error! on VPN client menu and I see this on my log:
ovpn-client1[2501]: Linux ip link set failed: could not execute external program
Exiting due to fatal error

I tried Full Reset, trying various NordVPN servers and nothing helped. Everything worked fine before those 2 commits:

iproute2: fix exe location on HND to match that of other platforms; r…

rc: wrong variable used to report bitsize of rejected OVPN server DH

Code:
Sep 20 11:48:37 kernel: tun: Universal TUN/TAP device driver, 1.6
Sep 20 11:48:37 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Sep 20 11:48:37 ovpn-client1[2500]: OpenVPN 2.4.7 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Sep 19 2019
Sep 20 11:48:37 ovpn-client1[2500]: library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.08
Sep 20 11:48:37 ovpn-client1[2501]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Sep 20 11:48:37 ovpn-client1[2501]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 20 11:48:37 ovpn-client1[2501]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sep 20 11:48:37 ovpn-client1[2501]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sep 20 11:48:37 ovpn-client1[2501]: TCP/UDP: Preserving recently used remote address: [AF_INET]31.168.98.72:1194
Sep 20 11:48:37 ovpn-client1[2501]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Sep 20 11:48:37 ovpn-client1[2501]: UDP link local: (not bound)
Sep 20 11:48:37 ovpn-client1[2501]: UDP link remote: [AF_INET]X.X.X.X:1194
Sep 20 11:48:37 ovpn-client1[2501]: TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=15e0a488 1c908aeb
Sep 20 11:48:37 ovpn-client1[2501]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA3
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY KU OK
Sep 20 11:48:37 ovpn-client1[2501]: Validating certificate extended key usage
Sep 20 11:48:37 ovpn-client1[2501]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY EKU OK
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=0, CN=il26.nordvpn.com
Sep 20 11:48:37 ovpn-client1[2501]: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Sep 20 11:48:37 ovpn-client1[2501]: [il26.nordvpn.com] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
Sep 20 11:48:38 ovpn-client1[2501]: SENT CONTROL [il26.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sep 20 11:48:38 ovpn-client1[2501]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS X.X.X.X,dhcp-option DNS X.X.X.Xsndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.8.0.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.0.17 255.255.255.0,peer-id 14,cipher AES-256-GCM'
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: timers and/or timeouts modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: explicit notify parm(s) modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: compression parms modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sep 20 11:48:38 ovpn-client1[2501]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --ifconfig/up options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: route options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: route-related options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: peer-id set
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: adjusting link_mtu to 1657
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: data channel crypto options modified
Sep 20 11:48:38 ovpn-client1[2501]: Data Channel: using negotiated cipher 'AES-256-GCM'
Sep 20 11:48:38 ovpn-client1[2501]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 20 11:48:38 ovpn-client1[2501]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 20 11:48:38 ovpn-client1[2501]: TUN/TAP device tun11 opened
Sep 20 11:48:38 ovpn-client1[2501]: TUN/TAP TX queue length set to 1000
Sep 20 11:48:38 ovpn-client1[2501]: /bin/ip link set dev tun11 up mtu 1500
Sep 20 11:48:38 ovpn-client1[2501]: Linux ip link set failed: could not execute external program
Sep 20 11:48:38 ovpn-client1[2501]: Exiting due to fatal error

Fixed with the latest commits 21/09
 
Last edited:
Yesterday I compiled the last commits and since then I have issues with VPN (384.14 alpha1):
It says : Configuration Error! on VPN client menu and I see this on my log:
ovpn-client1[2501]: Linux ip link set failed: could not execute external program
Exiting due to fatal error

I tried Full Reset, trying various NordVPN servers and nothing helped. Everything worked fine before those 2 commits:

iproute2: fix exe location on HND to match that of other platforms; r…
rc: wrong variable used to report bitsize of rejected OVPN server DH


Code:
Sep 20 11:48:37 kernel: tun: Universal TUN/TAP device driver, 1.6
Sep 20 11:48:37 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Sep 20 11:48:37 ovpn-client1[2500]: OpenVPN 2.4.7 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Sep 19 2019
Sep 20 11:48:37 ovpn-client1[2500]: library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.08
Sep 20 11:48:37 ovpn-client1[2501]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Sep 20 11:48:37 ovpn-client1[2501]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 20 11:48:37 ovpn-client1[2501]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sep 20 11:48:37 ovpn-client1[2501]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sep 20 11:48:37 ovpn-client1[2501]: TCP/UDP: Preserving recently used remote address: [AF_INET]31.168.98.72:1194
Sep 20 11:48:37 ovpn-client1[2501]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Sep 20 11:48:37 ovpn-client1[2501]: UDP link local: (not bound)
Sep 20 11:48:37 ovpn-client1[2501]: UDP link remote: [AF_INET]X.X.X.X:1194
Sep 20 11:48:37 ovpn-client1[2501]: TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=15e0a488 1c908aeb
Sep 20 11:48:37 ovpn-client1[2501]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA3
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY KU OK
Sep 20 11:48:37 ovpn-client1[2501]: Validating certificate extended key usage
Sep 20 11:48:37 ovpn-client1[2501]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY EKU OK
Sep 20 11:48:37 ovpn-client1[2501]: VERIFY OK: depth=0, CN=il26.nordvpn.com
Sep 20 11:48:37 ovpn-client1[2501]: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Sep 20 11:48:37 ovpn-client1[2501]: [il26.nordvpn.com] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
Sep 20 11:48:38 ovpn-client1[2501]: SENT CONTROL [il26.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Sep 20 11:48:38 ovpn-client1[2501]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS X.X.X.X,dhcp-option DNS X.X.X.Xsndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.8.0.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.0.17 255.255.255.0,peer-id 14,cipher AES-256-GCM'
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: timers and/or timeouts modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: explicit notify parm(s) modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: compression parms modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sep 20 11:48:38 ovpn-client1[2501]: Socket Buffers: R=[524288->1048576] S=[524288->1048576]
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --ifconfig/up options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: route options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: route-related options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: peer-id set
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: adjusting link_mtu to 1657
Sep 20 11:48:38 ovpn-client1[2501]: OPTIONS IMPORT: data channel crypto options modified
Sep 20 11:48:38 ovpn-client1[2501]: Data Channel: using negotiated cipher 'AES-256-GCM'
Sep 20 11:48:38 ovpn-client1[2501]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 20 11:48:38 ovpn-client1[2501]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 20 11:48:38 ovpn-client1[2501]: TUN/TAP device tun11 opened
Sep 20 11:48:38 ovpn-client1[2501]: TUN/TAP TX queue length set to 1000
Sep 20 11:48:38 ovpn-client1[2501]: /bin/ip link set dev tun11 up mtu 1500
Sep 20 11:48:38 ovpn-client1[2501]: Linux ip link set failed: could not execute external program
Sep 20 11:48:38 ovpn-client1[2501]: Exiting due to fatal error

There's a big GPL merge (8104) in progress as Asus have updated a lot of internal components, Merlin will let users know when its ready for testing.
 
have to reflash back to 384.13

Seems like there is something wrong with stubby (DOT)
My skynet unable to start due to no internet. I try to disable it, also cannot surf.
My ddns able to sync, my OPVN server able to start. But No internet access.

I change my PC dns server, able to surf (meaning internet connection is there)

After I disable DOT (stubby), it seems internet is back working and skynet able to start.

Suspect due to time sync issue causing DOT to fail to connect.
 
have to reflash back to 384.13

Seems like there is something wrong with stubby (DOT)
My skynet unable to start due to no internet. I try to disable it, also cannot surf.
My ddns able to sync, my OPVN server able to start. But No internet access.

I change my PC dns server, able to surf (meaning internet connection is there)

After I disable DOT (stubby), it seems internet is back working and skynet able to start.

Suspect due to time sync issue causing DOT to fail to connect.
I see you installed Diversion 4.1.4 . Check if Local Cache is set to 'No' in Tools->Other Setting
 
I see you installed Diversion 4.1.4 . Check if Local Cache is set to 'No' in Tools->Other Setting

Yes on Diversion 4.1.4

Currently is set to YES. Should i change to NO?

So is yours set to NO for 384.14 Alpha 1 and skynet able to start properly?

Looking at @thelonelycoder 's reply, i do agreed that technically it should be more responsive if set to NO.
https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/page-187#post-516484

If there is an issue, it could be the way Skynet check for internet connectivity? @Adamm can look into it?
Question is why 384.13 works with YES and why it dont work in 384.14Alpha1?

Another question.
I am using sg.pool.ntp.org & time.google.com for my NTP
and I have the following inside dnsmasq.conf.add
Code:
server=/sg.pool.ntp.org/8.8.8.8
server=/time.google.com/8.8.8.8
technically it should have used it and properly time synced?


I will try later. currently family using the net.
 
Last edited:
Yes on Diversion 4.1.4

Currently is set to YES. Should i change to NO?

So is yours set to NO for 384.14 Alpha 1 and skynet able to start properly?

Looking at @thelonelycoder 's reply, i do agreed that technically it should be more responsive if set to NO.
https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/page-187#post-516484

If there is an issue, it could be the way Skynet check for internet connectivity? @Adamm can look into it?
Question is why 384.13 works with YES and why it dont work in 384.14Alpha1?

Another question.
I am using sg.pool.ntp.org & time.google.com for my NTP
and I have the following inside dnsmasq.conf.add
Code:
server=/sg.pool.ntp.org/8.8.8.8
server=/time.google.com/8.8.8.8
technically it should have used it and properly time synced?


I will try later. currently family using the net.
Yes, it should be set to "No" . This happens to me also when Local Cache is set to Yes, The connection Icon turns off and Skynet reports that there is no Internet Connection . So set it to No and try 384.14 alpha 1 again.
The thing with Local DNS cache started on 384.12 (by then it was set to YES by default) and Merlin set it to "NO" by default on 384.13 version. It is not new for 384.14 build but when you installed Diversion 4.1.4, Diversion set it to YES , so after the installation you should switch it back to No. Not specific to 384.14 , its like that from 384.13
 
It's a ALPHA build
Some of the changes ( I guess there are more)

384.14 (xx-xxx-xxxx)
- UPDATED: miniupnpd 20190824 - UPDATED: miniupnpd 20190824

- UPDATED: dnsmasq 2.80-67-g5a91334 (themiron)

- CHANGED: Made webui SSL certificate generation compliant with
IOS 13 and MacOS 10.15 new requirements.

- FIXED: Webui wouldn't notify when running dangerously low on - FIXED: Webui wouldn't notify when running dangerously low on
free nvram (feature was lost at some point in the past) free nvram (feature was lost at some point in the past)

- FIXED: Non-working link to YandexDNS on the webui for
Russian models.
 
Yes, it should be set to "No" . This happens to me also when Local Cache is set to Yes, The connection Icon turns off and Skynet reports that there is no Internet Connection . So set it to No and try 384.14 alpha 1 again.
The thing with Local DNS cache started on 384.12 (by then it was set to YES by default) and Merlin set it to "NO" by default on 384.13 version. It is not new for 384.14 build but when you installed Diversion 4.1.4, Diversion set it to YES , so after the installation you should switch it back to No. Not specific to 384.14 , its like that from 384.13

Tested still didnt work for me.
But skynet did successfully start up after set to NO.
Also, YES or NO, both of them have connection icon light up.
However still unable to surf.

i did an experiment to do a command "stubby restart" in 384.14 Alpha 1
Code:
[16:59:31.585314] STUBBY: Read config from file /etc/stubby/stubby.yml
[16:59:31.586188] STUBBY: DNSSEC Validation is OFF
[16:59:31.586334] STUBBY: Transport list is:
[16:59:31.586433] STUBBY:   - TLS
[16:59:31.586605] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[16:59:31.586709] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[16:59:31.586802] STUBBY: Starting DAEMON....
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
Could not schedule query: The library did not have the requested API feature implemented.
.........
it keep giving me this " Could not schedule query: The library did not have the requested API feature implemented. "

When i give the same command in 384.13, the stubby is working and stop at " STUBBY: Starting DAEMON.... "

So i have a feeling that there is some mess up in stubby. Anyone having the same issue with me?
 
Changelog?

On Git.

Code:
c107c033bc (HEAD -> 8104x, origin/8104x) Merge branch 'mainline' into 8104x
82f85e4fca (origin/mainline, mainline) Merge branch 'master' into mainline
5e0bd21979 (origin/master, origin/HEAD, master) rc: wrong variable used to report bitsize of rejected OVPN server DH
59c51d6b99 Revert "rc: wrong variable used to report bitsize of rejected OVPN server DH" - should be done on master branch
629d26690d rc: wrong variable used to report bitsize of rejected OVPN server DH
1f30b376ba rc: remove call to set LED_WAN_NORMAL for non-HND models in setup_leds()
ee0a375d93 libdisk: disable Asus's unfinished handling of SMB protocol version
c58396c790 rc: update state/error report for OpenVPN clients and servers
f843b51770 rc: shared: re-implemented LED control.
d1af6cbfea webui: updated Temperature page
3997621b50 openssl: harmonized recipes with upstream
49624c24f6 rom: harmonized certs location in source tree with upstream
0faaa679bf rc: shared: fix build warn error due to duplicate modprobe define
c0ff0a3dc0 samba36: harmonized root Makefile with Asus's
047ec2198e webui: add bg class to non-Asus pages, to natch with 81049
7c3a802cf1 openvpn: implement support for verify-x509-name with "subject" or "name-prefix" types ("name" was already supported)
3d09eada10 libvpn: updated write_ovpn_dns() to match 81049; implemented get_ovpn_status() and get_ovpn_errno() which are new in 81049
dc26c5fb26 webui: re-based DHCP web page on upstream code (with the new DNS field)
f5b98afe07 Merge SDK + binary blobs from 81049 for RT-AC68U
4a933a97d0 Merge with GPL 384_81049 (from RT-AC68U)
679c8b5976 Merge with GPL 384_81044 (from GT-AC2900)
a606aba9b2 iproute2: fix exe location on HND to match that of other platforms; remove related dead code in rc/qos.c.
cc084fdab0 webui: fix ouiDB broken by c5f5f07e314d9d06c2251433321d977c271b28fc
0b797c237b Merge branch 'master' into mainline
91b840d112 Updated documentation
c1f84d2268 webui: do not report new firmware availability during QIS since we lack liveupdate capabilities
7f88f1f8ce webui: ensure that YandexDNS is always disabled at the webui level (closes #347)
a660529b9f dnsmasq: update to 2.80-67-g5a91334
e786dfa2a5 httpd: add "TLS Web Server Authentication" to certificate's extended attributes
9e1566a472 httpd: limit SSL certificate to 2 years if clock is accurate
bad3178ce9 Merge branch 'master' into mainline
b7136dc124 Updated documentation
ed363e37dc miniupnpd: updated to 20190824
4f3c91044a webui: fix typo
1b72d510fc build: change default toolchain symlink to be relative
b7d2e68f26 rc: log unrecognized events to syslog
5ab95cc2eb webui: re-implement notification if free nvram < 3000 bytes
c5f5f07e31 webui: update OUI database to 2018-08-17 version
9c5b4b0844 build: update build-all script, adding branch support
fdd62e39f1 build: update copy-prebuilt script
40b52b0fd6 Bumped revision to 384.14 alpha 1

Can't remember for sure if that build was from this first commit, or a bit earlier.
 
On Git.
Code:
c107c033bc (HEAD -> 8104x, origin/8104x) Merge branch 'mainline' into 8104x
82f85e4fca (origin/mainline, mainline) Merge branch 'master' into mainline
5e0bd21979 (origin/master, origin/HEAD, master) rc: wrong variable used to report bitsize of rejected OVPN server DH
59c51d6b99 Revert "rc: wrong variable used to report bitsize of rejected OVPN server DH" - should be done on master branch
629d26690d rc: wrong variable used to report bitsize of rejected OVPN server DH
1f30b376ba rc: remove call to set LED_WAN_NORMAL for non-HND models in setup_leds()
ee0a375d93 libdisk: disable Asus's unfinished handling of SMB protocol version
c58396c790 rc: update state/error report for OpenVPN clients and servers
f843b51770 rc: shared: re-implemented LED control.
d1af6cbfea webui: updated Temperature page
3997621b50 openssl: harmonized recipes with upstream
49624c24f6 rom: harmonized certs location in source tree with upstream
0faaa679bf rc: shared: fix build warn error due to duplicate modprobe define
c0ff0a3dc0 samba36: harmonized root Makefile with Asus's
047ec2198e webui: add bg class to non-Asus pages, to natch with 81049
7c3a802cf1 openvpn: implement support for verify-x509-name with "subject" or "name-prefix" types ("name" was already supported)
3d09eada10 libvpn: updated write_ovpn_dns() to match 81049; implemented get_ovpn_status() and get_ovpn_errno() which are new in 81049
dc26c5fb26 webui: re-based DHCP web page on upstream code (with the new DNS field)
f5b98afe07 Merge SDK + binary blobs from 81049 for RT-AC68U
4a933a97d0 Merge with GPL 384_81049 (from RT-AC68U)
679c8b5976 Merge with GPL 384_81044 (from GT-AC2900)
a606aba9b2 iproute2: fix exe location on HND to match that of other platforms; remove related dead code in rc/qos.c.
cc084fdab0 webui: fix ouiDB broken by c5f5f07e314d9d06c2251433321d977c271b28fc
0b797c237b Merge branch 'master' into mainline
91b840d112 Updated documentation
c1f84d2268 webui: do not report new firmware availability during QIS since we lack liveupdate capabilities
7f88f1f8ce webui: ensure that YandexDNS is always disabled at the webui level (closes #347)
a660529b9f dnsmasq: update to 2.80-67-g5a91334
e786dfa2a5 httpd: add "TLS Web Server Authentication" to certificate's extended attributes
9e1566a472 httpd: limit SSL certificate to 2 years if clock is accurate
bad3178ce9 Merge branch 'master' into mainline
b7136dc124 Updated documentation
ed363e37dc miniupnpd: updated to 20190824
4f3c91044a webui: fix typo
1b72d510fc build: change default toolchain symlink to be relative
b7d2e68f26 rc: log unrecognized events to syslog
5ab95cc2eb webui: re-implement notification if free nvram < 3000 bytes
c5f5f07e31 webui: update OUI database to 2018-08-17 version
9c5b4b0844 build: update build-all script, adding branch support
fdd62e39f1 build: update copy-prebuilt script
40b52b0fd6 Bumped revision to 384.14 alpha 1
Can't remember for sure if that build was from this first commit, or a bit earlier.

Awesome, is everything going fine with other models like RT-AC86U ? can't wait :) hoping it will be available soon
 
Awesome, is everything going fine with other models like RT-AC86U ? can't wait :) hoping it will be available soon

The RT-AC68U is the only GPL I have at the moment, so that's the only model that can be compiled.
 
Installed 384.14_alpha1 on the 68U yesterday..24 hours of uptime and all running smoothly: wifi, dnscrypt, pixelserv, diversion, skynet, and yazfi.
 
Will OpenSSL 1.1.1d & OpenSSL 1.0.2t be added in 384.14? (released 10sep)
 
Just updated to Alpha1
Discover "vpn_client1_state" never reach "2" state, when vpn is connected.
(DOWN state=0) (CONNECTING state=1) (UP state=2)
@RMerlin @Martineau

Probably regarding this fix/update
c58396c790 rc: update state/error report for OpenVPN clients and servers

3d09eada10 libvpn: updated write_ovpn_dns() to match 81049; implemented get_ovpn_status() and get_ovpn_errno() which are new in 8104
 
Last edited:
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top