[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[vincom]

i have 3.0.0.4.374.43_2-20B5j9527 on ac66u, is this older or newer(mine seems tobe a higher build number) than current release

 

[L&LD]

i have 3.0.0.4.374.43_2-20B5j9527 on ac66u, is this older or newer(mine seems tobe a higher build number) than current release

Yours is older ('B5'). The latest is 'B7'.

 

[vincom]

Yours is older ('B5'). The latest is 'B7'.

3.0.0.4.374.43_2-20B5j9527 current fw
3.0.0.4_374.43_2-19E3j9527

hard to tell which one is the newer one by looking at the fw title

 

[john9527]

Yours is older ('B5'). The latest is 'B7'.

Soon to be '20E2' and formally released (no longer a beta).....doing my final testing now

 

[john9527]

3.0.0.4.374.43_2-20B5j9527 current fw
3.0.0.4_374.43_2-19E3j9527

hard to tell which one is the newer one by looking at the fw title

The bigger the numbers/letters....the later the release. 'nnBx' are betas....'nnEx' are stable releases.

 

[KKLD]

Hey guys I am running older builds of this firmware on my AC66U and AC68U. Both working flawlessly!
I am wondering if it is safe for me to upgrade directly to the newest version, either V19E3 or V20B7.
My AC66U and AC68U both run 374.43_2-16E1j9527
Is there anything I might want to know before upgrading?
Thanks in advance

 

[john9527]

Hey guys I am running older builds of this firmware on my AC66U and AC68U. Both working flawlessly!
I am wondering if it is safe for me to upgrade directly to the newest version, either V19E3 or V20B7.
My AC66U and AC68U both run 374.43_2-16E1j9527
Is there anything I might want to know before upgrading?
Thanks in advance

You should be fine going directly to the latest stable release (the 'E' releases)...with no factory reset required. One of the final release tests I do is an update from 13E3 (this was a popular release for a long time).

The beta 'B' releases.....well, they are betas In most cases they are safe, but sometimes bad things can happen. We just went through an ugly firmware update problem on the beta related to one of the updates that turned out to be hardware rev level related. I still thank those that tried the betas and helped me to track it down.

Just to complete the picture, you should also be able to go backwards in the fork levels, although you can run into some problems if you aren't careful with the new options. For example, the later releases allow you to change the http port for the gui. If you change it and try to go back to a level that didn't support changing the port, you won't come up clean. In this case you would have to do a factory reset.

 

[L&LD]

3.0.0.4.374.43_2-20B5j9527 current fw
3.0.0.4_374.43_2-19E3j9527

hard to tell which one is the newer one by looking at the fw title

'20' is higher than '19'.

 

[ColinTaylor]

I've been experimenting with QOS (all types) in 374.43_2-19E3j9527 on a AC68U but can't seem to get it to do what I want.

Whatever I do I can't seem to get the QOS rules to effect either of my wireless laptops, it's as though the rules don't exist. It appears to work OK for my PC hard wired to the router though. Is it possible that there is something about wireless that changes the QOS markings?

UPDATE: Well I've had a look at /proc/net/ip_conntrack and as far I can see the marks are there. They are either 2 which is set by the rule, or 6 (the default?).

 

[KKLD]

You should be fine going directly to the latest stable release (the 'E' releases)...with no factory reset required. One of the final release tests I do is an update from 13E3 (this was a popular release for a long time).

The beta 'B' releases.....well, they are betas In most cases they are safe, but sometimes bad things can happen. We just went through an ugly firmware update problem on the beta related to one of the updates that turned out to be hardware rev level related. I still thank those that tried the betas and helped me to track it down.

Just to complete the picture, you should also be able to go backwards in the fork levels, although you can run into some problems if you aren't careful with the new options. For example, the later releases allow you to change the http port for the gui. If you change it and try to go back to a level that didn't support changing the port, you won't come up clean. In this case you would have to do a factory reset.

Thanks a lot for the explanation, I will keep that in mind. I upgraded both and they are running version V19E3 without problems so far!

 

[vincom]

Thanks a lot for the explanation, I will keep that in mind. I upgraded both and they are running version V19E3 without problems so far!

i did have to reinstall ab solutions though
but all other fw settings were working fine.

 

[john9527]

I've been experimenting with QOS (all types) in 374.43_2-19E3j9527 on a AC68U but can't seem to get it to do what I want.

Whatever I do I can't seem to get the QOS rules to effect either of my wireless laptops, it's as though the rules don't exist. It appears to work OK for my PC hard wired to the router though. Is it possible that there is something about wireless that changes the QOS markings?

UPDATE: Well I've had a look at /proc/net/ip_conntrack and as far I can see the marks are there. They are either 2 which is set by the rule, or 6 (the default?).

I just ran and checked on my AC68P and all seems to be working......

So.....I thought I read you had recently got a speed boost on you ISP connection? If you are running traditional QoS, are you sure that your wireless clients are fast enough to hit the download/upload limits? My wireless AC laptop can run faster than my ISP connection though.

Bandwidth limiter should work if you set the limits below the wireless actual rates.

 

[ColinTaylor]

I just ran and checked on my AC68P and all seems to be working......

So.....I thought I read you had recently got a speed boost on you ISP connection? If you are running traditional QoS, are you sure that your wireless clients are fast enough to hit the download/upload limits? My wireless AC laptop can run faster than my ISP connection though.

Bandwidth limiter should work if you set the limits below the wireless actual rates.

Thanks for checking. No my ISP speeds remain the same at 158 down and 10 up. My wireless clients can easily saturate the line. The problem is the opposite. Here's a simple test.

1) Remove all QOS rules.
2) Set Traditional QoS and SFQ. (not using Bandwidth Limiter)
3) Set the Download Bandwidth at 50Mbps and upload to 9Mbps.
4) Run a speed test from a wired PC. Result: Download capped at about 53Mbps
5) Run a speed test from a wireless laptop. Result: Download at maximum line speed 158Mbps.

EDIT: OK I looked at the ip_conntrack a bit more closely and found a difference. In 4) above when downloading the connmark is 6 and when uploading it is 4. In 5) above the connmarks are 4 in both directions!

 

[kun1he2]

The beta 'B' releases.....well, they are betas In most cases they are safe, but sometimes bad things can happen. We just went through an ugly firmware update problem on the beta related to one of the updates that turned out to be hardware rev level related. I still thank those that tried the betas and helped me to track it down.

Going forward, will we need to ensure that our CFE is up to date?
I'm currently on 17E8 running on AC68U with CFE 1.0.1.6.

 

[ColinTaylor]

Thanks for checking. No my ISP speeds remain the same at 158 down and 10 up. My wireless clients can easily saturate the line. The problem is the opposite. Here's a simple test.

1) Remove all QOS rules.
2) Set Traditional QoS and SFQ. (not using Bandwidth Limiter)
3) Set the Download Bandwidth at 50Mbps and upload to 9Mbps.
4) Run a speed test from a wired PC. Result: Download capped at about 53Mbps
5) Run a speed test from a wireless laptop. Download at maximum line speed 158Mbps.

EDIT: OK I looked at the ip_conntrack a bit more closely and found a difference. In 4) above when downloading the connmark is 6 and when uploading it is 4. In 5) above the connmarks are 4 in both directions!

I've done a bit more testing to confirm the above and eliminate any oddities with the laptop or desktop.

I disabled the wireless on my laptop and plugged it into the router with a cable. I then did the download test again and it was capped at ~53Mbps.

I ran the test again but this time I ran another download on my desktop simultaneously. The individual speeds varied between 20 and 40Mbps but the combined download was again ~53Mbps, as expected.

Then I unplugged the laptop from the router and re-enabled the 5G wireless. I then re-ran the 2 tests. As before the laptop downloaded at maximum line speed (~158Mbps). With the simultaneous test the PC was capped at ~53Mbps but the laptop consumed all of the remaining bandwidth (~105Mbs).

So again, the QOS rules don't appear to have any effect on wireless clients. Is anyone else seeing this problem or is it something misconfigured on my router? TIA.

 

[john9527]

So again, the QOS rules don't appear to have any effect on wireless clients. Is anyone else seeing this problem or is it something misconfigured on my router?

This is turning out to be interesting Can you ssh/telnet to the router and PM me a copy of
/tmp/qos

BTW....that fact you are seeing any limiting on the wired connects is something unique to this fork. With other builds it's not limited at all for traditional qos.

 

[ColinTaylor]

Thanks for looking into this @john9527 . I've sent you a PM as requested.

 

[rtn66uftw]

If it has only two entries, that's the problem, Let's give this a try.....go to the main router page, select the network view and 'Refresh' the client status. Give it about 1 min, then look at the wireless log.

EDIT: A better idea....just ping one of the clients attached to the AP then check the wireless log.

Thanks John! I've tried both but still nothing showed up in IP Address column :/

 

[XSXS]

@john9527,
Did you make any changes to the stock QoS engine on the way it works for the RT-AC66R?

 

[Andi P]

Guys,

please excuse me if this was explained already somewhere. But before bricking my AC68U, I would like to quickly get confirmation:

Status:
I am currently on 17E8 still, and would like to update to latest official 19E3.

Questions:
1- Is it correct I just flash the 19E3 firmware in web interface and I am done?
2- Or do I have to flash a fixpack first, as somehow mentioned in first post?
3- Also, can I go back to 17E8 again in case I face trouble, or do I need to use the firmware restoration tool?
4- Do I have to do a factory reset after going on 19E3 or are the settings taken over correctly from 17E8?

Really sorry, I am usually not such a big noob, but lost track somehow with that revisions. Especially after Asus making the firmware format incompatible lately.

Any answer is highly appreciated.

Many many thanks
Andi