[BETA] Asuswrt-Merlin 380.59 Beta 1 is now available

[RMerlin]

Just sent via email.

Thanks, I'll take a look. At first glance something might still be missing, there's no private.o (not sure it's needed for old MIPS models tho) or ate.o.

 

[RMerlin]

Are you talking about the Advance--> Lan-->DHCP Server Tab ate the bottom where it say Manually Assigned IP around the DHCP list ?

If so specifically what kind of feedback do you want that is all I use for all devices? I have an AC5300 BTW

That's correct. I need to ensure that people can still safely remove, add, or edit entries in that list.

 

[bobiii]

Just added two new entries in my DHCP list. Hit apply and everything looks great! This is on my RT-AC5300.

 

[Matt Hettermann]

Thanks, I'll take a look. At first glance something might still be missing, there's no private.o (not sure it's needed for old MIPS models tho) or ate.o.

I did a search of the entire tarball and neither of those files exist ...

 

[Phil Schaffer]

That's correct. I need to ensure that people can still safely remove, add, or edit entries in that list.

I haven't had any issues adding or deleting entries on my AC5300. However, I have a few problematic entries that I can't edit the name for. Specifically, these are addresses 192.168.1.200 thru 207. These eight entries are all for the same type of device, Nest smoke detectors. I have a total of 51 DHCP reservations both above and below this range. When I try to change these, everything seems to work right up to clicking apply but the device name never changes from "New Device".

On another issue, I have not been able to get the Client List to work. If I click View List, the list doesn't populate initially. If I then click By Interface, the wired list will populate but none of the wireless lists show any clients even though there are many connected. Clicking on the number of clients connected instead of View List works fine and shows the clients on the right hand side of the screen.

Phil

Sent from my SM-T810 using Tapatalk

 

[idimitro]

You managed to skip both my devices with this update. Any news when can we expect version for RT-66N and RT-AC56

 

[mstombs]

You managed to skip both my devices with this update. Any news when can we expect version for RT-66N and RT-AC56

All files needed to compile are now in git, fingers crossed the firmwares will be there for beta2, along with other improvements learnt from beta1 on the other models.

 

[SMN]

Regarding MU-MIMO, i can confirm no M flag in 87U wireless log for Galaxy S7 which is supposed to support MU-MIMO.
Not sure which one at fault.

 

[GoNz0]

Still looking for more user feedback about this updated page. Please test editing, adding and removing entries.

Also, more feedback related to SMB sharing would be appreciated, especially in these areas:

- People who previously had trouble accessing using a username/password, does it work more reliably now that spnego has been enabled?
- Benchmark numbers showing throughout of 380.58 vs 380.59 for the RT-AC68U and RT-AC87U (performance settings were changed for these model's SMB configuration)

If nothing else is reported, there will be at least a second beta release in the coming days.

Thanks!

Works fine here, restored setting ok and assigned a new device. Removed an old one, edited another. (AC68u)

 

[Stach]

That's correct. I need to ensure that people can still safely remove, add, or edit entries in that list.

RMerlin, I apologize in advance if this has been answered before, but any chance that the DHCP lease reservations could be stored in JFFS (like the OpenVPN variables are now), so that we conserve the precious NVRAM? It seems like the heavy users of your firmware (like me) have lots of devices and want to know exactly where they are via lease reservations.

-Stach

 

[malinois1]

That's correct. I need to ensure that people can still safely remove, add, or edit entries in that list.

Yes sir it is functioning correctly just as good as the official with better icon choices. I have about 20 devices in the list that I assign ip addys. I edit the host name if I don't like the default name to better recognize it which is probably 1/4 of those devices. I just deleted a few and verified in the network map that it showed DHCP as opposed to manual. I also change some of the icons and they all seem to stick and transfer to the network map. BTW I am using a RT- AC5300

 

[RMerlin]

I did a search of the entire tarball and neither of those files exist ...

I see they aren't in the AC66U tarball either.

private.o is probably only needed by models with a BCM5301x switch. As for ate.o, I can (still) build it myself, so this shouldn't be a problem either.

 

[RMerlin]

I haven't had any issues adding or deleting entries on my AC5300. However, I have a few problematic entries that I can't edit the name for. Specifically, these are addresses 192.168.1.200 thru 207. These eight entries are all for the same type of device, Nest smoke detectors. I have a total of 51 DHCP reservations both above and below this range. When I try to change these, everything seems to work right up to clicking apply but the device name never changes from "New Device".

"New Device" is a description, not a hostname. To change the description, you have to go through the Network Client List, not through the DHCP page.

On another issue, I have not been able to get the Client List to work. If I click View List, the list doesn't populate initially. If I then click By Interface, the wired list will populate but none of the wireless lists show any clients even though there are many connected. Clicking on the number of clients connected instead of View List works fine and shows the clients on the right hand side of the screen.

I've heard a few reports of missing entries for the past few firmware releases. However I'm unable to reproduce the issue here, so it will have to be resolved by Asus in a future release I'm afraid.

 

[RMerlin]

Regarding MU-MIMO, i can confirm no M flag in 87U wireless log for Galaxy S7 which is supposed to support MU-MIMO.
Not sure which one at fault.

It's possible that the Quantenna SoC used on the RT-AC87U doesn't properly report whether a client supports MU-MIMO or not. I only tested the Broadcom support. I'll check if Asus did implement MU-MIMO report for the RT-AC87U.

 

[RMerlin]

RMerlin, I apologize in advance if this has been answered before, but any chance that the DHCP lease reservations could be stored in JFFS (like the OpenVPN variables are now), so that we conserve the precious NVRAM? It seems like the heavy users of your firmware (like me) have lots of devices and want to know exactly where they are via lease reservations.

-Stach

No. The JFFS storage should always be a last resort, and only for very specific things. The reasons:

1) JFFS partition is NOT guaranteed to survive a firmware upgrade. It means, for instance, RT-N66U users might be forced to reconfigure all their DHCP leases every time they flash a new firmware (since the RT-N66U has a dynamicaly sized JFFS partition)

2) JFFS content is not backedup/restored along with other settings. It would become confusing for users if their settings backup might end up be missing such a commonly used feature

3) That would require extensive changes throughout the firmware code to redirect everything that deals with that specific nvram setting

 

[swetoast]

i see RT-AC56U mentioned in the changelog but no beta available guessing this build is just for MU-MIMO routers, so am i right im my assumption?

 

[RMerlin]

i see RT-AC56U mentioned in the changelog but no beta available guessing this build is just for MU-MIMO routers, so am i right im my assumption?

Please read the first sentence of the first post in this thread.

 

[RMerlin]

Seems that the closed source components were updated in the tree but I have to refrain from using this beta on my AC56U, one of the known issues is traditional QoS not working which is a deal breaker for my network. Will wait for newer versions.

BTW, I was able to spend some time testing Traditional QoS + my new QoS code last night, with an RT-AC68U. As I thought, Traditional QoS is still working fine with the RT-AC68U (and so it should also be fine on the RT-AC56U). The issue lies only with newer models.

So I was able to do a couple of tests involving SFQ versus fq_codel versus OpenWRT's SQM implementation. The results were not entirely what I expected... I'll need to digest the data first before deciding what to do with these results. But the first thing I noticed, and which didn't really surprise me: from purely a bufferbloat point of view, using DSLReports's bufferbloat tests? I get similar, even slightly better results with... Asus's SFQ implementation. Switching it to fq_codel gave me slightly HIGHER latency.

But that's not the only piece of data I've collected. I'll need to analyze the rest before deciding what to do with it.

But in the meantime, feel free to switch to 380.59 - your T-QoS should still work properly on your RT-AC56U.

 

[swetoast]

Please read the first sentence of the first post in this thread.

ahhh hehe well just my luck to have that model, any ideas of when its gonna be resolved ?

 

[RMerlin]

ahhh hehe well just my luck to have that model, any ideas of when its gonna be resolved ?

And the answer is in the SECOND post of the thread.