What's new

Release [ 384.19_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!

Are you satisfied with title?

  • Yes

    Votes: 75 93.8%
  • No

    Votes: 5 6.3%

  • Total voters
    80
  • Poll closed .
Status
Not open for further replies.
I compiled 384.19 alpha 1 build for my Asus 86u once I saw the new GPL (384_81992) merged. Works great. I guess the new builds for the rest model are gonna be available very soon

Code:
384.19 (xx-xxx-2020)
  - NEW: Added support for static routes for PPTP/L2TP VPN
         clients, on the Static Route page (themiron)
  - NEW: Added notification when jffs free space drops below
         3 MB.
  - NEW: Added notification when jffs free space drops
         below 3 MB.
  - UPDATED: Merged GPL 384_9354 for AX models.
  - UPDATED: Merged GPL 384_81992 for mainline models.
  - UPDATED: Merged SDK + binary blobs 384_9354 for RT-AX58U.
  - UPDATED: Merged SDK + binary blobs 384_9107 for RT_AX88U.
  - UPDATED: Merged binary blobs + SDK 384_81981 for RT_AC5300.
  - UPDATED: Merged binary blobs + SDK 384_81992 for RT-AC86U.
  - UPDATED: Merged bwdpi components from 385_20630 firmware
             image for RT-AC68U.
  - CHANGED: Improved mechanism for providing an available
             mount point for addon API scripters (dave14305)
  - CHANGED: Harmonized the various SSL certificate modes with
             upstream.
             0-None - will be self-generated
             1-Imported - lets you upload your own (no longer
                           self generated unless you don't
                           upload one)
            2-Let's Encrypt (unchanged)
            Self-generated cert will be stored to /jffs/cert.tgz,
            just like upstream.
  - FIXED: Broken French webui on AX models (fixed with
           Asus's GPL update)
  - FIXED: Chacha20 wasn't prioritized for bcm675x models which
           lacked AES acceleration (RT-AX56U and RT-AX58U)
 
Last edited:
I compiled 384.19 alpha 1 build for my Asus 86u once I saw the new GPL (384_81992) merged. Works great. I guess the new builds for the rest model are gonna be available very soon

Code:
384.19 (xx-xxx-2020)
  - NEW: Added support for static routes for PPTP/L2TP VPN
         clients, on the Static Route page (themiron)
  - NEW: Added notification when jffs free space drops below
         3 MB.
  - NEW: Added notification when jffs free space drops
         below 3 MB.
  - UPDATED: Merged GPL 384_9354 for AX models.
  - UPDATED: Merged GPL 384_81992 for mainline models.
  - UPDATED: Merged SDK + binary blobs 384_9354 for RT-AX58U.
  - UPDATED: Merged SDK + binary blobs 384_9107 for RT_AX88U.
  - UPDATED: Merged binary blobs + SDK 384_81981 for RT_AC5300.
  - UPDATED: Merged binary blobs + SDK 384_81992 for RT-AC86U.
  - UPDATED: Merged bwdpi components from 385_20630 firmware
             image for RT-AC68U.
  - CHANGED: Improved mechanism for providing an available
             mount point for addon API scripters (dave14305)
  - CHANGED: Harmonized the various SSL certificate modes with
             upstream.
             0-None - will be self-generated
             1-Imported - lets you upload your own (no longer
                           self generated unless you don't
                           upload one)
            2-Let's Encrypt (unchanged)
            Self-generated cert will be stored to /jffs/cert.tgz,
            just like upstream.
  - FIXED: Broken French webui on AX models (fixed with
           Asus's GPL update)
  - FIXED: Chacha20 wasn't prioritized for bcm675x models which
           lacked AES acceleration (RT-AX56U and RT-AX58U)
Sorry where can I download the 384.19 alpha 1 for RT-AC86U
 
@TimmyL, you can't download it yet. But you can compile it yourself if you're able to. :)
 
Why is Bandwidth meter on Network map showing 450KB/s download, but Adaptive QoS Bandwidth Monitor shows ZERO. Something is not right here. RT-AX58U. The data transfer is being done on a wired client (Windows PC).
 
I compiled 384.19 alpha 1 build for my Asus 86u once I saw the new GPL (384_81992) merged.
It looked like there were limited improvements over the .18 base: three or four security issues and OpenVPN bug fixes, maybe some already in .18?
 
Why is Bandwidth meter on Network map showing 450KB/s download, but Adaptive QoS Bandwidth Monitor shows ZERO. Something is not right here. RT-AX58U. The data transfer is being done on a wired client (Windows PC).

The same thing happens to me but with the upload not with the download, maybe for that reason upload limit in the adaptive qos doesn't work.

EAmy.jpg
 
Last edited:
I don't get it. Bandwidth monitoring on router keeps saying something is being transferred at 450KB/s on wired interface basically entire day, but when I looked on said wired device, there were no transfers being done. What the hell? I've even disabled QoS entirely now and it's the same. That's weird.

Shut down the only wired client and it's still showing constant 450KB/s. Now, the only wired client left is IPTV which should be bypassing all display in the interface. And bitrate seems a bit low for HD TV image... What the hell is going on here?

EDIT:
Yup, somehow Internet Traffic is capturing IPTV traffic. Turned off IPTV and the traffic dropped to zero. Weirdly, it's not showing anywhere else but here and under Traffic Analyzer. I don't think it used to be this way, IPTV used to be entirely separate and entirely immune to any control or monitoring. That doesn't seem to be the case anymore.
 
Last edited:
I compiled 384.19 alpha 1 build for my Asus 86u once I saw the new GPL (384_81992) merged. Works great. I guess the new builds for the rest model are gonna be available very soon

Code:
384.19 (xx-xxx-2020)
  - NEW: Added support for static routes for PPTP/L2TP VPN
         clients, on the Static Route page (themiron)
  - NEW: Added notification when jffs free space drops below
         3 MB.
  - NEW: Added notification when jffs free space drops
         below 3 MB.
  - UPDATED: Merged GPL 384_9354 for AX models.
  - UPDATED: Merged GPL 384_81992 for mainline models.
  - UPDATED: Merged SDK + binary blobs 384_9354 for RT-AX58U.
  - UPDATED: Merged SDK + binary blobs 384_9107 for RT_AX88U.
  - UPDATED: Merged binary blobs + SDK 384_81981 for RT_AC5300.
  - UPDATED: Merged binary blobs + SDK 384_81992 for RT-AC86U.
  - UPDATED: Merged bwdpi components from 385_20630 firmware
             image for RT-AC68U.
  - CHANGED: Improved mechanism for providing an available
             mount point for addon API scripters (dave14305)
  - CHANGED: Harmonized the various SSL certificate modes with
             upstream.
             0-None - will be self-generated
             1-Imported - lets you upload your own (no longer
                           self generated unless you don't
                           upload one)
            2-Let's Encrypt (unchanged)
            Self-generated cert will be stored to /jffs/cert.tgz,
            just like upstream.
  - FIXED: Broken French webui on AX models (fixed with
           Asus's GPL update)
  - FIXED: Chacha20 wasn't prioritized for bcm675x models which
           lacked AES acceleration (RT-AX56U and RT-AX58U)

I think you'll find that, while the base self-compile works well with most add-ons - the webui pages of @Jack Yaz for YazFI, spdMerlin and uiDivStats don't work. The pages are there but the data isn't. My self compile for both RT-AC86U and RT-AC5300 worked with above limitations.

The webui data for Skynet on the Firewall Tab and for Unbound on the Addons Tab work fine with all data displaying.

Best to wait for RMerlin to release code for RT-AC86U and RT-AC5300. Quite likely more under the hood work is required.
 
The same thing happens to me but with the upload not with the download, maybe for that reason upload limit in the adaptive qos doesn't work.

EAmy.jpg

Someone else posted about this on the 384.18 firmware aswell however when I test it works fine for me.

 
Last edited:
Someone else posted about this on the 384.18 firmware aswell however when I test it works fine for me.

For me it works with traditional qos, upload download and qos work well. But with the adaptive qos upload doesn't work, in 384.18 this did not happen to me, but adaptive qos it didn't work for me either.

If the next firmware fixes the upload on the adaptive qos, it would be a great firmware.
 
For me it works with traditional qos, upload download and qos work well. But with the adaptive qos upload doesn't work, in 384.18 this did not happen to me, but adaptive qos it didn't work for me either.

If the next firmware fixes the upload on the adaptive qos, it would be a great firmware.

My test is done with QOS off.
 
How does Merlin know about mistakes if everyone waits?

When Merlin releases an Alpha 384.19 version for the RT-AC86U and or the RT-AC5300 ... or for any other models in addition to the two models he has so far compiled - it will be appropriate to test and respond.

My comments related specifically to a post [quoted in my reply above] from @Delusion who had, like me, self compiled for our routers. His post implied that everything was good to go in HIS RT-AC86U compile [Not Merlin's compiled for that model] and I simply pointed out there were still hiccups to be dealt with.
 
Last edited:
When Merlin releases an Alpha 384.19 version for the RT-AC86U and or the RT-AC5300 ... or for any other models in addition to the two models he has so far compiled - it will be appropriate to test and respond.

My comments related specifically to a post [quoted in my reply above] from @Delusion who had, like me, self compiled for our routers. His post implied that everything was good to go in HIS RT-AC86U compile [Not Merlin's compiled for that model] and I simply pointed out there were still hiccups to be dealt with.

Ohhh right.. everything works fine on my setup (in the signature ) .
 
I've been having problems with AiMesh and Merlin releases for a while now.

The XT8s are quite slow to connect to the 5GHz band which causes node parent connection selection to be even worse than usual.

But yesterday I thought I'd give this release a try on my AX88U with an AC86U as a node and it couldn't associate with the 5GHz band on the AX88U at all.

I will eventually do a factory reset on the AX88U and try again but I'm not hopeful because I first saw this behaviour following a factory reset and configure.
 
AiProtect happy with that site here.......
Allow
I’m wondering if I need to have AiProtect enabled, doesn’t seem to be doing anything?

same here allows accesss access.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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