[384.14_Alpha - builds] Testing all variants.

[Mihai]

https://github.com/RMerl/asuswrt-merlin.ng/commits/c58396c790

Where can I find this commit in Github?
c58396c790 rc: update state/error report for OpenVPN clients and servers

Q: Have tried to search with "c58396c790"
OK: found it!?
https://github.com/RMerl/asuswrt-merlin.ng/commit/c58396c790a55be260cb76c269ae9928ff236e0e

New: vpn_client1_state
OVPN_STS_INIT OLD=1
OVPN_STS_RUNNING OLD=2
OVPN_STS_STOP OLD=0

NEW: vpn_server1_state
OVPN_STS_ERROR OLD=-1

 

[John Fitzgerald]

I'm getting the same error as in post #33 with the new ...dff5 alpha.

Also, Diversion thread (Example post #3823) https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/page-192
indicating that Pixelserv helper 2.3.0 may be causing issues.

 

[octopus]

Just updated to alpha1 on (version 2) and Curl working fine now.

Thanks for testbuild.

 

[DonnyJohnny]

I tested the 2 alpha for my AC68U. both didnt work out for me.

I am using DOT (built-in stubby), ntpmerlin, Diversion with pixelserv (jack's fork), skynet and have IPv6
VPNserver, Diversion, Skynet all loaded properly after reboot.
I also checked that stubby is loaded via htop.

I am able to do dns query via router but all my other clients are unable to surf unless i set dns server on the client itself.

What i did to try resolve the issue but in vain.
I disabled Diversion, Skynet, IPv6. Still unable to use.
I checked the Connections under the system log, there isn't any connection from my clients when they tried to surf net.

I switched DOT servers, reboot router (multiple times), still unable to surf.

When i flashed back to 384.13, it works again.

May I know what's wrong?

 

[octopus]

I tested the 2 alpha for my AC68U.

There isn't any alpha2 only alpha1 version 1 and 2

 

[octopus]

Found this nice feture. DNS Server (Optional)

 

[SomeWhereOverTheRainBow]

Found this nice feture. DNS Server (Optional)

View attachment 19403

That is a nice feature if you are trying to point a device at a different lan DNS instead of using default 192.168.1.1(or what ever yours is).

 

[DonnyJohnny]

There isn't any alpha2 only alpha1 version 1 and 2

Lol.. I did said 2 alpha and not alpha2.

anyone? Anyone know what’s wrong with my configuration and what u think I should do?

 

[octopus]

Lol.. I did said 2 alpha and not alpha2.

Hmm sorry read to fast sometime.

 

[RMerlin]

Found this nice feture. DNS Server (Optional)

View attachment 19403

Added by Asus in 384_81049.

 

[alexandro]

Is it new AIMesh libs from Asus? AIMesh in 13 broke my AX88 - 2,4GHz disabled, reset to defaults can’t help. Back flash 12 then 13 enable 2,4. So, AiMesh seems unstable and buggy.

 

[SomeWhereOverTheRainBow]

I wonder if new firmware Version 3.0.0.4.384.81116 for the RT-AC88U and RT-AC3100 will release a GPL in time to make it into this alpha.

I think those are roughly equivalent to the 384_81049 as far as changes that have been made. I wonder why the difference in versions then.

 

[Vexira]

I wonder if new firmware Version 3.0.0.4.384.81116 for the RT-AC88U and RT-AC3100 will release a GPL in time to make it into this alpha.

I think those are roughly equivalent to the 384_81049 as far as changes that have been made. I wonder why the difference in versions then.

If not then hopefully it will make it into the beta.

 

[FIN]

Found this nice feture. DNS Server (Optional)

View attachment 19403

is there the same option in RT-AC88U new build. - 384.14_alpha1 ?

 

[RMerlin]

is there the same option in RT-AC88U new build. - 384.14_alpha1 ?

No, the RT-AC68U is the only device currently on a newer GPL.

 

[maxbraketorque]

On Git.

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.

Isn't 81049 fairly problematic? Lots of people complaining about it in the Official FW forum. Did you resolve any of the issues as part of the merge?

 

[RMerlin]

Isn't 81049 fairly problematic? Lots of people complaining about it in the Official FW forum.

If you look closely, people have complained about every single release for the past 2-3 years...

A lot of people who complain do zero troubleshooting of their network, and instantly blame the router firmware for everything not working to their liking. I once had a blind test done by users where people reported differences in wifi performance between two firmware images i had provided them, where I hadn't told them that both images actually had the exact same wifi code... (actually, I provided three separate firmware images, but only two had differences. And people reported differences between the two identical releases.)

That's when I stopped caring about wifi related complains.

 

[scjr]

I’m having zero WiFi issues on Merlin, based on 81049. I don’t run AiMesh.

 

[SMS786]

2nd alpha working great on the trusty 68U.

An issue for the 1st alpha I failed to report earlier: DDNS was not updating my isp's new ip address, causing issues for my ovpn server. Not sure if it was an actual issue addressed in the 2nd alpha or was something on my end, but after upgrading it seems to be resolved.

 

[maxbraketorque]

If you look closely, people have complained about every single release for the past 2-3 years...

A lot of people who complain do zero troubleshooting of their network, and instantly blame the router firmware for everything not working to their liking. I once had a blind test done by users where people reported differences in wifi performance between two firmware images i had provided them, where I hadn't told them that both images actually had the exact same wifi code... (actually, I provided three separate firmware images, but only two had differences. And people reported differences between the two identical releases.)

That's when I stopped caring about wifi related complains.

Yeah, I can see some truth to there always being perceived issues, but there have definitely been times when a new FW is found to truly be problematic. Anyhow, .13 has been great for me, so I'll wait for this one to reach release status before I try it.