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.
Just updated to alpha1 on (version 2) and Curl working fine now.

Thanks for testbuild. :)
 
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?
 
Found this nice feture. DNS Server (Optional)

IP.jpg
 
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?
 
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.
 
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.
 
Last edited:
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.
 
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.
 
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.

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?
 
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.
 
I’m having zero WiFi issues on Merlin, based on 81049. I don’t run AiMesh.
 
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.
 
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.
 
Status
Not open for further replies.

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