Release [Beta] Asuswrt-Merlin 384.19 beta is now available

[Broken Hope]

Is JFFS used for any of the normal router settings, DHCP reservations etc? Or is it only if you’re using scripts/addons?

Can it be backed up and restored via the GUI?

 

[AntonK]

Is JFFS used for any of the normal router settings, DHCP reservations etc? Or is it only if you’re using scripts/addons?

Can it be backed up and restored via the GUI?

Regarding your second question, yes, see: Administration - Restore/Save/Upload Setting panel.

 

[L&LD]

Yes, it may be used for OpenVPN Servers and Clients that you've set up. I'm sure there are other things in there too.

 

[immi803]

Are you sure you download the correct FW? And not the one for AC86U?

Yes, I'm sure it's the right version AC68U

 

[QuikSilver]

Yes, I'm sure it's the right version AC68U

I had to unmount my USB drive from the gui and even then it still took 2 tries to take.

 

[shabbs]

Yes, it may be used for OpenVPN Servers and Clients that you've set up. I'm sure there are other things in there too.

As per the tool tip...

 

[RMerlin]

The exported file from the server that I import to the openvpn ios app.

According to the OpenVPN manual, "tcp" is not a valid proto, it has to be tcp-client:

–proto pUse protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.The default protocol is udp when –proto is not specified.


For UDP operation, –proto udp should be specified on both peers.

For TCP operation, one peer must use –proto tcp-server and the other must use –proto tcp-client. A peer started with tcp-server will wait indefinitely for an incoming connection. A peer started with tcp-client will attempt to connect, and if that fails, will sleep for 5 seconds (adjustable via the –connect-retry option) and try again infinite or up to N retries (adjustable via the –connect-retry-max option). Both TCP client and server will simulate a SIGUSR1 restart signal if either side resets the connection.

 

[RMerlin]

Eric, I get error message that my jffs partition is almost full, which is not the case since it was unmounted. However this message disappear once router mount jffs partition, usually after reboot.

View attachment 25103
View attachment 25104

It's because the router was being reported a size of -1, which was lower than the 3 MB threshold it checks for. I've changed it to display a different error message when the partition is not mounted.

 

[Intrepid2007]

The source IP must match the subnet of your LAN, which I assume is 192.168.2.0/24. In this setup, you are not routing anything through your VPN.

No, that is not correct: my LAN devices use IP addresses in the 172.16.0.0/24 - 172.16.2.0/24 range:

172.16.0.0/24: clients with an IP address in this subnet are routed directly (NO VPN)
172.16.1.0/24: clients with an IP address in this subnet are routed to VPN #1
172.16.2.0/24: clients with an IP address in this subnet are routed to VPN #2

The WAN is in the 192.168.2.0/24 range.

My laptop has an IP address of 172.16.1.50 and is connected via WIFI from the Asus router.
My ISP modem (192.168.2.254) is connected to the WAN port.

The VPN rule (VPN, source 172.16.0.1/24) makes sure that traffic of my laptop is routed to the VPN client.
The WAN rule (WAN, destination 192.168.2.0/24) makes sure that devices in the WAN are accesible to my laptop (my ISP modem)

When I do a test with ipleak.net, dnsleaktest.com or the VPN provider's test page, I can see that traffic is routed to the VPN tunnel (routing goes well!).

The problem/issue is that the VPN's DNS server is not used. Instead the DNS server specified in the WAN settings is used.

DNS leak test from VPN provider:

ipleak.net:

Whatever I select on the VPN client 'Accept DNS Configuration' setting (Strict or Exclusive), the VPN provider's DNS server is never shown when doing a test.

Update:
After a factory reset with this firmware I configured only one VPN client (DNS in 'exclusive' mode, no policy routing). I still have DNS leaks which is not normal.


After downgrading to alpha4, I noticed the same problem.

Then I downgraded to alpha3 and now it is working again:

 

[XIII]

Upgraded my RT-AC86U from 384.18 to 384.19 Beta 1. Although I properly ejected the USB drive the first upgrade failed after only a few percent: "Firmware upgrade unsuccessful. This may result from incorrect image or error transmission. Please check the version of firmware and try again.". Even though that error message already appeared at less than 10% the progress bar still slowly proceeded to 100%. Unfortunately the router was still at 384.18 then. A second attempt with the same firmware image was successful (free RAM memory seemed to be about the same in both attempts). No JFFS corruption here it seems (but I had plenty of free space).

 

[prosperot]

Flawless dirty upgrade on my 86u to 384.19B1, coming from 384.18. All settings and OpenVPN certificates survived the upgrade.

Only thing I ran into is that afterwards my Nest Hello had lost Wifi connection and would not reconnect automatically. But after a new wifi search on the Nest, everything is back to normal.

My OpenVPN works just fine on the UDP protocol I always used.

 

[Xentrk]

No, that is not correct: my LAN devices use IP addresses in the 172.16.0.0/24 - 172.16.2.0/24 range:

172.16.0.0/24: clients with an IP address in this subnet are routed directly (NO VPN)
172.16.1.0/24: clients with an IP address in this subnet are routed to VPN #1
172.16.2.0/24: clients with an IP address in this subnet are routed to VPN #2

The WAN is in the 192.168.2.0/24 range.

My laptop has an IP address of 172.16.1.50 and is connected via WIFI from the Asus router.
My ISP modem (192.168.2.254) is connected to the WAN port.

The VPN rule (VPN, source 172.16.0.1/24) makes sure that traffic of my laptop is routed to the VPN client.
The WAN rule (WAN, destination 192.168.2.0/24) makes sure that devices in the WAN is accesible to my laptop (my ISP modem)

When I do a test with ipleak.net, dnsleaktest.com or the VPN provider's test page, I can see that traffic is routed to the VPN tunnel (routing goes well!).

The problem/issue is that the VPN's DNS server is not used. Instead the DNS server specified in the WAN settings is used.

DNS leak test from VPN provider:
View attachment 25130

ipleak.net:
View attachment 25131

Whatever I select on the VPN client 'Accept DNS Configuration' setting (Strict or Exclusive), the VPN provider's DNS server is never shown when doing a test.

Update:
After a factory reset with this firmware I configured only one VPN client (DNS in 'exclusive' mode, no policy routing). I still have DNS leaks which is not normal.


After downgrading to alpha4, I noticed the same problem.

Then I downgraded to alpha3 and now it is working again:
View attachment 25133

What is the output of the command below? Replace "1" with the appropriate VPN Client number.

iptables --line -t nat -nvL DNSVPN1
iptables --line -t nat -nvL DNSVPN2

RPDB Rules

ip rule

If you are routing 192.168.2.0/24 to VPN Client 2, then remove the WAN Iface entry in VPN Client 1.

 

[Intrepid2007]

What is the output of the command below? Replace "1" with the appropriate VPN Client number.

iptables --line -t nat -nvL DNSVPN1
iptables --line -t nat -nvL DNSVPN2

RPDB Rules

ip rule

If you are routing 192.168.2.0/24 to VPN Client 2, then remove the WAN Iface entry in VPN Client 1.

View attachment 25137

What is the output of the command below? Replace "1" with the appropriate VPN Client number.

iptables --line -t nat -nvL DNSVPN1
iptables --line -t nat -nvL DNSVPN2

RPDB Rules

ip rule

If you are routing 192.168.2.0/24 to VPN Client 2, then remove the WAN Iface entry in VPN Client 1.

View attachment 25137

>> If you are routing 192.168.2.0/24 to VPN Client 2, then remove the WAN Iface entry in VPN Client 1.
The reason for this rule is that I want to be able to connect to my ISP modem, which has address 192.168.2.254 on the WAN.
I removed the WAN rule from VPN2 (client range 172.16.2.0/24). I can still access my ISP modem from my IP 172.16.1.50. This little change did not have effect at the DNS leak issue though...


Here is the output of
iptables --line -t nat -nvL DNSVPN1
iptables --line -t nat -nvL DNSVPN2

of both 384.19a3 and 384.19b1 (same setup):

The output for the 384,19b1 firmware appears to be 'empty'
The output for the 384.19a3 firmware shows IP addresses of DNS servers


output for 'rule ip' for both firmware versions:

 

[neil0311]

Dirty flash from 384.18 to .19 beta on AX88U. All is OK so far.

Only thing is this error has been present for the last several versions. Can anyone explain what this means and how to get rid of it? Is it a bug or configurational?

kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

 

[octopus]

Hi all
THIS IS SOLVED...... SBS
I have problem with "nslookup" in latest FW, Sometimes it's hit or miss if it working.
It can work "one" time and no more very strange. Is it working for you?
@dave14305 you helped me last time.....

CN="$(grep -E "CN" /tmp/vpnclient-3.log | tail -n 1 | cut -d '=' -f3)"                >>>>(from log "vpn01.prd.malmo.ovpn.com")
GROUP_IP="$(nslookup "$CN" | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | awk 'NR>2')"         >>>( answere "185.86.106.132")

# GROUP_IP="$(nslookup "$CN" | awk 'NR>2&&$1=="Address"{print $3;exit}')"

Have tested both nslookup example here:

@RMerlin
When is the vpn log written, do I have my till / tmp just before the vpn comes up?
EDIT: seems to work if i wait some time...........

+ echo 3
+ grep -qwE [1,3]
+ grep -E VERIFY OK: depth=0, /tmp/vpnclient-3.log
+ tail -n 1
+ cut -d = -f3
+ CN=
+ awk NR>2
+ grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3}
+ nslookup
nslookup: can't resolve ''
+ GROUP_IP=

 

[Vexira]

Maybe it's a "feature" to bring it in line with the AC86U

Thankfully I haven't encountered that feature.

 

[Morac]

No new binary blobs for the RT-AC88U?

I was hoping this version would have the CallStranger patch in it.

 

[Butterfly Bones]

No new binary blobs for the RT-AC88U?

I was hoping this version would have the CallStranger patch in it.

See RMerlin's reply to this question that comes up often.
https://www.snbforums.com/threads/384-19_alpha-build-s-testing-available-build-s.65003/post-607264

 

[Deleted member 22229]

No new binary blobs for the RT-AC88U?

I was hoping this version would have the CallStranger patch in it.

Merlin's Firmware does not need the Call Stranger patch it's does not have that exploit.

 

[Jack Yaz]

No new binary blobs for the RT-AC88U?

I was hoping this version would have the CallStranger patch in it.

there's nothing to patch. please use the search feature in future.

Release - [ 384.19_Alpha Build(s) ] Testing available build(s)

Not at all the end of the line: closing the 384.18 final thread just means that RMerlin thinks that discussion has run its course and any additional posts would only stray further off topic (to meandering, random topics). Development is actively under way on 384.19: this thread started with a...

www.snbforums.com