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.

det721

Part of the Furniture
Just flashed 386.1_2 AX58U. No problems flashing did a factory reset and reconfigured all working as expected so far. :)
 

NivekTheSizable

Occasional Visitor
386.1_2 breaks OpenVPN completely for me on the RT-AX88U. Downgrading it to 386.1 restored it with the same config. I didn't see anything in the changelog that would be an obvious culprit.

To attempt to troubleshoot, I tried to enable OVPN server 2, which I don't use, in its default configuration to see if that worked, but it also failed to start with the same errors in the logs.

Here are the startup errors in the log for 386.1_2 (same erros for ovpn-server1):
Code:
Feb 13 10:23:27 ovpn-server2[12157]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Feb 13 10:23:27 ovpn-server2[12157]: Options error: --dh fails with 'dh.pem': No such file or directory (errno=2)
Feb 13 10:23:27 ovpn-server2[12157]: Options error: Please correct these errors.
Feb 13 10:23:27 ovpn-server2[12157]: Use --help for more information.
Feb 13 10:23:27 openvpn: Starting OpenVPN server 2 failed!

Here is a successful startup of OpenVPN on 386.1 after downgrade:
Code:
Feb 13 10:33:35 ovpn-server1[2432]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Feb 13 10:33:35 ovpn-server1[2432]: OpenVPN 2.5.0 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 30 2021
Feb 13 10:33:35 ovpn-server1[2432]: library versions: OpenSSL 1.1.1i  8 Dec 2020, LZO 2.08
Feb 13 10:33:36 ovpn-server1[2444]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Feb 13 10:33:36 ovpn-server1[2444]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 13 10:33:36 ovpn-server1[2444]: Diffie-Hellman initialized with 2048 bit key
Feb 13 10:33:36 ovpn-server1[2444]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb 13 10:33:36 ovpn-server1[2444]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb 13 10:33:36 ovpn-server1[2444]: TUN/TAP device tun21 opened
Feb 13 10:33:36 ovpn-server1[2444]: TUN/TAP TX queue length set to 1000
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip link set dev tun21 up mtu 1500
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip link set dev tun21 up
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24
Feb 13 10:33:36 ovpn-server1[2444]: ovpn-up 1 server tun21 1500 1621 10.8.0.1 255.255.255.0 init
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Feb 13 10:33:36 ovpn-server1[2444]: ERROR: Linux route add command failed: external program exited with error status: 2
Feb 13 10:33:36 ovpn-server1[2444]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Feb 13 10:33:36 ovpn-server1[2444]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Feb 13 10:33:36 ovpn-server1[2444]: UDPv4 link local (bound): [AF_INET][undef]:61194
Feb 13 10:33:36 ovpn-server1[2444]: UDPv4 link remote: [AF_UNSPEC]
Feb 13 10:33:36 ovpn-server1[2444]: MULTI: multi_init called, r=256 v=256
Feb 13 10:33:36 ovpn-server1[2444]: IFCONFIG POOL IPv4: base=10.8.0.2 size=252
Feb 13 10:33:36 ovpn-server1[2444]: Initialization Sequence Completed

Is anyone else having this issue? Any suggestions to fix it other than wait for the next release?
 

Wallace_n_Gromit

Senior Member
Run this and then upgrade to 386.1 and reset after the upgrade. Do it before @L&LD wakes up.
I want to dispel this commonly held notion that @L&LD EVER sleeps in the first place. :D

BTW: updated to 386.1_2. Smooth sailing so far.
 
Last edited:

bluzfanmr1

Senior Member
You are manually opening required ports, UPNP does this or tries to automatically for you, but UPNP is not something you want to leave on. Also when done playing you should turn open nat off again, so as not to advertise open ports when not gaming.
I believe this is outdated advice as stated previously here. The firmware version of UPNP is secure and it is unnecessary to turn it on and off. Of course, it's up to each individual how they want to deal with it.
 

Morac

Senior Member
- CHANGED: Use local OUI database instead of remote one hosted
on Asus's server (allows queries to work even when
accessing webui over https)

Is the local OUI database up to date? I ask because there‘a no data for my iPhone or iPad. I believe previously there was.

edit:

i checked https://github.com/RMerl/asuswrt-me...826ac154/release/src/router/www/js/ouiDB.json and the MACs are just missing. That’s why B2:8B:30 and 1E:CA:E0 don’t show as Apple.

From what I can tell elsewhere, it looks like OUI hasn’t updated to include those, so I guess this never worked.

Never mind.
 
Last edited:

ugandy

Very Senior Member
Smooth upgrade to 386.1_2
 

kibosh

Regular Contributor
I just updated my AX86U to 386.1_2

My Xbox Series X NAT type is now Moderate due to UDNP. I hard reseted my Series X and AX86U and still had the same issue. Anyone else have the same router and Series X to verify? It’s on a wired connection and not wireless.

I had to set the DMZ to my Series X to get it to NAT Open again in the meantime.

I have both the AX86u and a Xbox Series X. I just upgraded to 386.1_2 from 386.1. When I fired up the xbox, it was not getting a ipv6 address but the NAT was open. I rebooted it and it now has both ipv4 and ipv6 and the NAT is open. I dont enable QOS and I did not change the Enable GeForce NOW QoS UPnP control (it is defaulted to Yes).
 

Rhialto

Regular Contributor
Just went from 384.19 to 386.1_2 and briefly saw the GUI showing new version but now the GUI won't load. All devices work.

Maybe because too busy to update the db? I don't want to power it off now in case its working hard at something.

1613237960384.png
 

Rhialto

Regular Contributor
see the second post in this thread.
Thanks, I knew I've read about this somewhere thus what I was saying and was not under panic... ;-)

Those who are impatient and panic and restart while db is in the works, that may be a cause a of problems later.
 

Morac

Senior Member
This is probably a dumb question, but considering the amount of flashing I did today, I want to check.

As previously mentioned, in the process of trying to upgrade to 386.1_2, I had to install the ASUS official firmware in rescue mode, downgrade to 384.19 and then finally upgrade to 386.1_2.

I then restored the config and JFFS backups I made from 386.1. Should I be good?
 

L&LD

Part of the Furniture
@Morac I would guess, 'no'.

You are asking for issues doing the combination of steps you did.

Particularly with the problems you've been reporting in the last few days, I would follow the suggestions below to get your router/network to a good/known state where the router is using the expected defaults of the firmware it is currently running.

Once you are satisfied after a couple of days that the router/network is stable, save a backed-up copy of the config and JFFS settings then.

What you have now may work for a few days, a week, or indefinitely, in your specific network environment. But if any issues do crop up, they will be that much more difficult to track down and squash.

A full/proper reset now will give you peace of mind and a very good beginning on the 386.xxx codebase too.
 

QuikSilver

Very Senior Member

L&LD

Part of the Furniture
I

am

not

a

robot.


 

Morac

Senior Member
A full/proper reset now will give you peace of mind and a very good beginning on the 386.xxx codebase too.

I did a ”full/proper reset” after upgrading to 386.1 (8 days ago). Everything was working fine, except I couldn’t upgrade to 386.1_2.
 

RMerlin

Asuswrt-Merlin dev
If I do a dirty upgrade from 386.1 to 386.1_2, should I do a format JFFS at next reboot,

No.

I tried to update to the official ASUS Version 9.0.0.4.386.41994 and am getting the same error message.

Flash it in Recovery Mode.

The firmware validation code is closed source, so I have no way of knowing on which specific test your upgrade fails.
 

det721

Part of the Furniture
Wanted to add. The speed test on the AX58U works very well.
 

Attachments

  • Speed test (2).jpg
    Speed test (2).jpg
    58 KB · Views: 56
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