Beta Asuswrt-Merlin 386.2 Beta is now available

[joegreat]

P.S. And I did a full factory reset just before going to the Beta. I was doing a lot of dirty updates, so after updating to the atest stable - made a full reset, with formatting usb and jffs and reconfiguring everything from scratch manually.

I think you need another factory reset. Those numbers look like they belong to unrelated nvram vars wl1_chansps or wl1_chlist. So something bad is happening.

Yes, always do Factory Reset AFTER firmware update/install - doing it before makes no sense for the later firmware...

 

[jerrytouille]

386.2 beta1 issue: ssh does not login when enabled, had to reboot the router for it to work

 

[Mutzli]

Any tweaks done? or is that default config?

All default as set by Merlin. Besteffort and with wash enabled for ingress.

 

[RMerlin]

Yeah but it's going up significantly fast . Like a day I think it got up from 0 to 3MB. Like does it have a limit so we don't have to worry ?

I don't know, but Asus generally has limits in place on databases. My own is also 3 MB.

 

[Wade Coxon]

I've also added iptables rules for Teams and Zoom to ensure that it takes advantage of the Voice tin in diffserv3 on upload.
This is the contents of my /jffs/scripts/qos-start script. I have IPv6 enabled, so the last 4 lines aren't needed if you do not have IPv6 enabled.

#!/bin/sh

iptables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF 2>/dev/null
iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF
iptables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF 2>/dev/null
iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF

ip6tables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF 2>/dev/null
ip6tables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF
ip6tables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF 2>/dev/null
ip6tables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF

Thanks for that post. That was a handy reference.
Where was the information about the "ULOPTIONS" and "DLOPTIONS" variables in the first place? RMerlin mentions that the cake-qos.conf.add file was for adding configurations, but made no mention of "how". I presume you just looked into the /tmp/qos script to work that out, or did I miss the documentation?

Second question regarding your DSCP tagging rules. Is there a mechanism for adding download rules that I am missing? The qos-start script is run before /tmp/qos, so the ifb4eth0 will not have been created yet, making it impossible to add download rules to qos-start I would have thought?

@RMerlin Shouldn't we also have a post-qos-start script (or something like that) as well so we have a nice place to stick additional DSCP tagging rules?

 

[goodwin_c]

Yes, always do Factory Reset AFTER firmware update/install - doing it before makes no sense for the later firmware...

I didn't say that i did reset FOR beta update. I did it to be sure that stable release will work fine. But later did dirty update to Beta. I know that reset makes sense after not before update However, this doesn't answer why there are issues with firewall rules and internet connection (or maybe they are connected?) - doing a quick check on the nvram values and on the code in the firewall.c - I don't see any reason why it shouldn't work properly
Changes between last stable and this Beta doesn't look so significant to say that one more factory reset will definitely do a trick (but maybe I'll try, just for clean experiment. even if I'm 90% sure that this will not change anything)

 

[underdose]

Where was the information about the "ULOPTIONS" and "DLOPTIONS" variables in the first place?

tc-cake(8) - Linux manual page

 

[Wade Coxon]

tc-cake(8) - Linux manual page

No, those are the cake options and I am aware of where to find documentation for those.

I am referring to the syntax for adding those options into the cake-qos.conf.add file.

I only knew how to add those options after manually examining the /tmp/qos script.

 

[dave14305]

Thanks for that post. That was a handy reference.
Where was the information about the "ULOPTIONS" and "DLOPTIONS" variables in the first place? RMerlin mentions that the cake-qos.conf.add file was for adding configurations, but made no mention of "how". I presume you just looked into the /tmp/qos script to work that out, or did I miss the documentation?

Second question regarding your DSCP tagging rules. Is there a mechanism for adding download rules that I am missing? The qos-start script is run before /tmp/qos, so the ifb4eth0 will not have been created yet, making it impossible to add download rules to qos-start I would have thought?

@RMerlin Shouldn't we also have a post-qos-start script (or something like that) as well so we have a nice place to stick additional DSCP tagging rules?

It’s beta. Why write the documentation before the final release?

I looked at code and took advantage of my early access to the Cake builds. There’s no download rules because iptables is too late in the flow for downloads. That’s why you’ve been bugging Merlin for skbedit.

 

[dave14305]

The qos-start script is run before /tmp/qos, so the ifb4eth0 will not have been created yet, making it impossible to add download rules to qos-start I would have thought?

You can use qos-start to append commands to /tmp/qos.

 

[RMerlin]

@RMerlin Shouldn't we also have a post-qos-start script (or something like that) as well so we have a nice place to stick additional DSCP tagging rules?

There is, it's qos-start.

 

[Wade Coxon]

I looked at code and took advantage of my early access to the Cake builds. There’s no download rules because iptables is too late in the flow for downloads. That’s why you’ve been bugging Merlin for skbedit.

Yep, sorry, I was probably not explaining myself properly.

What I am looking for is a nice neat location/script for defining the skbedit rules which will execute after /tmp/qos

At the moment, there doesn't appear to be a readily available script that runs after the download interface is created.

 

[RMerlin]

I don't see any reason why it shouldn't work properly

Neither do I, which is why I suspect nvram corruption at this point.

        for(unit = WAN_UNIT_FIRST; unit < wan_max_unit; ++unit){
                if(!is_wan_connect(unit))
                        continue;

                snprintf(prefix, sizeof(prefix), "wan%d_", unit);
                wan_if = get_wan_ifname(unit);
                wanx_if = nvram_safe_get(strcat_r(prefix, "ifname", tmp));
                wanx_ip = nvram_safe_get(strcat_r(prefix, "xipaddr", tmp));

#ifdef RTCONFIG_TAGGED_BASED_VLAN
        /* Write forward rule for vlan */
        vlan_subnet_filter_forward(fp, wan_if);
#endif

#ifdef RTCONFIG_AMAS_WGN
        wgn_filter_forward(fp, wan_if);
#endif
// ~ oleg patch
                /* Filter out invalid WAN->WAN connections */
                fprintf(fp, "-A FORWARD -o %s ! -i %s -j %s\n", wan_if, lan_if, "other2wan");
#ifdef RTCONFIG_IPV6
                 if (ipv6_enabled() && *wan6face) {
                        if (nvram_match("ipv6_fw_enable", "1")) {
                                fprintf(fp_ipv6, "-A FORWARD -o %s -i %s -j %s\n", wan6face, lan_if, logaccept);
                        } else {        // The default DROP rule from the IPv6 firewall would take care of it
                        fprintf(fp_ipv6, "-A FORWARD -o %s ! -i %s -j %s\n", wan6face, lan_if, logdrop);
                        }
                }
#endif
                if (strcmp(wanx_if, wan_if) && inet_addr_(wanx_ip) && dualwan_unit__nonusbif(unit))
                        fprintf(fp, "-A FORWARD -o %s ! -i %s -j %s\n", wanx_if, lan_if, "other2wan");
        }

 

[Wade Coxon]

There is, it's qos-start.

In your first post you said that qos-start runs before /tmp/qos

If so, that won't allow me to add download DSCP rules because the download interface will not exist yet.

Or did have I missed something?

 

[RMerlin]

The original numbers in the firewall rules look bad (57 161 165).

This looks like the end of the wl1_chlist nvram content.

 

[RMerlin]

In your first post you said that qos-start runs before /tmp/qos

If so, that won't allow me to add download DSCP rules because the download interface will not exist yet.

Or did have I missed something?

You can use that script to modify the content of /tmp/qos.

Another option could be that I add a "running" state to qos-start. It currently runs with $1 being passed "init", I could run it a second time afterward with "running" passed as $1. It would however introduce an inconsistency, as that event would only occur in Cake mode (and T.QoS if I added it, but I can't add it to A.QoS as that gets setup asynchronously from rc).

 

[Wade Coxon]

You can use that script to modify the content of /tmp/qos.

Another option could be that I add a "running" state to qos-start. It currently runs with $1 being passed "init", I could run it a second time afterward with "running" passed as $1. It would however introduce an inconsistency, as that event would only occur in Cake mode (and T.QoS if I added it, but I can't add it to A.QoS as that gets setup asynchronously from rc).

Ahh gocha, yep, I see what you mean now.

Probably best not to call qos-start twice then.
I'll have a play and see if I can adapt any of the rules I found on the OpenWRT forums.

You're a legend

 

[goodwin_c]

This looks like the end of the wl1_chlist nvram content.

Nope, not really
wl1_chlist=36 40 44 48 149 153 157 161 165
But yeah, if I'll not find a root cause of that error message - as last resort, I will do factory reset, just to be sure

 

[MvW]

Not a bug report regarding this beta, but just a heads up for those of you using the add-on spdMerlin and have AutoBW activated, it looks like builtin Cake in this beta is not compatible with AutoBW, probably causing your up- and downstream to be drastically lowered over a period of approximately 24 hours.

See my experiences here: https://www.snbforums.com/threads/b...m-gradually-lowered-over-past-24-hours.71067/

For now, manually adjust to 95% of your actual upstream and downstream bandwidth (run a speedtest after you changed the values to 95% of the theoretical max up- and downstream, re-adjust the values to 95% of realistic values) and disable AutoBW for now until a solution is found.

For those who where affected as well: the issue with spdMerlin and Cake QoS has been solved in the latest release of spdMerlin by @Jack Yaz. Just update through amtm to version 4.1.2 and re-enable AutoBW and all will be fine.

Best regards,

Marco

 

[dave14305]

You can use that script to modify the content of /tmp/qos.

Another option could be that I add a "running" state to qos-start. It currently runs with $1 being passed "init", I could run it a second time afterward with "running" passed as $1. It would however introduce an inconsistency, as that event would only occur in Cake mode (and T.QoS if I added it, but I can't add it to A.QoS as that gets setup asynchronously from rc).

Or invoke qos-start with the “rules” parameter already used with t.QoS.