treboR2Robert
Occasional Visitor
35T2 does not work either
I am using 34E3 on my RT-N66R.
The only other thing I have running on it is Diversion ad blocker.
I did however notice the GUI in System Logs / Port Forwarding is bugged.
I'm using an android 8.0 Galaxy S9 running both OpenVPN clients Connect/For Android.
Maybe I will try and downgrade my FW.
Perhaps he doesn't need an AC router.You have an S9 and can not buy a cheap router like RT-AC68U.
I went to a RT-AC66U_B1 over a year ago and am please with it. Dual core processor and runs the same firmware as the RT-AC68U. There is also a new RT-N66U_C1 which has a dual core processor and may be able to run the same merlin firmware as the RT-AC68U but this is a guess as of now.Perhaps he doesn't need an AC router.
I know i don't and the N66 is about as good as it gets when it comes to wireless N routers.
For my AC needs i have a bt hub 5 set up as an access point in the room i usually sit in.
I do this because 5ghz AC signal doesn't travel anywhere near the distance that 2.4ghz N does.
So my main router (n66) in the hall only puts out 2.4ghz N for most devices like phones etc to connect to.
Pretty much all tvs, sky boxes and raspberry pis etc... are hardwired.
Then the only thing that connects to the 5ghz AC access point is my laptop when im in the same room as the AP for faster internal network transfers to save the hassle of connecting a ethernet every time.
Why would I waste money on a AC68U when my network works flawlessly as it is with a N66.
Perhaps MarkyMarkMark has a similar setup and the reason he can afford a s9 is because he doesn't go around wasting his money on stuff he doesn't need.
I went to a RT-AC66U_B1 over a year ago and am please with it. Dual core processor and runs the same firmware as the RT-AC68U. There is also a new RT-N66U_C1 which has a dual core processor and may be able to run the same merlin firmware as the RT-AC68U but this is a guess as of now.
# Custom Configuration
push "dhcp-option DOMAIN home.lan"^M
client-connect /jffs/scripts/openvpn-client-connect.sh
~
~
"config.ovpn" [noeol] 29L, 604C
Noticed a slight inconsistency in the VPN server config file (it's probably always been there). The Custom configuration lines are terminated with CR/LF instead of just LF (I haven't tried using a Linux-based browser).
Nope. It happens even when I type stuff from scratch.This is usually caused by copy/pasting into the Custom box - your paste contained the CR/LFs.
# Custom Configuration
sadasdasdasdadas^M
423414322141414^M
5fsdfsdfsfsfs
~
~
This type of behaviour will be fixed (or at least improved) in release v35.My DNS keeps switching over to the cloudflare server (primary, I presume). It may be a cleanbrowsing issue, I will try using ONLY one cleanbrowsing server to see if their DoT servers are borked. If that is not the case I don't know the cause of the switch.
It's always been there. It's a quirk of the broadcom routines that take a 'textarea' html box and write the data into nvram. I remember trying a lot of things in the gui code to eliminate them without success. I do remove them when I populate the custom config gui, or else everything is double spaced.@john9527 Noticed a slight inconsistency in the VPN server config file (it's probably always been there). The Custom configuration lines are terminated with CR/LF instead of just LF (I haven't tried using a Linux-based browser).
I'm still at a loss here.....I took a different tac and generated the list of all changed files between 33E7 and 34E3 and went through each one. Still can't see anything that would cause a breakage. If you run 34E3 without DoT enabled and without strict DNSSEC, it's identical to 33E7.I just tried the latest test version 35T3 and it has the same VPN reconnect problem as 34E3.
33E7 works fine
You do realize that a statement like this without any details goes directly into the bit bucket.....I did however notice the GUI in System Logs / Port Forwarding is bugged.
@ColinTaylorI just wrote a test fix to try and eliminate them from within the openvpn code when it generates the .ovpn file. We'll see how it goes.
VPN clients are subject to to 'global' min and max settings under Traditional QoS. Any other rules do not apply (the note about VPNs/Defaults on the QoS page is actually incorrect and will be removed in V35)
If you are using DoT, the router comes up initially without TLS encryption until the router time is set. DNSSEC is tied to the server capability.....if the DoT server support DNSSEC it will work, if not, it won't.02. In DoT CleanBrowsing/Cloudflare, if I have DNSSEC enabled in Strict mode and restart the router, the internet work? (Because you are using dnsmasq v2.80)
It depends on what turns out to be the release schedule. I'm currently running 2.80test6 (it looks like they are getting close to a final release).03. You will wait for the stable version 2.80 of dnsmasq, for you to release the next update like @RMerlin? (for me it is a wise decision or maybe not)
Remember, we don't get anything from Asus that says 'here's the code that fixes this problem'....we just get a code drop. So I make the attempt to look at the changed code in critical areas looking for what could be the fixes....sometimes it's easy to spot.....sometimes impossible (certainly impossible if the change is in closed source). Public documented CVEs I can usually find. Most of what I see being released lately is just previous fixes being applied to the different products and are already incorporated.04. You add these security fix that releases sometimes in the latest version of ASUS Official firmware? (or is it not necessary?)
I'm still at a loss here.....I took a different tac and generated the list of all changed files between 33E7 and 34E3 and went through each one. Still can't see anything that would cause a breakage. If you run 34E3 without DoT enabled and without strict DNSSEC, it's identical to 33E7.
The only other possibility is something in dnsmasq (although I don't see how that would play).
openvpn[548]: 192.168.0.53:57547 VERIFY OK: depth=0, CN=client1
openvpn[548]: 192.168.0.53:57547 peer info: IV_VER=2.5_master
openvpn[548]: 192.168.0.53:57547 peer info: IV_PLAT=android
openvpn[548]: 192.168.0.53:57547 peer info: IV_PROTO=2
openvpn[548]: 192.168.0.53:57547 peer info: IV_NCP=2
openvpn[548]: 192.168.0.53:57547 peer info: IV_LZ4=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_LZ4v2=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_LZO=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_COMP_STUB=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_COMP_STUBv2=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_TCPNL=1
openvpn[548]: 192.168.0.53:57547 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.5
<!-- 2nd connection log stops here -->
openvpn[548]: 192.168.0.53:57547 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so
This type of behaviour will be fixed (or at least improved) in release v35.
https://www.snbforums.com/threads/test-asuswrt-merlin-lts-fork-multiple-items.48642/#post-428118
Something I just noticed.....your client is running an unreleased version of openvpn, 2.5openvpn[548]: 192.168.0.53:57547 peer info: IV_VER=2.5_master
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!