What's new

[ 386.12 alpha Build(s) ] Testing available build(s)

  • 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.

octopus

Part of the Furniture
Available builds:

RT-AC5300
RT-AC88U
RT-AC86U
RT-AC68U
GT-AC2900
RT-AC3100

As usual, no support is given on alpha programs.

386.12 (xx-xxx-2023)
- UPDATED: Merged with GPL 386_51997.
- UPDATED: curl to 8.1.2.
- UPDATED: OpenVPN to 2.6.5.
- UPDATED: openssl to 1.1.1u.
- UPDATED: tor to 0.4.7.13.
- CHANGED: FTP server will now only support strong ciphers
in TLS mode.
- FIXED: QOS Classification showing no Upload data on some
WAN configurations.
- FIXED: Radio temperature graphs weren't updating
- FIXED: nvram usage reported on Sysinfo page was inaccurate
as it included JFFS stored values.

 
Last edited:
Seems to have fixed a problem I had activating T-Mobile wifi calling--perhaps the issue noted for 51255.

86U here.
 
Hopefully will get a chance to install this over the next few days.

In the meantime, does anyone know if this GPL includes the fixes for the asd and networkmap memory leaks?
 
Hopefully will get a chance to install this over the next few days.

In the meantime, does anyone know if this GPL includes the fixes for the asd and networkmap memory leaks?
Follow the link in post #2
 
Follow the link in post #2

From that link, the short answer is likely no - focus on security only.

I asked as I had seen something a while ago on the asd memory leak being fixed against the 388 code base and wondered if Asus would have patched back giving the fix in this GPL.

I'll take a look at the behaviour once the alpha is installed.
 
Thankfully I dodged the headaches of Asus' bad asd signature update - this was behaviour that specifically started when I jumped a few versions to 386.10.

RMerlin also confirmed the known asd memory leak in that thread and that a new GPL would be needed with the fix included - hence my question earlier in this thread.

I'm happy to do the legwork myself to check when I have a chance to install the update but thought I'd ask the question.
 
RMerlin also confirmed the known asd memory leak in that thread and that a new GPL would be needed with the fix included - hence my question earlier in this thread.
RMerlin's statement is slightly incorrect in that thread. That's understandable because that specific "asd" issue only started 24 hours earlier and when RMerlin replied nobody had worked out it was the signature update that caused it. I believe RMerlin was referring to a known asd memory leak that at that time was only effecting the RT-AX68U.
 
I believe RMerlin was referring to a known asd memory leak that at that time was only effecting the RT-AX68U.
There was a documented asd memory leak that Asus told me about which predates the signature issues. If I recall, it mostly affected AiMesh setups however. I would assume this has been fixed by now considering how long ago they told me about the issue.
 
I would like to start by saying a big thank you RMerlin for your work!

I've updated the firmware on an Asus RT-AC68U H/W ver. A1 router from 386.11_0 to 386.12_alpha1-g64a31d1c9e, keeping the settings.
I have a problem with ddns watchdog restarting the ddns update every 30 seconds, so after some troubleshooting, which got me nowhere, I've decided to do a hard reset, by holding wps button while powering on until power led starts blinking, to check if the issue is present after a minimal setup, after saving the config and jffs partition.

The problem now is that the WebUI is not accessible after the reset. I've waited at most 30 minutes to give the httpd daemon time to start if this firmware had something to do in that time.
I've had to use the firmware restoration tool, by holding reset button while powering on until power led starts blinking. I've loaded the most recent official firmware which only contained the image for the original AC68U and not the v4 one, which is AsusWRT 3.0.0.4_386_41634.

I've checked and dhcp was working properly, at least if offered ips for address, gateway, dns, also tried with static ip on pc's ethernet connection.
I've tried multiple web browsers, mostly in private mode, with extensions allowing access or disabled completely.
I've tried to upload the firmware again 3 times, using an ethernet cable connected directly from the pc to the router.
I've also checked the included sha256 checksum against the .trx file and it checks out.
One time I've also tried a restore to factory defaults from within the firmware by also checking "Initialize all settings[...]" with the same inaccessible WebUI after the reboot.

Does anybody have some insight or is willing to test a reset of their own and post results?
 
I would like to start by saying a big thank you RMerlin for your work!

I've updated the firmware on an Asus RT-AC68U H/W ver. A1 router from 386.11_0 to 386.12_alpha1-g64a31d1c9e, keeping the settings.
I have a problem with ddns watchdog restarting the ddns update every 30 seconds, so after some troubleshooting, which got me nowhere, I've decided to do a hard reset, by holding wps button while powering on until power led starts blinking, to check if the issue is present after a minimal setup, after saving the config and jffs partition.

The problem now is that the WebUI is not accessible after the reset. I've waited at most 30 minutes to give the httpd daemon time to start if this firmware had something to do in that time.
I've had to use the firmware restoration tool, by holding reset button while powering on until power led starts blinking. I've loaded the most recent official firmware which only contained the image for the original AC68U and not the v4 one, which is AsusWRT 3.0.0.4_386_41634.

I've checked and dhcp was working properly, at least if offered ips for address, gateway, dns, also tried with static ip on pc's ethernet connection.
I've tried multiple web browsers, mostly in private mode, with extensions allowing access or disabled completely.
I've tried to upload the firmware again 3 times, using an ethernet cable connected directly from the pc to the router.
I've also checked the included sha256 checksum against the .trx file and it checks out.
One time I've also tried a restore to factory defaults from within the firmware by also checking "Initialize all settings[...]" with the same inaccessible WebUI after the reboot.

Does anybody have some insight or is willing to test a reset of their own and post results?
Which ip address are you using to access the router?
 
The gateway ip address set by dhcp, 192.168.1.1.
Try 192.168.1.50 or 192.168.0.50

Edit: unless you are getting the gateway from your client, then never mind.
 
The problem now is that the WebUI is not accessible after the reset. I've waited at most 30 minutes to give the httpd daemon time to start if this firmware had something to do in that time.
I've had to use the firmware restoration tool, by holding reset button while powering on until power led starts blinking.
I can confirm this issue on RT-AC68U
 
How are you trying to reach the GUI? What IP are you using?

See post 16.
 
I'm not aware of any confirmed memory leaks on these models for those processes (but I may have just missed them).
I can confirm a memory leak from networkmap of about 1.5 MB/day affecting my RT-AC86U, with firmware versions 386.9 and 386.10. I did not install 386.11, but I'm fairly sure it is still there. My original message is here.

I hope this helps.
 
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