[Beta] Asuswrt-Merlin 384.18 Beta / 384.13_9 is now available

[Rhialto]

You need a forced refresh, i.e. press shift while pressing on the reload icon. This will force your browser to bypass its (outdated) cache content.

Isn't CTRL-F5 more effective?

 

[mbze430]

WAN Aggregation with LAN Aggregation both enabled still missing wired lan devices in the Network Map/List

 

[bughit]

This is the developer's problem (mine), not the end user's.

@RMerlin

The changelog is published for the end user, its absurd to then claim that the user doesn't need to understand it, and that's all I am trying to do.

Is it the case that the GPL release versions can't be compared across models? If so, can you include in the changelog from which model the gpl version is taken? Otherwise it's a meaningless number.

I did figure out the significance of "code is identical to 384_81846". 384_81846 GPL was used in a prior alpha, the chnagelog for which is not on the main changelog page. If you know this fact, the phrase makes perfect sense, it says the gpl code did not change between the alpha and beta, despite the version bump. But someone just looking at at the changelog page would not understand that. You knew perfectly well what I was asking and why.

 

[jsbeddow]

@RMerlin

You knew perfectly well what I was asking and why.

Wow, it might be time to reconsider your attitude a bit and consider this: this is an amazing project that adds tremendous value to our Asus routers, it is provided entirely free, with an equally impressive level of support provided by both other end users and @RMerlin. The fact that he is even able to add his customization features and stability to the Asus code does not entitle you to demand more in the form of explicit changelog details and a "map" of what Asus has created in their confusing release number ordering. He is simply working with what they provide as GPL code, and yes, that might mean that it is not always exactly up to date in comparison to what they release as finished binary firmware.

 

[Howard_inGA]

11 hours on beta...no problems. Did the update on the 3200 as well. Again, flawless...

 

[RMerlin]

Isn't CTRL-F5 more effective?

Depends on your workflow I suppose. I'm just used to shift-clicking because I know it works in every browsers.

 

[RMerlin]

RT-AC88U

Please give this test build a try:

http://www.asuswrt-merlin.net/test-builds

Took a few iterations, but this one seems to work fine... so far.

 

[themiron]

@RMerlin
Is it the case that the GPL release versions can't be compared across models? If so, can you include in the changelog from which model the gpl version is taken? Otherwise it's a meaningless number.

seems you're asking right question but to the wrong person. version numbers and newer/older deps questions should be asked directly to asus, I believe, 'coz they are upstream of that gpls, not @RMerlin.

 

[Morac]

RT-AC88U

Please give this test build a try:

http://www.asuswrt-merlin.net/test-builds

Took a few iterations, but this one seems to work fine... so far.

What GPL is this based off of? An unreleased one?

 

[Asad Ali]

What GPL is this based off of? An unreleased one?

384_81918

 

[RMerlin]

What GPL is this based off of? An unreleased one?

Specially compiled version that I received, not off an official GPL release.

EDIT: Should actually be 384_81918, not 81919. Too many version strings to keep track of right now...

 

[Morac]

Specially compiled version that I received, not off an official GPL release.

Thanks. Hopefully it has the KrØØk patch in it.

 

[RMerlin]

Thanks. Hopefully it has the KrØØk patch in it.

In theory it should.

 

[Vexira]

Super stable so far so good no issues I've noticed as of late stable as always.

 

[MegaTronics]

I have running Merlin based firmware for years on my rt-ac68u , but with the last couple of versions I always ran into problems with the port forwarding.

When I install the different firmwares, I did a factory reset and build all the settings from scratch and it was working alright, inbound and outbound traffic . But after some time the inbound traffic (port forwarding) stops working. There is no more response on the outside on the different ports (for example HTTP(S) and SSH) from the internal servers. Internet access from the local network works just fine without any problems.

The OpenVPN connection to the router still works, so when I am external, I can logon to the internal network and reset the router from there, after the reboot, the port forwarding is working again for some time, but eventually it stops working again.

I have also tried a new rt-ac68u router to exclude some hardware issue with the old router, but the problem still is there.

I now run the stock firmware 3.0.0.4.385.20490 from Asus on both routers (the second one is now an AiMesh extension) without any problems after weeks of uptime.

Are there more people here who faced the same problems and most important is it fixed in one of the latest firmwares?

 

[netware5]

.....................what Asus has created in their confusing release number ordering. .......................

That's the main problem .... Unfortunately out of RMerlin's and users' control ....

 

[Jasso]

Are there any likely problems with dirty flash from 384.15?

 

[pinkgrae]

Are there any likely problems with dirty flash from 384.15?

@Jasso Love Lake Ballard!

 

[maxbraketorque]

Running 384.18 b1 on AC86U main/AP combos at two locations. Both are working well so far, but at my home AC86U combo that has more features enabled, I got the following log entries last night:

Jun 20 23:21:14 kernel: pgd = ffffffc010d49000
Jun 20 23:21:14 kernel: [00000000] *pgd=0000000010d4a003, *pud=0000000010d4a003, *pmd=00000000132b0003, *pte=0000000000000000
Jun 20 23:21:14 kernel: CPU: 1 PID: 2408 Comm: dcd Tainted: P O 4.1.27 #2
Jun 20 23:21:14 kernel: Hardware name: Broadcom-v8A (DT)
Jun 20 23:21:14 kernel: task: ffffffc0145cc180 ti: ffffffc010dcc000 task.ti: ffffffc010dcc000
Jun 20 23:21:14 kernel: PC is at 0x29b6c
Jun 20 23:21:14 kernel: LR is at 0x29dec
Jun 20 23:21:14 kernel: pc : [<0000000000029b6c>] lr : [<0000000000029dec>] pstate: 200f0010
Jun 20 23:21:14 kernel: sp : 00000000fff7fd90
Jun 20 23:21:14 kernel: x12: 00000000000a002c
Jun 20 23:21:14 kernel: x11: 0000000000080c14 x10: 0000000000000006
Jun 20 23:21:14 kernel: x9 : 0000000000000003 x8 : 0000000000000006
Jun 20 23:21:14 kernel: x7 : 00000000f5cfe888 x6 : 0000000000000035
Jun 20 23:21:14 kernel: x5 : 0000000000000043 x4 : 00000000f5cfe8e8
Jun 20 23:21:14 kernel: x3 : 0000000000000000 x2 : 0000000000000005
Jun 20 23:21:14 kernel: x1 : 000000000000000a x0 : 0000000000000000​

 

[Stevens243]

Dirty flash from .17. No issues. I did the mesh node (AC88U) first using the above link to the beta .trx file. Flashed fine. Unplugged the flash drive from the 86U (since I'm not feeling overly lazy today) and flashed the .18 Beta on it. No issues. Both the 86 and the 88U are up and running on .18Beta, clients connected and no logged issues to report.

I'm pretty sure the AC88U test request was for use as a router but it's working just fine as a mesh node as well.