What's new

Beta Asuswrt-Merlin 386.3 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.
It varies. Sometimes it's out the next day, sometimes it takes 2 months. In my case it's different, as they build special tarballs for me (as I need the same codebase for all supported models, so they generate GPL releases even for models which didn't get a firmware release for that specific codebase). GPL releases have been on hold for a few weeks now as they need to address some issues with the generated archives.


It's not that simple. For instance, a firmware image contains fully linked kernel modules (*.ko files), while for building a firmware you need the pre-linked object files (*.o). You need the actual GPL archives with those object files so they can be properly linked within the generated firmware filesystem. And a lot of components interact with one another, so you can't just blindly replace one single file, and expect it to work properly. SDK changes for instance may also require code changes within libshared or rc, which will require the proprietary object files that have been generated to work with that updated SDK. Trying to do that kind of frankenbuilding is generally a large waste of time, and I don't want to do it anymore.
Oh ok that makes sense. Man what kind of hook-up you got with ASUS? i bet you use to work there huh? :p

and yeah your right it was a huge waste of time. i just figured out the reason i wasnt seeing the error in the stock fw is because they have the system log level higher(less info, or would that be lower lol) so it doesnt show kernel CONSOLE msgs i think they have it set to notice and merlin is debug ofc
 
Updated 2x RT-AC86U and 1x RT-AC68U to latest beta, with no issues. One of which is part of a S2S mesh back to primary site here.

Good work as usual! Cheers.
 
Looks like ASUS have changed some other bits of code as their AiMesh is partly broken for me with this release.

I have AX88U with two AX86U nodes - one wired one 5G backhaul.

With 386.3 the 5G node falls back to 2.4G backhaul after 12-24 hours (same with official ASUS 386.3). A reboot fires up 5G backhaul but this just repeats. 5G backhaul under 386.2 works fine without issues. Strength is reported by AiMesh as ‘good’ at around -62dB.

I know this is all closed source and Merlin won’t be able to fix this so staying on 386.2 for now.

HB

Interesting. Mine are hardwired but this issue is a good observation to know about.
 
Dirty upgrade from 386.2_6 to 386.3b1 here. VPN is working great. Every setting carried over, however with my Roku set to WAN it has no internet connection. It acts as if the "kill switch" is shutting it down because it's not going through the tunnel. Turning off said kill switch has no effect.
 
Dirty upgrade from 386.2_6 to 386.3b1 here. VPN is working great. Every setting carried over, however with my Roku set to WAN it has no internet connection. It acts as if the "kill switch" is shutting it down because it's not going through the tunnel. Turning off said kill switch has no effect.
We'll need more info on your setup: DNS mode, VPN routing mode, etc...
 

Attachments

  • VPN.png
    VPN.png
    334.8 KB · Views: 202
  • VPN2.png
    VPN2.png
    271.3 KB · Views: 201
  • VPN3.png
    VPN3.png
    359.1 KB · Views: 197
I'm currently using vpnmgr (Jack Yaz script) with current stable fw.

If I want to try this beta fw, do I need uninstall vpnmgr? I don't think it will work with VPN Director correct?
 
Quick question for you all on the Alpha, playing around with the VPN Director. I am currently running most of my VPN config/initialization through an openvpnclient1.postconf file... since the interface isn't able to hold everything under the custom config section of the GUI. Is this going to have any effect on the operation or use of the VPN Director?
 
No matter what I adjusted on this beta, I could not get the VPN killswitch to work properly. Ended up dropping back to last release, recreating policy rules, as well as needing to re-insert the VPN conditions as they had been wiped.

Gonna have to do some reading about the VPN Director changes.
 
Quick question for you all on the Alpha, playing around with the VPN Director. I am currently running most of my VPN config/initialization through an openvpnclient1.postconf file... since the interface isn't able to hold everything under the custom config section of the GUI. Is this going to have any effect on the operation or use of the VPN Director?
The Custom section can now contain much longer configurations than previous releases (up to 4095 characters now instead of only around 300 in 386.2). You will probably no longer need that.

I had forgotten to add that to the changelog.
 
Dirty upgrade from 386.2_6 to 386.3b1 here. VPN is working great. Every setting carried over, however with my Roku set to WAN it has no internet connection. It acts as if the "kill switch" is shutting it down because it's not going through the tunnel. Turning off said kill switch has no effect.
Your WAN rule is disabled, try re-enabling it.

Do you have any special DNS configuration on your router (DNSFilter, DHCP page or WAN page)?
 
Your WAN rule is disabled, try re-enabling it.

Do you have any special DNS configuration on your router (DNSFilter, DHCP page or WAN page)?
Yes, that is what I am saying. If I enable it it has no internet connection. I will check those pages for you asap, currently not home. Thank you.
 
I'm currently using vpnmgr (Jack Yaz script) with current stable fw.

If I want to try this beta fw, do I need uninstall vpnmgr? I don't think it will work with VPN Director correct?
vnpmgr is working here, under the new beta
 
Dirty update over latest stable....so far so good.
 
Your WAN rule is disabled, try re-enabling it.

Do you have any special DNS configuration on your router (DNSFilter, DHCP page or WAN page)?
To make sure I am clear as mud. I had everything routed through VPN except the Roku on 386.2_6. It worked flawless. Local TV via Fubo works with the VPN however Vudu and Amazon Prime ect. do not, hence the WAN setting for the Roku. Family was watching tv while I upgraded firmware to 386.3b and the Roku went down, no internet connection detected. The only way I can get it back up is to disable the WAN rule for the Roku. I hope these screen shots are what you requested.
 

Attachments

  • DNSfilter.png
    DNSfilter.png
    593.7 KB · Views: 121
  • DHCP.png
    DHCP.png
    527.6 KB · Views: 131
  • Wan1.png
    Wan1.png
    577.9 KB · Views: 117
  • Wan2.png
    Wan2.png
    463.7 KB · Views: 117
To make sure I am clear as mud. I had everything routed through VPN except the Roku on 386.2_6. It worked flawless. Local TV via Fubo works with the VPN however Vudu and Amazon Prime ect. do not, hence the WAN setting for the Roku. Family was watching tv while I upgraded firmware to 386.3b and the Roku went down, no internet connection detected. The only way I can get it back up is to disable the WAN rule for the Roku. I hope these screen shots are what you requested.
When android box shows no internet connection, does it have correct time? Because Android box must have correct time to have internet connection, it does this through NTP protocol. If your VPN server actively block NTP or UDP or its port, you won’t be able to sync time thus no internet connection.
 
First boot post upgrade, I needed to change the VPN Client > Redirect Internet traffic through tunnel setting to VPN Director (policy rules) as it was initially set to No. Once this adjustment was made, everything worked fine and the VPN Director settings appear to be functioning as expected.
 
Is it possible to use VPN Director to block access to the VPN tunnels from selected IP ranges on my LAN?
 
Is it possible to use VPN Director to block access to the VPN tunnels from selected IP ranges on my LAN?

One approach that I just tried was to point a select IP range on my local LAN to the WAN when attempting to access a VPN IP range, but that did not work. Still could access the VPN network.
 
One approach that I just tried was to point a select IP range on my local LAN to the WAN when attempting to access a VPN IP range, but that did not work. Still could access the VPN network.
It won`t block access to the VPN, it will just use the WAN gateway for routing their traffic.

Make sure you set the local IP as your LAN clients, and leave the remote IP empty.
 
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