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

[fink.nottle]

Correct.....this fork still uses http validation and as long as the browser window remains open the credentials will be cached.

That reminds me. During the initial setup, you can't copy paste the admin password in the fork. Kinda annoying if you use a password manager. Can this be changed ?

 

[slobodan]

I did:

killall -9 dropbear;dropbear -s -a

But it does not stick, at every Apply the default dropbear options get loaded instead of my hack.

I have put a script in the crontab which does that every hour.

 

[fink.nottle]

@fink.nottle A couple of things.....
- on my fork you need to do the 'limits' entry yourself.....that is for the upload/download on the main page take your actual speed and reduce by 10%
- I forget what ASUS has for the default rules for QoS, but seem to remember they were pretty weak. You may need to define your own rule for HTML/port 80 to see any effect on dslreports bufferbloat. I'll take a look and may change the defaults.

It definitely does work when set up correctly. My test goes from a 'C' to an 'A'

So I flashed the latest stable release today, and did a factory reset. I don't see any difference in bufferbloat with the default QoS settings (fq_codel) in automatic mode. The default rules have Web Surf (0~1536) Highest, HTTPS (0~1536) Highest, File Transfer 80 (1536~) Low, File Transfer 443 (1536~) Low. Do you have any recommendations ?

 

[mproper23]

The latest update didn't make any changes to AICloud that I am aware of.
A couple of questions....
- I see you are relatively new on the forum (Welcome!). Sometimes people confuse this fork with the latest Merlin release. Just to confirm you are using the 374 fork.
- If indeed it's the 374 fork, can you provide a little more detail/example. I don't normally run AICloud in my environment.

I posted in the wrong thread. I'm very sorry.

 

[Santiago C]

I mean: restore dropbear to listening on the public address as it did before build 22E2 and also the firewall rules against hammering on port 22.

I second this, just found out I can no longer access SSH from the wan side

 

[ColinTaylor]

I second this, just found out I can no longer access SSH from the wan side

Oops. Looks like a bug. I don't normally have WAN access enabled but turned it on to test. With and without WAN access dropbear is the same:

# ps w | grep dropbear
  592 admin     1084 S    dropbear -p 192.168.1.1:22 -j -k
12910 admin     1152 S    dropbear -p 192.168.1.1:22 -j -k
12926 admin     1396 S    grep dropbear

On the other hand, it's really secure.

 

[john9527]

I did:

killall -9 dropbear;dropbear -s -a

But it does not stick, at every Apply the default dropbear options get loaded instead of my hack.

It gets restarted at several places in the gui. Also, dropbear is on the watchdog (per another user request).....as soon as you kill it, it will restart fairly quickly.

Oops. Looks like a bug. I don't normally have WAN access enabled but turned it on to test. With and without WAN access dropbear is the same:

Yep...it's a bug. I inadvertently killed the allow access from WAN setting. Maybe a Freudian slip with all the hacking attempts going on
I'll put out a refresh with a fix in a few days (just to give a little time for any other bugs to show up).

 

[ColinTaylor]

I've also noticed something else (that was probably always there?) about the syslog being saved to jffs.

If you reboot the router from the web UI the syslog files are rotated cleanly so that when the router comes back up you haven't lost any of the history.

If you just do a "reboot" from the command line (obviously) the log files aren't rotated so you loose the current information. That's fair enough. But I just noticed that by hitting Apply on the Administration > System page you also loose the current syslog history file.

 

[thelonelycoder]

I was hoping the .ash_history was supported in this version as you wanted to sync with Merlin's BusyBox settings.
Ah, well, I guess this comes with an eventual update of BusyBox to 1.25.1.
22E2 runs very well on my 66U, thanks John.

Edit: I was wrong, you did it!

 

[ColinTaylor]

.ash_history works on my AC68U

 

[thelonelycoder]

.ash_history works on my AC68U

Yup!!! Premature complaint.
You have to enter a command first, of course.
Thanks a lot John!

 

[john9527]

I've also noticed something else (that was probably always there?) about the syslog being saved to jffs.

If you reboot the router from the web UI the syslog files are rotated cleanly so that when the router comes back up you haven't lost any of the history.

If you just do a "reboot" from the command line (obviously) the log files aren't rotated so you loose the current information. That's fair enough. But I just noticed that by hitting Apply on the Administration > System page you also loose the current syslog history file.

Hmm...haven't been able to recreate this one. Just to double check....you didn't disable saving the syslog to jffs, correct?

EDIT: Nevermind.....just did.....strange and not consistent.

 

[john9527]

Yup!!! Premature complaint.
You have to enter a command first, of course.
Thanks a lot John!

Yes, Merlin and I should be in sync now on busybox applets.

 

[fink.nottle]

So I flashed the latest stable release today, and did a factory reset. I don't see any difference in bufferbloat with the default QoS settings (fq_codel) in automatic mode. The default rules have Web Surf (0~1536) Highest, HTTPS (0~1536) Highest, File Transfer 80 (1536~) Low, File Transfer 443 (1536~) Low. Do you have any recommendations ?

@john9527 , just wanted to get your attention.

 

[Nullity]

@john9527 , just wanted to get your attention.

Did you set the upload/download bandwidth to ~95% of your real-world speeds?

 

[fink.nottle]

Did you set the upload/download bandwidth to ~95% of your real-world speeds?

Yes. The download/upload bandwidth caps seem to have an effect, but not on bufferbloat.

 

[jrmwvu04]

Yes. The download/upload bandwidth caps seem to have an effect, but not on bufferbloat.

Here's what I'm currently experimenting with.

My connection is 120/12, and to this point 110/11 has been the sweet spot in terms of best result/least speed reduction. If you haven't tried around 90%, try that.

 

[john9527]

So I flashed the latest stable release today, and did a factory reset. I don't see any difference in bufferbloat with the default QoS settings (fq_codel) in automatic mode. The default rules have Web Surf (0~1536) Highest, HTTPS (0~1536) Highest, File Transfer 80 (1536~) Low, File Transfer 443 (1536~) Low. Do you have any recommendations ?

What are your 'base' upload/download speeds? Also, check in the detail from the bufferbloat test to see if one or the other is having problems. If you have a relatively low ISP bandwidth, sometimes their 'throttling' algorithms can wreak havoc with bufferbloat that can't be managed.

 

[john9527]

My connection is 120/12, and to this point 110/11 has been the sweet spot in terms of best result/least speed reduction. If you haven't tried around 90%, try that.

Interesting that you found that to be the case.....based on some of the assumptions I made for the algorithms, 90% should be the sweet spot.

In general, if you are having problems getting the results you expect, go slightly lower (maybe 85%) instead of higher.

 

[ColinTaylor]

@jrmwvu04 Your File Transfer value should be 2048~, because the 0~2048 on Web Surf is translated as 0 to 2097151 bytes (2048k -1 byte).