What's new

[Beta 384/NG] Asuswrt-merlin 384.4 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.
If I increase it, the new length will be rejected by the RT-AC86U due to its hardcoded values within the wlc module.
In that case, shouldn't the limit in Advanced_System_Content.asp also be reverted to 2999, as it will be limited by defaults.c anyway? Or is that not how it works?
 
Been running the 384.4 beta1 for about a week now, and everything seem's fine however I have noticed this one odd issue that keep's on popping up randomly and unexpectedly. So far I have been unable to reproduce it, so I am not sure if it's something in my set-up causing it or if something within the new code base has changed. But, it has happened enough that it has caught my attention.

The problem occurs out of nowhere only over WIFI, if for some reason I want to log into my router's webUI page through my smartphone or PC over WIFI, it hang's forever loading. However, using a wired connection and everything is fine, and load immediately. The log's don't show anything weird and the CPU core's are typically 1-3% spiking to maybe 60% and 6% on core 1 and 2 respectively . To fix the issue, require's me rebooting the device or trying again at a later time. My internet during all of this is fine and uninterrupted, I am only prevented from logging in via the webUI over WIFI during these random lockouts.

Even, after logging in with no issue's over the wired connection, the WIFI device's will refuse to even load the page until a reboot or some later time.

I've played around with no VPN connections, Adaptive QoS off, and even smart connect off, and this issue just happen's randomly. I've run out of idea's on trying to pinpoint the issue, so looking to more knowledgeable user's who can shed some light on discovering and potentially fixing the issue.

I would like to chalk it up to a performance issue, and not waste any more time on troubleshooting it, but it's too annoying of an issue to ignore lol
 
@RMerlin - I found the root cause why I couldn't get the open vpn server working (first tried with 384.3 with no luck):
With traditional QoS enabled clients stall during the connection setup process, it's not possible to connect to the routers vpn server from the internet. When I disable traditional QoS (either completely or switch mode to adaptive QoS) vpn is working fine. So there seems to be a problem with traditional QoS implementation (maybe thats also the cause for the missing statistics) - if I can help you fixing it don't hesitate to contact me since I've setup a dedicated test router (RT-AC68U Rev. E1) now to play with.

Regards,
Chris
 
Thanks a lot for your hardwork @RMerlin ! Will try this version on mine this weekend.

Looking at the list of commits, I was wondering if there is any difference between the libwdpi for AC-3100 on your branch (Feb 17) and the one from ASUS released on Feb 21 ?

Code:
Version 3.0.0.4.384.20379

2018/02/21

45.68 MBytes

ASUS RT-AC3100 Firmware version 3.0.0.4.384.20379

Security fixed
- Fixed KRACK vulnerabilities
- Fixed AiCloud 2.0 Reflected XSS Vulnerability. Thanks to Guy Arazi and Niv Levi contribution.
Thanks to Guy Arazi for following vulnerabilities.
- AiCloud 2.0 Stored XSS Share link manager.
- AiCloud 2.0 Reflected XSS - "share a link"
- Download Master HTTP service DoS vulnerability.
- Download Master Reflected XSS Main login.
Bug fixed
- Fixed Let’s encrypt authentication issue.
- Fixed IPSec connection problem when PSK/Account/Password over 32 characters.
- Fixed typo in AiProtection alert mail.
 
In that case, shouldn't the limit in Advanced_System_Content.asp also be reverted to 2999, as it will be limited by defaults.c anyway? Or is that not how it works?

I'd have to do some tests, some of the variables are handled differently. I never specifically tested certificates.

In any case, another internal limitation is the size of the buffers used to process web requests. The current size was calculated based on a worst-case scenario at the time, increasing key/cert sizes would require validating every single buffer throughout the chain to ensure that everything was made large enough. I did it at the time, not sure I feel like doing it again, especially with some portions now being outside of my control.
 
Been running the 384.4 beta1 for about a week now, and everything seem's fine however I have noticed this one odd issue that keep's on popping up randomly and unexpectedly. So far I have been unable to reproduce it, so I am not sure if it's something in my set-up causing it or if something within the new code base has changed. But, it has happened enough that it has caught my attention.

Test using http. https support is quirky, and will cause frequent stalls.
 
@RMerlin - I found the root cause why I couldn't get the open vpn server working (first tried with 384.3 with no luck):
With traditional QoS enabled clients stall during the connection setup process, it's not possible to connect to the routers vpn server from the internet. When I disable traditional QoS (either completely or switch mode to adaptive QoS) vpn is working fine. So there seems to be a problem with traditional QoS implementation (maybe thats also the cause for the missing statistics) - if I can help you fixing it don't hesitate to contact me since I've setup a dedicated test router (RT-AC68U Rev. E1) now to play with.

Regards,
Chris

Traditional QoS has been known to be broken for years, and it's something Asus isn't interested in fixing since they consider everyone should be using Adaptive QoS instead.
 
This thing causes CPU spikes periodically, anyone any idea what is this?

https://prnt.sc/ily374

Something seems to be preventing the router from generating the SSL certificate it uses for that service, or something is causing that service to crash and restart.

How is your webui's SSL configured? Let's Encrypt, persistent cert that you uploaded, etc...?
 
How is your webui's SSL configured? Let's Encrypt, persistent cert that you uploaded, etc...?

Let's Encrypt. Maybe I can try to switch it to None and switch back to Let's Encrypt again?
 
Looking at the list of commits, I was wondering if there is any difference between the libwdpi for AC-3100 on your branch (Feb 17) and the one from ASUS released on Feb 21 ?

I don't know. I would expect it to be the same, since I got it from the 384_20379 GPL Asus sent me.
 
Let's Encrypt. Maybe I can try to switch it to None and switch back to Let's Encrypt again?

Try it for a while with Let's Encrypt disabled to see if it's interfering with the certificate management for that service.
 
Try it for a while with Let's Encrypt disabled to see if it's interfering with the certificate management for that service.

Disabled Let's Encrypt but still same process eats CPU in about every 10 seconds. Any other ideas?
 
Excuse me for being very dense, but, at what stage should the factory reset be performed? Before installing 3.8.4 or after installing? Is this the same as the Factory Default setting under Administration - Restore/Save/Upload Setting in the WEB GUI?
Do you suggest recreating all the settings from scratch?
I am currently using 380.69.2 on a AC68U, with no problems running 2 Open VPN tunnels with Policy Routing set for certain devices.
 
Disabled Let's Encrypt but still same process eats CPU in about every 10 seconds. Any other ideas?

Try rebooting after disabling LE.
 
Test using http. https support is quirky, and will cause frequent stalls.
Awesome, will test it out in a few hour's

Sent from my LG-H830 using Tapatalk
 
Traditional QoS has been known to be broken for years, and it's something Asus isn't interested in fixing since they consider everyone should be using Adaptive QoS instead.
I know (broken is relative in reality), but you made it working in 380 and it's there in 384 but there seems to be some small changes in the background (for example chain QOSO0 and QOSO1 in 380 dual wan, now only one chain QOSO in 384 dual wan) which maybe could be fixed without great efforts, that's why I want to help. :) Adaptive isn't working for my scenario, I need traditional and vpn both working together. Btw, they work fine each alone, so maybe just a litte screw to turn?

Edit: Think I found the cause for this problem: I have a last rule "any protocol -> lowest priority" and if this is present incoming vpn stalls. If I remove it or change from lowest to low vpn works. So maybe a problem with classifying traffic into lowest priority? I'll dig further as long as my knowledge is enough to dig.

Edit2: It's definitely the classification, whenever this is present vpn stalls:

iptables -t mangle -S QOSO
...
-A QOSO -j CONNMARK --set-xmark 0x5/0x7
-A QOSO -j RETURN

As soon as I change it to 0x4/0x7 (equal to low instead of lowest in gui) everything is fine. I classified all other traffic to lowest to check if there is something wrong with lowest priority but http/ftp/... still works fine classified as lowest, only vpn won't work. Now that I know it I can edit my rules and use traditional qos and vpn together. But if someone has an idea how to fix it within the binaries it would be fine. :)

Regards,
Chris

Edit 3: Gave up now, will try to get rid of traditional QoS and use adaptive instead.
 
Last edited:
Excuse me for being very dense, but, at what stage should the factory reset be performed? Before installing 3.8.4 or after installing? Is this the same as the Factory Default setting under Administration - Restore/Save/Upload Setting in the WEB GUI?
Do you suggest recreating all the settings from scratch?
I am currently using 380.69.2 on a AC68U, with no problems running 2 Open VPN tunnels with Policy Routing set for certain devices.

Install 384 and then factory default (with restore) under Factory Default setting under Administration - Restore/Save/Upload Setting in the WEB GUI
 
Try rebooting after disabling LE.

I've tried reboot, didn't help. I've deleted everything under /etc/cfg_mnt. Router created new ones. I've also deleted everything under /jffs/.le but none of them helped. Just before this "watchdog" uses high CPU and this comes with using more CPU.

If you don't have any idea it's OK I can live with it :)
 
I've tried reboot, didn't help. I've deleted everything under /etc/cfg_mnt. Router created new ones. I've also deleted everything under /jffs/.le but none of them helped. Just before this "watchdog" uses high CPU and this comes with using more CPU.

If you don't have any idea it's OK I can live with it :)

I see in your signature that you are using various scripts, can you try disabling these to ensure they're not causing any conflict?

Also check with "ps w" - does the cfg_sync process ID change (which would indicate the process is crashing and restarting itself)?

EDIT: something more seems to be going on, I just noticed that the service isn't even running on my own RT-AC88U.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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