What's new

[ 386.4 alpha Build(s) ] Testing available build(s)

  • 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.
The changes are always on Github for alpha snapshots.

Code:
merlin@ubuntu-dev:~/amng$ git log --oneline 952c6bdecc..7d7073bf09
7d7073bf09 (origin/45958) Bump revision to alpha 3
b454925d96 Update build tools for new models
bd06e54067 Merge RT-AC88U/3100/5300 SDK + binary blobs from 45958
81b1f1ba63 miniupnpd: fix compiling under 2.6 kernel
b35877c914 build: updated copy-prebuilt - added new models, removed old ones improved copy/syncing
4ddcf06932 webui: apply AM general.js changes to the GT-AXE11000 copy
ac145a8417 webui: add 6 GHz support to Wireless Log page
e67e9fe3db webui: add 6G support to Tools Sysinfo page
ad911e3a38 rc: add LED control support to GT-AXE11000
26e8d2b290 httpd: add temperature report for GT-AXE11000
04f67ef827 Merge GT-AXE11000 SDK + binary blobs from 45958
2899e16357 Merged RT-AC68U_V4 binary blobs + SDK from 45958
aa46c15ba6 Updated documentation
4fd55c9770 Enable wireguard module + tool on RT-AC86U/GT-AC2900
79c06ed80c Fix visualization bin location
4abc3bf300 Merge GT-AC2900 binary blobs from 45958
6157117000 Revert "rc: fully disable wanduck DNS probing if disabled on the webui"
d0169015d8 Merge RT-AC86U SDK + binary blobs from 45958
2fa751e1f8 Merge with GPL 386_45958 (from RT-AC86U)
8a77382a6e (origin/master, master) Updated documentation
23e27eb262 (origin/45581, 45581) build: disable the rest of the wireguard code, keeping only kernel + userspace
Is one of the takeaways from this that the GT-AXE11000 will soon be supported?
 
Is one of the takeaways from this that the GT-AXE11000 will soon be supported?
Yes, that was announced a few weeks ago. However wifi is broken in the current GPL, so there's no build available for it.
 
Updated from alpha1 to 3 on RT-AC86U, everything's running great!
Thanks again for your dedication and eternal patience @RMerlin!
 
I don`t know, I'm not the developer of that addon.
I’m a bit confused by the term “addon”; isn’t “ookla” just a binary included in the Asuswrt (standard) firmware?

(which I want to run stand-alone on the command line; not as part of an addon)
 
Getting a really weird client popping up on my network map that is on an entirely different subnet than my regular network, or even my guest network for that matter. It even shows as a wired device, but I am totally sure there aren't any other ethernet devices connected that I haven't plugged in myself.



Should I be concerned? It's named after my brother's laptop that is currently half way across the country (for which I gave an alias to on the network map when it was connected over wifi here a week ago), and which was never connected by ethernet to the network. Just for good measure, I checked the ovpn server and no clients are connected and logs seem pretty clear besides the usual kernal noise.

FYI ax88u running on 386.4_alpha2-g952c6bdecc.

Edit: The plot thickens. On a deeper dive into the logs I found this during the time that the mystery client appeared above:

Code:
Nov 30 01:19:20 rc_service: httpds 9807:notify_rc restart_wan_if 0;restart_stubby
Nov 30 01:19:20 custom_script: Running /jffs/scripts/service-event (args: restart wan_if)
Nov 30 01:19:20 ovpn-server1[5700]: event_wait : Interrupted system call (code=4)
Nov 30 01:19:20 ovpn-server1[5700]: Closing TUN/TAP interface
Nov 30 01:19:20 ovpn-server1[5700]: /usr/sbin/ip addr del dev tun21 10.8.0.1/24
Nov 30 01:19:20 ovpn-server1[5700]: ovpn-down 1 server tun21 1500 1621 10.8.0.1 255.255.255.0 init
Nov 30 01:19:20 ovpn-server1[5700]: SIGTERM[hard,] received, process exiting
Nov 30 01:19:22 custom_script: Running /jffs/scripts/service-event (args: restart stubby)
Nov 30 01:19:22 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Nov 30 01:19:22 wan: finish adding multi routes
Nov 30 01:19:22 miniupnpd[5169]: shutting down MiniUPnPd
Nov 30 01:19:23 start_ddns: update FREEDNS.AFRAID.ORG default@freedns.afraid.org, wan_unit 0
Nov 30 01:19:23 inadyn[31061]: In-a-dyn version 2.8.1 -- Dynamic DNS update client.
Nov 30 01:19:23 rc_service: udhcpc 30953:notify_rc start_vpnserver1
Nov 30 01:19:23 custom_script: Running /jffs/scripts/service-event (args: start vpnserver1)
Nov 30 01:19:23 rc_service: udhcpc 30953:notify_rc stop_samba
Nov 30 01:19:23 rc_service: waitting "start_vpnserver1" via udhcpc ...
Nov 30 01:19:23 ovpn-server1[31246]: OpenVPN 2.5.4 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 16 2021
Nov 30 01:19:23 ovpn-server1[31246]: library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.08
Nov 30 01:19:23 ovpn-server1[31266]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 30 01:19:23 ovpn-server1[31266]: Diffie-Hellman initialized with 2048 bit key
Nov 30 01:19:23 ovpn-server1[31266]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 30 01:19:23 ovpn-server1[31266]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 30 01:19:23 ovpn-server1[31266]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Nov 30 01:19:23 ovpn-server1[31266]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Nov 30 01:19:23 ovpn-server1[31266]: TUN/TAP device tun21 opened
Nov 30 01:19:23 ovpn-server1[31266]: TUN/TAP TX queue length set to 1000
Nov 30 01:19:23 ovpn-server1[31266]: /usr/sbin/ip link set dev tun21 up mtu 1500
Nov 30 01:19:23 ovpn-server1[31266]: /usr/sbin/ip link set dev tun21 up
Nov 30 01:19:23 ovpn-server1[31266]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24
Nov 30 01:19:23 ovpn-server1[31266]: ovpn-up 1 server tun21 1500 1621 10.8.0.1 255.255.255.0 init
Nov 30 01:19:23 ovpn-server1[31266]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Nov 30 01:19:23 ovpn-server1[31266]: UDPv4 link local (bound): [AF_INET][undef]:2424
Nov 30 01:19:23 ovpn-server1[31266]: UDPv4 link remote: [AF_UNSPEC]
Nov 30 01:19:23 ovpn-server1[31266]: MULTI: multi_init called, r=256 v=256
Nov 30 01:19:23 ovpn-server1[31266]: IFCONFIG POOL IPv4: base=10.8.0.2 size=252
Nov 30 01:19:23 ovpn-server1[31266]: Initialization Sequence Completed
Nov 30 01:19:24 rc_service: udhcpc 30953:notify_rc start_samba
Nov 30 01:19:24 rc_service: waitting "stop_samba" via udhcpc ...
Nov 30 01:19:24 custom_script: Running /jffs/scripts/service-event (args: stop samba)
Nov 30 01:19:26 dhcp_client: bound 24.130.151.21/255.255.248.0 via 24.130.144.1 for 5429 seconds.
Nov 30 01:19:26 custom_script: Running /jffs/scripts/service-event (args: start samba)
Nov 30 01:19:27 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
Nov 30 01:19:28 Diversion: restarted Dnsmasq to apply settings
Nov 30 01:19:28 Samba_Server: daemon is started

And certainly for sure no ovpn clients showed as being connected to the server at the time on the router's GUI. Now should I be even more concerned?
 
Last edited:
I’m a bit confused by the term “addon”; isn’t “ookla” just a binary included in the Asuswrt (standard) firmware?

(which I want to run stand-alone on the command line; not as part of an addon)

Yes Ookla's speedtest binary is part of the Asus GPL supplied to Merlin. However, it appears that some of the command line arguments have changed in the latest release of of binary file. This is causing problems with Jack's addon script as the problematic argument that Jack was passing onto the internal speedtest binary is no longer supported.

@Jack Yaz has already stated that it will not get fixed until this release moves into Beta at the very least. For that I don't blame him. Alpha's are too fluid to keep up with any third party fixes.

In the meantime, there have been several posts with work arounds that can be used. I won't go into them in detail here as they have been posted in detail elsewhere, but they are;

1. Using the Speed CLI, you can switch to the development branch and then select to use the external SpeedTest Binary
2. Edit the spdmerlin script and go to line 1364 and set the variable LICENSE_STRING="--accept-license --accept-gdpr" to "" (this may cause problems if you run speedtest for the first time on a fresh install).

There may even be an issue with the IFS environment variable getting set to something other than a space. When adapting the script for OpenWRT, I had intermittent issues with this same license string giving the same error. Turned out another OpenWRT process was changing the IFS variable. I ended up breaking up the license string into two variables to avoid the issue. However, I don't thing that is the cause here.
 
I’m a bit confused by the term “addon”; isn’t “ookla” just a binary included in the Asuswrt (standard) firmware?

(which I want to run stand-alone on the command line; not as part of an addon)
He's talking about SpdMerlin, which is an addon.
 
He's talking about SpdMerlin, which is an addon.
But for me ookla stand-alone does not work, or I use it wrong…

Anyway, also with the manually downloaded speedtest CLI version my router seems not able to tell me the wired speed, since it reports around 500 Mbps down, while a MacBook connected via WiFi (to this same router) reports over 750 Mbps…
 
Getting a really weird client popping up on my network map that is on an entirely different subnet than my regular network, or even my guest network for that matter. It even shows as a wired device, but I am totally sure there aren't any other ethernet devices connected that I haven't plugged in myself.



Should I be concerned? It's named after my brother's laptop that is currently half way across the country (for which I gave an alias to on the network map when it was connected over wifi here a week ago), and which was never connected by ethernet to the network. Just for good measure, I checked the ovpn server and no clients are connected and logs seem pretty clear besides the usual kernal noise.

FYI ax88u running on 386.4_alpha2-g952c6bdecc.

Edit: The plot thickens. On a deeper dive into the logs I found this during the time that the mystery client appeared above:
...
And certainly for sure no ovpn clients showed as being connected to the server at the time on the router's GUI. Now should I be even more concerned?

On my network I found that all WiFi devices Connected through my Access Point (With Most recent STOCK Firmware) simply showed up as hardwired when looking at the main router.
I think I read somewhere that this may have been a normal/expected occurance/
 
On my network I found that all WiFi devices Connected through my Access Point (With Most recent STOCK Firmware) simply showed up as hardwired when looking at the main router.
I think I read somewhere that this may have been a normal/expected occurance/
An access point connects via an ethernet connection and thus the devices that connect to the AP are connected via that ethernet connection.

Morris
 
On my AC5300 I loaded the latest Stock MErlin firmware, there was a submenu on the left called Open NAT i think....why is it removed on Merlin firmware?
 
On my AC5300 I loaded the latest Stock MErlin firmware, there was a submenu on the left called Open NAT i think....why is it removed on Merlin firmware?
On my RT-AX88U running 386.4 alpha2 it is there. I don't think it was removed on purpose. Maybe a router reset is required?
 
On my AC5300 I loaded the latest Stock MErlin firmware, there was a submenu on the left called Open NAT i think....why is it removed on Merlin firmware?
Have you tried with "CTRL-F5"?
 
Current alphas on Main and AP without issues :cool:

EDIT:
Dirty Filthy Upgrade from alpha 1 on both Main/AP
 
Last edited:
any news about Wi-Fi HaLow [802.11ah] it has a 1 Kilometer Range o_O
 
Hey folks,
Does anyone know whether or not Alpha 3 for the AX58U is being released? Keen to check it out.
 
Two devices (both) on guest network 1 can no longer discover each other (using SSDP and/or mDNS), unless I enable intranet access...

Is this new?

Expected behaviour?
 
Expected.
 
Status
Not open for further replies.

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!

Members online

Top