[Beta] Asuswrt-Merlin 384.16 beta (and 384.13_5) are available

[digits n bits]

Running 384.16 beta on my 88U and 58U both running really well, top class job thanks

 

[RMerlin]

Mar 15 11:32:30 kernel: dimchief.ignorelist.com:Verify error:Fetching http://dimchief.ignorelist.com/.wel...e/ijxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQo: Connection refused

The remote site unable to connect with you to validate that you truly use that domain. Make sure you aren't in a dual NAT situation, and that there are no firewall in front of your router.

Does 384.16 include the 3.0.0.4.384.81352 release which patches the Kr00k vulnerability in the RT-AC86U?

The current GPL merge is always specified in the changelog. There has been no GPL release from Asus with these fixes, so none of them are present at this time.

A stubby upgrade was noted in the changelog. It's been a while since I've visited that thread, so I'm out of that loop (and frankly can't remember if I have to add it via terminal or amtm/Diversion or if it's part of the firmware for DoT, selectable/configurable in the UI).

Anything that I label as being updated means it's part of the firmware, and not an external add-on.

 

[Max33Verstappen]

AX88U:
On beta1, this issue persists (starting from alpha 2):
There's sth wrong about the scaling of the chart of 24hr traffic monitor. It just scales up for no reason. The ceiling value is now 1361462.40KB/s, rendering it useless. After restart the 'rstats', it starts normally, but gradually increases the ceiling indefinitely. (There's nothing crazy for the value displayed in the table below the chart.)
Didn't experience it on alpha 1.

 

[RMerlin]

Looks like 384.16_beta1 has the Traffic Analyzer bug again where it thinks it has transmitted/received 17,179,869,180.10 GB or something. RT-AC68U. Daily: https://i.imgur.com/A4DRl5A.png 24-hour: https://i.imgur.com/laREjN1.png

Asus issued a fix in 386_36400 which I backported, in hopes it resolved those spikes. I guess it didn't.

Ipv6 stopped transmitting internet access after updating to beta 1 on the RT AX88u

What kind of IPv6 connection? What's in your system log? Do you still obtain an IPv6?

 

[The Chief]

The remote site unable to connect with you to validate that you truly use that domain. Make sure you aren't in a dual NAT situation, and that there are no firewall in front of your router.

No dual NAT, no extra firewall. After manually deleting hidden '/jffs/.le' folder new cert was issued without any problem.

 

[elorimer]

Sorry to be blind...where is the separate changelog for 13_5 for the 87U? Not part of the beta download.

 

[Zastoff]

Sorry to be blind...where is the separate changelog for 13_5 for the 87U? Not part of the beta download.

https://github.com/RMerl/asuswrt-merlin.ng/blob/384.13_x/Changelog-NG.txt

 

[Yota]

I think upload and download colors can be better!

• Red usually means slow, so don't use it.

• Yellow is faster than red and can be used as download, just like asus did on the traffic analysis page.

• Blue usually means fast, asus is used in traffic analysis pages.

• Dark blue means extreme speed.

However, because the page theme is dark, I think it would be better to use light colors. such as using yellow and blue, Green is also good, but it should be light green., or we can use the speedtest.net color scheme, Blue for download, Purple for upload.
but, too many inconsistent color schemes can cause confusion for users.

So, what do you think?

picture from here

 

[Chazall1]

Running 384.16 beta and all running great here.

Thanks

 

[FTC]

I think upload and download colors can be better!

• Red usually means slow, so don't use it.

• Yellow is faster than red and can be used as download, just like asus did on the traffic analysis page.

• Blue usually means fast, asus is used in traffic analysis pages.

• Dark blue means extreme speed.

However, because the page theme is dark, I think it would be better to use light colors. such as using yellow and blue, Green is also good, but it should be light green., or we can use the speedtest.net color scheme, Blue for download, Purple for upload.
but, too many inconsistent color schemes can cause confusion for users.

So, what do you think?
View attachment 21960
picture from here

Those are good suggestions.. moreover, I see that beta1 has supposedly the scale linked to the QoS settings as long as it is activated. I feel this should be also usable when QoS is NOT activated, just like the QoS monitor graph does. And like that one, if the max is not set, the graph should at least be logarithmic AND start with a much higher value (100Mbits/sec or similar).

This way when you just load the page and see a long usage bar, you can be sure that the traffic usage is significant.
At the same time (being logarithmic scale) the bar is meaningful for almost any bandwidth level The way it is now can be a bit misleading.

Eric, what do you think ?

 

[RMerlin]

Sorry to be blind...where is the separate changelog for 13_5 for the 87U? Not part of the beta download.

Get it from the support site. My build script cannot properly deal with having multiple different changelogs, and I forgot to merge the 384.13_5 portion into the main changelog.

I think upload and download colors can be better!

That makes no sense. Just because you aren't doing a large download shouldn't scare you or confuse you by showing different colours.

but, too many inconsistent color schemes can cause confusion for users.

Which is why I reused colours already used on the webui, rather than define a new colour just for this meter. Consistency is important here. I reused the colours I use on the Traffic Monitor, but I am considering possibly changing them to reuse colours used by the other bar charts on the same page. I'm reluctant to do so because, quite frankly, Asus chose pretty bad colours in general on that particular page.

just like the QoS monitor graph does.

The QoS monitor doesn't. It merely sets a baseline of 100 KB/s (which is what I was using in the alpha builds).

the graph should at least be logarithmic AND start with a much higher value (100Mbits/sec or similar).

No. That would mean that a large majority of users would never see anything remotely accurate. Here in Canada, the average connection is well below 100 Mbps. A large portion is on 25 Mbps DSL for instance.

The current behaviour is the one that makes the most sense. If you are only lightly using your connection, then you will get a very low usage report. If you have a slow connection and you fully load it, you will get fully accurate results (unless you were somehow on something slower than 1 Mbps). And if you have a fast one, it will scale appropriately with usage.

It's much more representative to show a short progress bar when not fully pushing your connection than having it never ever get filled even when downloading at full speed. Your brain will be able to tell that "very short bar = very low usage". Whether it shows a 2% bar or a 10% bar, your brain will still register it as being "very low usage".

The point here isn't to provide data that could be used in scientific studies. It's just to show a general report of whether your connection is currently fully used, or only lightly used. For this purpose, the current behaviour is the most accurate.

And using disabled QoS values is a bad idea. That setting isn't exposed unless you enable QoS, so users would never know that they should enable the setting, set values, then disable the setting. From a usability point of view, it makes no sense at all.

 

[Treadler]

Ipv6 stopped transmitting internet access after updating to beta 1 on the RT AX88u

IPv6 appears to be working fine here.
(Passes all the various online tests I can find).

 

[FTC]

The QoS monitor doesn't. It merely sets a baseline of 100 KB/s (which is what I was using in the alpha builds).


No. That would mean that a large majority of users would never see anything remotely accurate. Here in Canada, the average connection is well below 100 Mbps. A large portion is on 25 Mbps DSL for instance.

Sorry to disagree. Maybe I am seeing it wrong, but when I enter the QoS LAN/WAN Bandwidth you can clearly see logarithmic 'speedometers' in the upper part, as shown in the demoui also
:
http://demoui.asus.com/AdaptiveQoS_Bandwidth_Monitor.asp

For instance, the first 20Mb/s take half of the graph, and then other 80Mb/s do take the other half
so you can also see that users with connections even as low as 1Mb will see it perfectly.

 

[Deleted member 22229]

IPv6 appears to be working fine here.
(Passes all the various online tests I can find).

Same here IPv6 working as it should. Using Native.

 

[SomeWhereOverTheRainBow]

Asus issued a fix in 386_36400 which I backported, in hopes it resolved those spikes. I guess it didn't.



What kind of IPv6 connection? What's in your system log? Do you still obtain an IPv6?

i fixed the IPV6 issue @RMerlin , it wasn't firmware related, I just brought it up since it happen right after flashing the firmware. I had no logs to show that it wasn't working, it just wasn't transmitting the ipv6 connection (Issue with ISP connection coming in). However, it was properly assigning the ipv6 addresses to clients from the router. So after tinkering with the ISP(modem) and several refresh signals later, I got it to work.

The type of IPV6 connection was Native-Stateless.

 

[FTC]

And using disabled QoS values is a bad idea. That setting isn't exposed unless you enable QoS, so users would never know that they should enable the setting, set values, then disable the setting. From a usability point of view, it makes no sense at all.

I fully agree with you in this part, but that was not the idea. I was thinking more in the line of exposing these two values in the tools page, so that when you enable QoS, QoS will use them.

(and please forgive me if I seem like trying to force you to do one or another thing.. this are just ideas to improve the code's behavior. Note that I very much appreciate your work in any case)

 

[RMerlin]

Sorry to disagree. Maybe I am seeing it wrong, but when I enter the QoS LAN/WAN Bandwidth you can clearly see logarithmic 'speedometers' in the upper part, as shown in the demoui also
:

I was referring to the bargraphs shown below, next to each client, showing the volume of traffic for each of these.

Using a log scale for a bar graph does not work, because there is no visible scale next to it, so people expect these to be linear, as it's intended to report a relative value (in this case, current throughput versus maximum throughput). A speedometer with a needle is intended to report a specific value, and therefore it can use a non-linear scale and still be useful.

 

[RMerlin]

I fully agree with you in this part, but that was not the idea. I was thinking more in the line of exposing these two values in the tools page, so that when you enable QoS, QoS will use them.

Expecting people to go there to adjust the scale shown on a different page isn't intuitive, and nobody will use that except a very small handful of people who actually saw it mentionned here on the forums. And it won't take into account people misconfiguring it. Using these values while QoS is enabled will still work even when misconfigured, because that configuration error does impact the maximum speed they will be able to reach.

 

[FTC]

Expecting people to go there to adjust the scale shown on a different page isn't intuitive, and nobody will use that except a very small handful of people who actually saw it mentionned here on the forums. And it won't take into account people misconfiguring it. Using these values while QoS is enabled will still work even when misconfigured, because that configuration error does impact the maximum speed they will be able to reach.

Now this is a reasonable point (not too intuitive). I do not see these values either in the main page (where the graphs are).. Related to 'working' or not, the autoscale 'security net' should be used anyways (the same as the 'speedometers' do when you supass the 100Mb line.. then they do autoscale logatythmically to 1000Mb).

Thanks anyways for discussing this idea.

 

[MDM]

Dirty upgrade to 384.13_5, all is fine.
Tnx