What's new

[Release] Asuswrt-Merlin 384.12 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!

Well..... I did it. I wrote down or screen shot every setting for 380.65 I had running. From the update page on the UI, I selected the 384.12 file and uploaded it from a wired connection. After three minutes or so, the router rebooted and the log-in screen was a little jumbled so I refreshed the browser window and was able to log in perfectly. Every setting was saved. I'm not going to do a factory reset unless the wife-unit complains about the speed. So far, so good. Cheers y'all!

While various parameters will be automatically migrated, some might not be. Things that require particular attention are the VPN settings, as well as SSH configuration (which changed a long time ago).

There's also the risk of wifi-related issues if the old "default" parameters are no longer optimal with the newer firmware. There was for a long time a bug for instance where a wifi-related parameter was incorrectly set, but it wasn't actively used so it went unnoticed for a long time. When part of the code started using it, that very old bug showed up. It's been too long now, so I don't remember what was the exact parameter or the symptoms. So, if you experience any weird wifi-related issues, a factory default reset will be required.
 
After setting log to "Only Info." I got these messages

Code:
Jun 27 11:43:19 rc_service: rc 12123:notify_rc restart_wrs
Jun 27 11:43:33 BWDPI: fun bitmap = 7f
Jun 27 18:30:10 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnpevents_processfds: 0x2c2f8, remove subscriber uuid:d1891695-a424-4775-a4d6-421a306d0212 after an ERROR cb: http://192.168.2.99:2869/upnp/eventing/shgowohrim

I don't have any upnp devices connected...
 
Wireless is all closed source and out of RMerlin's control. There is literally nothing he can do about it.
which is why I noted "until the buggy driver included in the gpl got updated.". but regardless, just noting my issues with this newer build.
I'll just downgrade to older release which was fine and wait until a new release with updated gpl base that may fix it and try again at that point.
 
After setting log to "Only Info." I got these messages

Code:
Jun 27 11:43:19 rc_service: rc 12123:notify_rc restart_wrs
Jun 27 11:43:33 BWDPI: fun bitmap = 7f
Jun 27 18:30:10 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnp_event_process_notify: connect(192.168.2.99:2869): Connection timed out
Jun 27 18:30:30 miniupnpd[28340]: upnpevents_processfds: 0x2c2f8, remove subscriber uuid:d1891695-a424-4775-a4d6-421a306d0212 after an ERROR cb: http://192.168.2.99:2869/upnp/eventing/shgowohrim

I don't have any upnp devices connected...
Not even a torrent?
 
This might be a starting point but you might need to dig a bit deeper:

https://www.snbforums.com/threads/dns-security.56784/page-2#post-494348

Thanks, there was some more info in that thread and another that I followed it to that offered some more detail.

This was changed to prevent various potential issues. Here are a few:

- Local DNS-based tests to determine if the connection was up could incorrectly report as being up since the response would come from dnsmasq's cache without actually trying to access the Internet
- More robust handling of Internet connections that rely on DHCP + VPN to establish a connection in two stages (like Russia's Beeline)
- More robust handling in case dnsmasq fails to start due to a misconfiguration of some sort
- More robust handling in case something went wrong with a VPN client or DNS over TLS configuration
Thank you. I'm not using network monitoring and my connection isn't reliant upon DHCP + VPN. I suppose I'll have to keep an eye out for dnsmasq issues but I don't mess with my config too much and don't currently have any issues relating to it.

However, I do VPN into my network through my router and I am using DoT. What sort of issues would one or the other cause by having this setting as 'Yes'? I'd just like to know what to look out for in case I would need to set it back to 'No'.

Thanks so much for the explanation.
 
While various parameters will be automatically migrated, some might not be. Things that require particular attention are the VPN settings, as well as SSH configuration (which changed a long time ago).

There's also the risk of wifi-related issues if the old "default" parameters are no longer optimal with the newer firmware. There was for a long time a bug for instance where a wifi-related parameter was incorrectly set, but it wasn't actively used so it went unnoticed for a long time. When part of the code started using it, that very old bug showed up. It's been too long now, so I don't remember what was the exact parameter or the symptoms. So, if you experience any weird wifi-related issues, a factory default reset will be required.

Thank you sir. I'll keep an eye out for any anomalies. I do have all parameters saved for my configuration and won't hesitate to reset to factory if anything seems amok.
 
You may be better off using OpenVPN on your PC. Fewer problems. Just try it if you do not have a good reason to have everything on your local network go over VPN.

Sent from my SM-T380 using Tapatalk

True...but then I can't use chromecast from any phone or pad since it takes the data from the router. Tried several times. VPN on the phone or pad does not work.
 
I have utorrent. Should I disable uPnP port mapping in utorrent, could that cause the log ?

P.S

what is that

Code:
Jun 27 11:43:33 BWDPI: fun bitmap = 7f
That quote message is related to QoS or so protection, you don't need to turn off upnp.
 
BUG Report: (RT-AC86U RMerlin v384.12)
Turn on Adaptive QoS and select mode like Games , save it and will see a game icon on the top ico area.
Reboot the router , the Adaptive QoS setting lost and it has been set to default of Constomize Mode.

Thank you RMerlin.
 
BUG Report: (RT-AC86U RMerlin v384.12)
Turn on Adaptive QoS and select mode like Games , save it and will see a game icon on the top ico area.
Reboot the router , the Adaptive QoS setting lost and it has been set to default of Constomize Mode.

Thank you RMerlin.
That's a known but with Asus who hasn't relase a fix for it yet.
 
I have utorrent. Should I disable uPnP port mapping in utorrent, could that cause the log ?

P.S

what is that

Code:
Jun 27 11:43:33 BWDPI: fun bitmap = 7f
Torrents need an open port to work as intended, then or you open and set one manually in router and utorrent or you let uPnP do it for you, so the log is normal (1h timeout and it closes the port if no more open torrent).

For the other, if you clear AiProtection log you have that message.
 
Hey there,
i have a AC68U and since the last two releases the Astrill VPN applet won't load. Anyone else?
What can i do to help fixing the problem?
Thanks!
 
Hey there,
i have a AC68U and since the last two releases the Astrill VPN applet won't load. Anyone else?
What can i do to help fixing the problem?
Thanks!
My suggestion is contact astrill and ask them for help.
 
Dirty upgrade to 384.12 from 11_2 on a RT-AC88U and RT-AC68U (ap). All running well so far.
 
One question to RMerlin:

I defined an individual up script within vpn server custom configuration settings (up /jffs/scripts/myscript), now I get the following message:
Jun 28 17:46:34 ovpn-server1[4504]: Multiple --up scripts defined. The previously configured script is overridden.

I read the changelog saying that there is now a default up/down vpn server script so I wanted to ask if this message means that my script overrides the default, or the default overrode my script?

Thank you for your answer,
best wishes,
Chris
 
I read the changelog saying that there is now a default up/down vpn server script so I wanted to ask if this message means that my script overrides the default, or the default overrode my script?

Your script is probably added at the end, so provided OpenVPN processes entries in descending order, your script is overriding the one configured by the firmware. Currently for servers, that script does nothing but call an openvpn-event script if it exists, however this could change in the future, so I do not recommend overriding it.

Instead, use an openvpn-event script, as it will be automatically called by the firmware's updown script. You can check the passed parameters to determine if the script is being called by your OpenVPN server1 instance, or by another OpenVPN instance. Also check if it's being called for an up, or a down event. Here is a list of parameters typically passed when the up script is called:

Code:
Jun 28 12:52:18 ovpn-server1[4425]: updown.sh tun21 1500 1621 10.8.0.1 255.255.255.0 init

tun21 would indicate vpnserver1. The "init" parameter will indicate that it's called when setting up.
 
I finally got 12_0 working including two VPN clients and one VPN server on my AC86. The VPN server is running with default settings and no problems getting it started. My aplogies to Merlin for implying there might have been an issue with 12_0.

The router has been unstable for a week and apparently L&LD's detailed and generally excellent tutorial were not enough to get my router stabilized even after multiple attemps to do so. A log of my actions over the past twenty four hours is attached.

Finally to get the router stable I had to put it into recovery mode and load a current version of ASUS firmware, then followed L&LD's instructions to reset the router and upgrade using the GUI to Merlin's 12_0.

I have abandoned the idea of running any scripts since I think the problem started when Skynet crashed.

If you have an AC86 and are having strange issues and L&LD's plan of attack doesn't solve them consider reloading firmware using the recovery mode.
 

Attachments

  • Configurationlog.txt
    4.6 KB · Views: 285

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