What's new

[Beta] Asuswrt-Merlin 384.12 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
It looks different from all the others in the mainline branch, without the www, meaning the files are probably misplaced.
https://github.com/RMerl/asuswrt-merlin.ng/tree/mainline/release/src/router/www/sysdep
I mainly wanted to know because if it wasn't a issue in the code, I would just simply do a factory reset. If any one can confirm that has a rt ac 5300 that their netools is showing as it should in the gui I would appreciate it because then I would do a factory reset.
 
I mainly wanted to know because if it wasn't a issue in the code, I would just simply do a factory reset. If any one can confirm that has a rt ac 5300 that their netools is showing as it should in the gui I would appreciate it because then I would do a factory reset.

Well I'd help if I have an AC 5300 but why not do a backup, factory reset and test, if still same restore the backup without any loss.
 
I mainly wanted to know because if it wasn't a issue in the code, I would just simply do a factory reset. If any one can confirm that has a rt ac 5300 that their netools is showing as it should in the gui I would appreciate it because then I would do a factory reset.
Compare the /www/Main_Analysis_Content.asp files on both routers. They should be the same. A reset won’t fix what’s in rom. :)
 
I have remote router with P2P OpenVPN connection, which I update only remotelly. Is there way to:
- disable firewall to OpenVPN clients before update
- disable firewall to OpenVPN clients after update using some executable command by script
?

LOL, that didn't take long. At the time this security measure was being discussed, we were debating whether the default should be block or allow. There always seem to be an outlier.

Frankly, updating a remote router's firmware seems pretty risky, just in general. Unless you have a *very* desperate need for a new feature or bug fix, this is something better left for when you are present at the remote site. And a *beta* ta-boot.

Assuming you accept the risk and intend to maintain the existing nvram settings (something I don't normally recommend either), I suppose you could add some firewall rules to the firewall-start script that precede the blocking.

Code:
SCRIPTS_DIR="/jffs/scripts"
FIREWALL_SCRIPT="$SCRIPTS_DIR/firewall-start"
mkdir -p $SCRIPTS_DIR
cat << "EOF" > $FIREWALL_SCRIPT
#!/bin/sh
iptables -I INPUT -i tun1+ -j ACCEPT
iptables -I FORWARD -i tun1+ -j ACCEPT
EOF
chmod +x $FIREWALL_SCRIPT

This assumes, of course, you have jffs and custom scripts enabled on the Administration->System page.

Once you have access to the OpenVPN client again, you can change the "Inbound Firewall" option to "Allow" and get rid of the firewall script. Or perhaps leave it there for future firmware updates.
 
Last edited:
Well I'd help if I have an AC 5300 but why not do a backup, factory reset and test, if still same restore the backup without any loss.
I have back ups. I just have people I cannot afford downtime atm anything that saves me time is worth the time imo.
 
Compare the /www/Main_Analysis_Content.asp files on both routers. They should be the same. A reset won’t fix what’s in rom. :)
It is there I just think the symbolic link wasn't done properly in a way the code understands.
 
I have back ups. I just have people I cannot afford downtime atm anything that saves me time is worth the time imo.

I'd agree to that if you're on a stable firmware, but you're running a beta version in your mission critical environment, that's a bad practice on its own but it's a free world and everyone is entitled to do whatever they want!! [emoji6]
 
Screenshot_20190611-204501522.jpg

The symbolic link is appended on the router itself and not a sub /www. That is probably the issue.
 
I'd agree to that if you're on a stable firmware, but you're running a beta version in your mission critical environment, that's a bad practice on its own but it's a free world and everyone is entitled to do whatever they want!! [emoji6]
I hear you there it isnt unstable it is just featureless lol that is why I am not really calling it critical to factory reset.
 
I hear you there it isnt unstable it is just featureless lol that is why I am not really calling it critical to factory reset.

That part I understand and honestly I don't believe a reset will fix it either, the issue seems to be in the code compilation itself.
 
That part I understand and honestly I don't believe a reset will fix it either, the issue seems to be in the code compilation itself.
Yea it all made sense when you posted the link and I had a closer look. At first, I only looked at the outside commit. That is what led me to post the question, but after seeing the link I can honestly say I completely agree with you. Btw even if I delt with a whining army of kids I dont think I will ever stop beta or alpha testing with you guys. :)
 
so I updates, my netools is not active on the RT-AC5300, well it shows it is active under HTOP, but the gui is not linking to it. where as with my 68u and my 3100 it is working both ways. is there an issue with it in the build for the RT-AC5300 can any one confirm it is working for them?

working fine here
 
Interesting you seem to be very resistant in considering something that might work. But so be it.

Because it's a hack and a workaround at best, not a fix to the actual problem. These are what is causing modern software to be so crappy in general, as developers are getting lazy, being more interested in implementing quick workarounds that come back to bite them in the butt later rather than track down and address the root problem.

These types of workarounds have a tendency to introduce new problems. Case in point: a few years ago, Asus wanted networkmap to do a better job in identifying printers. Their bright idea was to submit a fake print job on the spooler. End result: everyone's printers kept coming out of sleep mode multiple times per day just because networkmap was trying to confirm they were actually printers. I removed that piece of code, and I believe Asus did as well later on.

So, I try to avoid these as much as possible. Disrupting proper behaviour of ARP caching on a network is NOT a valid solution to this problem.
 
Interesting you seem to be very resistant in considering something that might work. But so be it.

Apart from what @RMerlin said above, your proposed fix is just like taking Steroids, you feel like your body is getting better but in reality all it's doing is making it work harder and in the end breaking more things.
 
Asus issue, they have since corrected it, but haven't released any firmware yet with the fix.

Sent from my P027 using Tapatalk
Is that the only affeted model?
 
Is that the only affeted model?

It affects all HND models: RT-AC86U, RT-AX88U, GT-AC5300, GT-AX11000, etc... It's an issue with the nvram-to-jffs code on these models.
 
AC3200 latest beta :

This is being logged every few minutes :


Code:
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: Adjusted channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER


Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: Adjusted channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: acs_set_chspec: 0x1001 (1) for reason APCS_CSTIMER


Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: Adjusted channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_CSTIMER
 
Because it's a hack and a workaround at best, not a fix to the actual problem. These are what is causing modern software to be so crappy in general, as developers are getting lazy, being more interested in implementing quick workarounds that come back to bite them in the butt later rather than track down and address the root problem.

These types of workarounds have a tendency to introduce new problems. Case in point: a few years ago, Asus wanted networkmap to do a better job in identifying printers. Their bright idea was to submit a fake print job on the spooler. End result: everyone's printers kept coming out of sleep mode multiple times per day just because networkmap was trying to confirm they were actually printers. I removed that piece of code, and I believe Asus did as well later on.

So, I try to avoid these as much as possible. Disrupting proper behaviour of ARP caching on a network is NOT a valid solution to this problem.

Ah I remember my wireless printer use to try to do "mock" print jobs. Now I can hardly ever get it to stay connected online.
 
AC3200 latest beta :

This is being logged every few minutes :


Code:
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: Adjusted channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER


Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: Adjusted channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: acs_set_chspec: 0x1001 (1) for reason APCS_CSTIMER


Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: Adjusted channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_CSTIMER
I noticed this as well, acsd is also pumping alot harder, and if you arnt carefull on reboots it is now causing a racing condition within inside the cpu.
 
AC3200 latest beta :

This is being logged every few minutes :


Code:
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: Adjusted channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: selected channel spec: 0x1002 (2)
Jun 12 03:22:49 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER


Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: Adjusted channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: selected channel spec: 0x1001 (1)
Jun 12 03:07:47 acsd: acs_set_chspec: 0x1001 (1) for reason APCS_CSTIMER


Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: Adjusted channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: selected channel spec: 0x1006 (6)
Jun 12 03:37:51 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_CSTIMER
Screenshot_20190612-015501723.jpg

Acsd on crack.
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top