Release Asuswrt-Merlin 386.1 is now available

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.
Status
Not open for further replies.

AntonK

Very Senior Member
Smooth upgrade from 386.1 to 386.1_2 on both routers.
From RT-AC88U web UI, I first upgraded the node (RT-AC86U_RT-AC2900) and than the RT-AC88U itself. Left both usb-drives plugged in.

My RT-AC88U doesn't seem to have the 160 MHz for wifi available.

View attachment 30717
Tried different servers, but the speed seems to be 15-20 % to low compared to a web speedtest. But it is a nice feature.

My RT-AC88U doesn't have 160 MHz available either. I assume it's a regional, or hardware revision thing.
 
Last edited:

ray

Regular Contributor
Hi all. The earliest ones I've seen are 384.19 > 386.1 at the beginning of this thread, and subsequently 386.1 >> 386.1_2 or 384.19 > 386.1_2.

I'm on 384.17. Do I need to flash every version? Should I do a factory reset before dirty flashing? I used to be much more trigger happy flashing the latest and greatest but have become very very risk averse!
 

Kees17760

Regular Contributor
Discovered a minor thing on my RT-AC2900 running 386.1_2 (started from scratch)

- After performing a health check on an 8 GB USB 3.0 stick (which takes minutes to complete), my VPN connection through PPTP is lost and does not recover. I have to manually recycle it (deactivate-activate) to gain access to the internet again. The stick holds a 2 GB swap file.

Tried another USB stick to the same result.
 
Last edited:

JIPG

Regular Contributor
I have updated to FW 386.1_2 from 386.1, and although I have not reseted everything, I have done a "format jffs after reboot". After several reboots, the information on the jffs is still there, nothing has been erased. Am I missing something or this option can be only used when you do a full "reset"?.

In any case, everything is working fine. I did the format jffs just to see if I can recover the warning pages from Ai Protection (now, they are empty, without a description of the threat).
 

cristobal07

Occasional Visitor
my apologies, Merlin.

just realized that my DDNS update issue was possibly caused by isp.

tried several times and method to troubleshoot yesterday, no luck.
suddenly the issue is gone today, DDNS updated without problem.

thank you.

thanks for fixing the ipv6 address bug as well. :)

p/s: confirmed, problems from my isp.
routing issue, site inaccessible, high ping/latency, slows down etc.
ongoing and happened intermittently.


upgraded from 386.2 alpha to 386.1_2 > factory reset,
having DDNS update issue with tunnelbroker.net - Request error! Please try again.
log showing 500 internal server error.

Code:
start_ddns: update WWW.TUNNELBROKER.NET [email protected], wan_unit 0
inadyn[1630]: In-a-dyn version 2.8.1 -- Dynamic DNS update client.
inadyn[1630]: Update forced for alias xxxxxx, new IP# xxx.xxx.xxx.xxx
inadyn[1630]: Temporary error in DDNS server response:
inadyn[1630]: [500 Internal Server Error]
inadyn[1630]: Will retry again in 600 sec ...

tried to manual update the endpoint ip in tunnelbroker.net website, successful updated and ipv6 is working.
but under router DDNS tab still showing "Request error! Please try again.",
internet status also showing exclamation mark with "registration is successful" message.

another issue, always stuck at "Applying Settings..." in DDNS tab
(after insert info and click on apply button, no problem.
click apply button again, got stuck).


thanks RMerlin.

upgraded RT-AC88U to beta 4 - factory reset.

found out that IPv6 - tunnel 6in4 no longer accept
LAN IPv6 Prefix address from tunnel broker that ends with ::
randomly added one digit after ::, from xxx:xxx:xxxx:: to xxx:xxx:xxxx::0 did the trick.

Thanks Merlin.
 
Last edited:

gattaca

Senior Member
would “bad blocks” explain why flashing 386.1 to 386.1_2 doesn’t work, but 386.1 to 384.19 to 386.1_2 does?
Hi! Unknown. I finally found the post. It is in fixes posted for 386.1_2. -> http://www.snbforums.com/threads/asuswrt-merlin-386-1-is-now-available.69783/

- FIXED: Erasing the JFFS partition would often require a second reboot since the operation failed when encountering a bad block. These are now properly skipped.

In general, most (but not all) flash upgrades perform validations to prevent the firmware flash from bricking target - router, motherboards, etc... As a software engineer, I'd say anything is possible with code checks and verifications. This was just a theory based on above and what I saw with bad-blocks happening on my AC86 units in 384.19. Crazy, I know. Your path is certainly an outlier too. Now that you are 386.1_2, it will be interesting to know how the next step/version flash upgraded goes. FWIW, I've not tried to step AC86 from 384.19 to 386.***. I'm considering upgrading the main router to the AX86U and then waterfalling my AC86 to WAPs. Stay safe, stay alive. Peace.
 
Last edited:

predatorz

Occasional Visitor
Dirty upgrade from 386.1 to 386.1_2 on AC-88U smoothly.
Thanks for the firmware!!
 

Yota

Senior Member
It seems that the Scheduled check for new firmware availability is broken.

I did a clean update after updating from 384.19 to 386.1 (restore factory and set manually), and then I turned the Scheduled check for new firmware availability. Now I have a reminder to update to 386.1_2, so I think even if I turn off automatic check for updates, it will not work.


photo.png




====================================


It seems that the local OUI database is not working well. I updated from 386.1 to 386.1_2 on an AC86U without Internet (Dirty upgrade). Online devices can display the manufacturer, but other devices are loading.
Use https to access webui, on the static DHCP page:

photo.png
 
Last edited:

Wanabo

Occasional Visitor
Elsewhere in this thread it was mentioned that there are problems with usb 3.0 mode. I've noticed that also with 386.1 and this problem remains in 386.1_2. Before 386 I never had a problem with usb 3.0 mode
Allthough the usb 3.0 drive seems to be working, it has entware and skynet on it which are still working, the web gui reports it as completely full. But only 10% is in use. Also it can not be accessed as an smb drive. After a health scan the usb drive is marked as faulty. Rebooting or changing mode usb 3.0 to usb 2.0 fixes this issue (temporarily?) as previously mentioned somewhere in this thread.

The usb 3.0 drive was formatted with the amtm tool as ext4. Could this be the problem as this is not an option with the formatting options in the web gui?
 

Igor

Regular Contributor
RT-AC68U, 386.1_2
NVRAM usage: 64378 / 65536 bytes
Is that how it should be?

JFFS: 4.57 / 62.75 MB
Uptime: 40 min
 
D

Deleted member 51572

Guest
updated RT-AC86U from v384.19 to 386.1_2

some noticeable improvements that i like, but constant log spam as usual + A LOT of these messages:

nf_conntrack: expectation table full
(lots of these, every minute or so, non-stop)

net_ratelimit: 41 callbacks suppressed
(seems to occur after rebooting via web UI)

acsd adjusted channel spec
(i don't need to know everytime the channel changes!)

wlceventd_proc_event
(just insane)

... on and on, ad nauseam

i use a remote log server (Syslog Watcher on port 514) to receive log messages from several devices on our network, including the AC86U, so this ridiculous level of log spam is unacceptable. yeah i can create filters to hide some of the router spam (which i've done), but i shouldn't have to do this. debug logging should be disabled by default on the 86U, period.

i'd hoped to finally put my RT-AC86U into service (in router mode instead of an AP) after waiting so long for a solid-stable, reliable firmware revision, but it wasn't to be. i'm disappointed and fed up with Asus' flakey firmware, tbh. i don't know what all the 'nf_conntrack: expectation table full' messages mean, but there's a steady stream of them.

and before anyone asks, YES, I did hard-reset the router to factory defaults (several times) after updating it from Asuswrt-Merlin v384.19 to v386.1_2 and reconfiguring all settings by hand (no scripts or third-party software installed). i had been using the 86U as an access point with Merlin v384 before updating it to v386, but i really should've known better with this router. just no good, no joke.

so we're back to the 1900P running an outdated version Merlin (380.70), because i have no confidence in the AC86U at this point, if ever. at least our 1900P is reliable and doesn't spam me to death with utterly useless debugging info. how difficult can it be for Asus to simply turn OFF debug logging??
 

ATLga

Senior Member
updated RT-AC86U from v384.19 to 386.1_2

some noticeable improvements that i like, but constant log spam as usual + A LOT of these messages:

nf_conntrack: expectation table full
(lots of these, every minute or so, non-stop)

net_ratelimit: 41 callbacks suppressed
(seems to occur after rebooting via web UI)

acsd adjusted channel spec
(i don't need to know everytime the channel changes!)

wlceventd_proc_event
(just insane)

... on and on, ad nauseam

i use a remote log server (Syslog Watcher on port 514) to receive log messages from several devices on our network, including the AC86U, so this ridiculous level of log spam is unacceptable. yeah i can create filters to hide some of the router spam (which i've done), but i shouldn't have to do this. debug logging should be disabled by default on the 86U, period.

i'd hoped to finally put my RT-AC86U into service (in router mode instead of an AP) after waiting so long for a solid-stable, reliable firmware revision, but it wasn't to be. i'm disappointed and fed up with Asus' flakey firmware, tbh. i don't know what all the 'nf_conntrack: expectation table full' messages mean, but there's a steady stream of them.

and before anyone asks, YES, I did hard-reset the router to factory defaults (several times) after updating it from Asuswrt-Merlin v384.19 to v386.1_2 and reconfiguring all settings by hand (no scripts or third-party software installed). i had been using the 86U as an access point with Merlin v384 before updating it to v386, but i really should've known better with this router. just no good, no joke.

so we're back to the 1900P running an outdated version Merlin (380.70), because i have no confidence in the AC86U at this point, if ever. at least our 1900P is reliable and doesn't spam me to death with utterly useless debugging info. how difficult can it be for Asus to simply turn OFF debug logging??
You do know that there IS a log setting in the Merlin version for you to change what you see in the log. Click the dropdown where apparently it now says Debug and CHANGE it to Notice and you wont see hardly anything at all in the log...
 
D

Deleted member 51572

Guest
You do know that there IS a log setting in the Merlin version for you to change what you see in the log. Click the dropdown where apparently it now says Debug and CHANGE it to Notice and you wont see hardly anything at all in the log...
doesn't work
 
D

Deleted member 51572

Guest
Not a known issue. If that didn't work for you, you've got other issues.
omg, just search this forum. even Merlin mentioned something about Asus leaving debug logging enabled for whatever reason, i don't remember exactly. in any case, the router log settings have no effect on the steady stream of debug messages.
 

ATLga

Senior Member
omg, just search this forum. even Merlin mentioned something about Asus leaving debug logging enabled for whatever reason, i don't remember exactly. in any case, the router log settings have no effect on the steady stream of debug messages.
Yes they did leave debugging on which is why YOU CAN TURN IT OFF either by SSH or the drop down in Merlin fw. If that setting isn't working for you, then something else is wrong. The setting works along with the ability to SSH and disable it.

We may be saying the same thing - I'm saying the messages may still be there, but the setting Hides them in the GUI. Your remote log server may still be seeing them though and that sounds like the issue
 
Last edited:
D

Deleted member 51572

Guest
Yes they did leave debugging on which is why YOU CAN TURN IT OFF either by SSH or the drop down in Merlin fw. If that setting isn't working for you, then something else is wrong. The setting works along with the ability to SSH and disable it.
you're wrong, and we're done. ignored.
 
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