What's new

[Beta] Asuswrt-Merlin 380.67 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.
Sorry about the OT. But if you don't push redirect_gateway from the server then doesn't it depend on whether the client has --redirect-gateway? I think I'm doing this with a Chromebook, where I have one .onc with "ignore_default_route" and one without. I think that is the equivalent for .ovpn.
Don't think that works... The server has to be setup to handle the redirect requests according to the openvpn documentation. If you try to get the client to push all requests thru the server and the server doesn't know it is suppose to handle them it can't do the redirects...

RMerlin is this a broken openvpn implementation or is there something wrong with my setup? It worked until I switched to the latest official release and the betas.

380.66_6 (22-June-2017)
- CHANGED: Updated OpenVPN to 2.4.3
- FIXED: Corrupted firewall rules if enabling SSHD brute-force
protection and Respond to WAN Ping at the same time
while in Dual WAN mode.

This is when I think it broke so not sure if it is broken in 2.4.3

I may have found a problem...

push "route 0.0.0.0 255.255.255.255 net_gateway" is in the config file for the server with direct client traffic... Is this suppose to be in here? Openvpn says to push this when you want to IgnoreRedirectGateway
 
Last edited:
Is beta 4, safe to compile or should i wait for it to be released?
 
I am still running 380.67 Beta 2. Per ipleak.net, I have DNS leaks on the router where VPN traffic is set to policy rules. On the router with VPN = All Traffic, I don't have DNS leaks.
 
I am still running 380.67 Beta 2. Per ipleak.net, I have DNS leaks on the router where VPN traffic is set to policy rules. On the router with VPN = All Traffic, I don't have DNS leaks.

Set DNS mode to Exclusive, and make sure you don't have IPv6 enabled.
 
Is beta 4, safe to compile or should i wait for it to be released?

Git always contains up-to-date code, so that means from one commit to another its stability (or even compile-ability) might vary, models aren't all tested, etc...

All I can say is that I'm currently running code from hash e4692b2 on my RT-AC88U.
 
IMG_3253.JPG
Thank You. The atm feature in fq_codel thats mainly for dsl connections correct
 
Set DNS mode to Exclusive, and make sure you don't have IPv6 enabled.
Thank you for the reply. This is a minor item for me and I'm sure you have a lot on your plate right now.

I verified that IPv6 is not enabled. On the router with All Traffic, I do set DNS mode to Exclusive and have no DNS leaks. However, I found I need to set DNS Mode to Strict for Policy Rules for AB-Solution to work over the VPN Tunnel. Otherwise, AB-Solution only works for WAN traffic. I first noticed this when I was participating on the AB-Solution 3.8 test team and was using 380.65. It may have been happening before that. Here is a screen print with the client information left out.

upload_2017-7-12_8-13-42.png


upload_2017-7-12_8-15-10.png


I use TorGuard and documented the settings in these threads.
https://www.snbforums.com/threads/torguard-openvpn-2-4-client-setup-for-asus-merlin-380-65-380-65_2-part-i.38281/

https://www.snbforums.com/threads/torguard-openvpn-2-4-client-setup-for-asus-merlin-380-65-380-65_2-part-ii.38282/

https://www.snbforums.com/threads/torguard-openvpn-2-4-client-setup-for-asus-merlin-380-65-380-65_2-part-iii.38283/

Thank you, Xentrk
 

Attachments

  • upload_2017-7-12_8-14-30.png
    upload_2017-7-12_8-14-30.png
    205 KB · Views: 665
Git always contains up-to-date code, so that means from one commit to another its stability (or even compile-ability) might vary, models aren't all tested, etc...

All I can say is that I'm currently running code from hash e4692b2 on my RT-AC88U.
Ah cool was wonder just in the case of my 88u
 
Beta 4 is up.

Code:
7df69e9 openvpn: changed two logger calls to avoid spaces in program id (ref. issue #1413)
4439b10 ez-ipupdate: make syslog entries RFC-compliant, by removing space from tag (ref. issue #1413)
1dac206 shared: make logmessage() ensure that provided tag don't break RFC3164 by using spaces (ref. issue #1413)
d864e5b rc: reverting logmessage change in Asus's own cases, as we're going to tackle the issue differently, and I don't want unnecessary changes that would increase the risk of merge issues with new GPL
e4692b2 Updated documentation
4620b18 shared: fix replace_char() parameter types
4c85fba rc: minor optimization to ntp - use nvram_get_int() instead of nvram_match()
a08b0a9 webui: properly escape OpenVPN user/passwords that contain &xx strings (close #1398)
f374d01 ssh: revert idle timeout support, as it doesn't work properly anyway
7db034b shared: add missing ";" from previous commit
4a2786c webui: Fix custom Adaptive QoS priority saving under IE 11
d625d15 rc, shared: provide RFC3164 compliant TAG field for hour_monitor and custom_script logmessage() calls (closes #1413)
9f9fd49 webui: add missing help hint for VirtualServer's source IP field (bug from Asus; closes #1409)
f87f4e0 kernel: ctf: temporary fix icmpv6 errors forwarding in reply
4df9152 firewall: fix rule generation for trigger port ranges
e6136ae shared: add replace_char function to strings.c
302d9ce iptables: fix iptables-save for trigger rules
f20cf3c qos: modified tc patch to avoid any potential endless loop between faketc and realtc
c4e8b37 Bumped revision to beta 4
 
There is Aicloud problem. It worked until beta1.

@RT-AC1900P-9C48:/tmp/home/root# /usr/sbin/lighttpd -f /tmp/lighttpd.conf -D

2017-07-13 05:32:54: (network.c.538) SSL: BIO_read_filename('/etc/server.pem') failed

I can't find server.pem although I turn on Aicloud feature.
 
Beta 4 is up.

Code:
7df69e9 openvpn: changed two logger calls to avoid spaces in program id (ref. issue #1413)
4439b10 ez-ipupdate: make syslog entries RFC-compliant, by removing space from tag (ref. issue #1413)
1dac206 shared: make logmessage() ensure that provided tag don't break RFC3164 by using spaces (ref. issue #1413)
d864e5b rc: reverting logmessage change in Asus's own cases, as we're going to tackle the issue differently, and I don't want unnecessary changes that would increase the risk of merge issues with new GPL
e4692b2 Updated documentation
4620b18 shared: fix replace_char() parameter types
4c85fba rc: minor optimization to ntp - use nvram_get_int() instead of nvram_match()
a08b0a9 webui: properly escape OpenVPN user/passwords that contain &xx strings (close #1398)
f374d01 ssh: revert idle timeout support, as it doesn't work properly anyway
7db034b shared: add missing ";" from previous commit
4a2786c webui: Fix custom Adaptive QoS priority saving under IE 11
d625d15 rc, shared: provide RFC3164 compliant TAG field for hour_monitor and custom_script logmessage() calls (closes #1413)
9f9fd49 webui: add missing help hint for VirtualServer's source IP field (bug from Asus; closes #1409)
f87f4e0 kernel: ctf: temporary fix icmpv6 errors forwarding in reply
4df9152 firewall: fix rule generation for trigger port ranges
e6136ae shared: add replace_char function to strings.c
302d9ce iptables: fix iptables-save for trigger rules
f20cf3c qos: modified tc patch to avoid any potential endless loop between faketc and realtc
c4e8b37 Bumped revision to beta 4

I assume that GPL merge for 7743 still applies for AC68U and akin models, noticed it's not specified in your change log for this beta release.
 
I have an intermittent problem with my RT-AC3100 router... wifi stops working after some time and the only way to fix this is to reboot the router.

When wifi stops working, wired is ok and remote access though OpenVPN is also ok.

Yesterday night I was at home when it happened... wifi network was visible but when trying to connect, it said that my password was incorrect. at that time, I did not changed anything... I just rebooted the router and it was fine after that.

I think this all started with one of the 380.67 beta because I never had this problem before.

Smartconnect is enabled on my router... but beside that, there's nothing fancy in my setup.

what could be the problem?
 
I have an intermittent problem with my RT-AC3100 router... wifi stops working after some time and the only way to fix this is to reboot the router.

When wifi stops working, wired is ok and remote access though OpenVPN is also ok.

Yesterday night I was at home when it happened... wifi network was visible but when trying to connect, it said that my password was incorrect. at that time, I did not changed anything... I just rebooted the router and it was fine after that.

I think this all started with one of the 380.67 beta because I never had this problem before.

Smartconnect is enabled on my router... but beside that, there's nothing fancy in my setup.

what could be the problem?

Here are a few options to try, no particular order and really to your discretion of what may make more sense.

1. Reset your device to factory default after upgrading to Beta to simply clear the NVRAM. While this should not be necessary, never hurts and can save hours of aggregation trying to resolve weird anomalies.

OR

2. Revert back to a stable release that worked for you prior to upgrading to the beta, reset to factory, start clean. If you run into the issue again while on a stable release, this can indicate a potential HW issue.

Note: as always, remember to disable the MU-MIMO, airtime fairness, beamforming etc. regardless if you are on stable or beta release fw.
 
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