Beta Asuswrt-Merlin 3004.388.8 beta is now available

RMerlin · Thursday at 2:35 PM

Mikeyy said:
After upgrading from 3004.388.7 to 388.8 beta1 my Internet connection stopped working. Downgraded back to 388.7 and it's working again.
I use PPPoE connection. Internet status said that connection to ISP is established and I got my WAN IP. If I remember correctly, subnet was 255.255.255.255 / 0 while now on .7 is 255.255.255.255 / 255.255.0.0

Tried changing DNS, tried opening 1.1.1.1 in web browser, nothing worked.

Look at your system log, it will tell you what's happening.

Nobody can help you with the absence of any information beyond "stopped working".

Mikeyy · Thursday at 4:42 PM

RMerlin said:
Look at your system log, it will tell you what's happening.

This is the system log after I turned off internet connection, and then reconnected (from router main network map screen).
Not sure if any of these help, but I'm using AX86U, PPPoE connection, with upnp turned off, custom DDNS script, DNS is via DNS-over-TLS, DNS Director set to "Router". No other custom scripts.

Code:

Jun 27 22:29:48 rc_service: httpd 1667:notify_rc restart_wan_if 0
Jun 27 22:29:50 pppd[3281]: Plugin rp-pppoe.so loaded.
Jun 27 22:29:50 pppd[3281]: RP-PPPoE plugin version 3.11 compiled against pppd 2.4.7
Jun 27 22:29:50 pppd[3283]: pppd 2.4.7 started by xxxyyy, uid 0
Jun 27 22:29:50 pppd[3283]: PPP session is 17228 (0x434c)
Jun 27 22:29:50 pppd[3283]: Connected to fa:16:3e:05:dc:23 via interface vlan100
Jun 27 22:29:50 pppd[3283]: Using interface ppp0
Jun 27 22:29:50 pppd[3283]: Connect: ppp0 <--> vlan100
Jun 27 22:29:50 pppd[3283]: Remote message: Access Accepted.^@
Jun 27 22:29:50 pppd[3283]: PAP authentication succeeded
Jun 27 22:29:50 pppd[3283]: peer from calling number FA:16:3E:05:DC:23 authorized
Jun 27 22:29:50 lldpd[1744]: removal request for address of 78.2.89.42%28, but no knowledge of it
Jun 27 22:29:50 pppd[3283]: local  IP address 78.2.89.42
Jun 27 22:29:50 pppd[3283]: remote IP address 172.27.99.1
Jun 27 22:29:50 lldpd[1744]: removal request for address of 172.27.99.1%28, but no knowledge of it
Jun 27 22:29:50 lldpd[1744]: removal request for address of 78.2.89.42%28, but no knowledge of it
Jun 27 22:29:50 lldpd[1744]: removal request for address of 78.2.89.42%28, but no knowledge of it
Jun 27 22:29:50 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Jun 27 22:29:50 dnsmasq[2061]: read /etc/hosts - 22 names
Jun 27 22:29:50 dnsmasq[2061]: using nameserver 127.0.1.1#53
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for mask.icloud.com
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for use-application-dns.net
Jun 27 22:29:50 dnsmasq[2061]: using nameserver 127.0.1.1#53
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for mask.icloud.com
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:29:50 dnsmasq[2061]: using only locally-known addresses for use-application-dns.net
Jun 27 22:29:50 wan: finish adding multi routes
Jun 27 22:29:50 openvpn-routing: Applying all killswitches
Jun 27 22:29:50 miniupnpd[2039]: shutting down MiniUPnPd
Jun 27 22:29:50 miniupnpd[3425]: Error: option ext_ip contains invalid address
Jun 27 22:29:50 ddns: WAN(0) IP is empty.(10)
Jun 27 22:29:50 rc_service: ip-up 3289:notify_rc stop_samba
Jun 27 22:29:50 Samba_Server: smb daemon is stopped
Jun 27 22:29:51 rc_service: ip-up 3289:notify_rc start_samba
Jun 27 22:29:51 dnsmasq[2061]: exiting on receipt of SIGTERM
Jun 27 22:29:51 stubby[3433]: Stubby version: Stubby 0.4.2
Jun 27 22:29:51 dnsmasq[3437]: started, version 2.90 cachesize 1500
Jun 27 22:29:51 dnsmasq[3437]: DNSSEC validation enabled
Jun 27 22:29:51 dnsmasq[3437]: configured with trust anchor for <root> keytag 20326
Jun 27 22:29:51 dnsmasq[3437]: asynchronous logging enabled, queue limit is 5 messages
Jun 27 22:29:51 dnsmasq-dhcp[3437]: DHCP, IP range 192.168.102.2 -- 192.168.102.254, lease time 1d
Jun 27 22:29:51 dnsmasq-dhcp[3437]: DHCP, IP range 192.168.101.2 -- 192.168.101.254, lease time 1d
Jun 27 22:29:51 dnsmasq-dhcp[3437]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:29:51 dnsmasq[3437]: read /etc/hosts - 22 names
Jun 27 22:29:51 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:29:51 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:29:51 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:30:05 WAN(0)_Connection: WAN was restored.
Jun 27 22:30:05 dnsmasq[3437]: read /etc/hosts - 22 names
Jun 27 22:30:05 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:30:05 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:30:05 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:30:11 avahi-daemon[1625]: Joining mDNS multicast group on interface vlan100.IPv4 with address 169.254.136.82.
Jun 27 22:30:11 avahi-daemon[1625]: New relevant interface vlan100.IPv4 for mDNS.
Jun 27 22:30:11 avahi-daemon[1625]: Registering new address record for 169.254.136.82 on vlan100.IPv4.
Jun 27 22:30:11 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Jun 27 22:30:11 dnsmasq[3437]: read /etc/hosts - 22 names
Jun 27 22:30:11 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:30:11 dnsmasq[3437]: using nameserver 127.0.1.1#53
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for mask-h2.icloud.com
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for mask.icloud.com
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for _dns.resolver.arpa
Jun 27 22:30:11 dnsmasq[3437]: using only locally-known addresses for use-application-dns.net
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 6^[[0m
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] runnerMcast_deactivate,736: Cannot rdpa_mcast_flow_find, ret = -5^[[0m
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 2^[[0m
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] runnerMcast_deactivate,736: Cannot rdpa_mcast_flow_find, ret = -5^[[0m
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 2^[[0m
Jun 27 22:30:11 kernel: ^[[0;33;41m[ERROR pktrunner] runnerMcast_deactivate,736: Cannot rdpa_mcast_flow_find, ret = -5^[[0m
Jun 27 22:30:11 zcip_client: configured 169.254.136.82
Jun 27 22:30:12 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 2^[[0m
Jun 27 22:30:12 kernel: ^[[0;33;41m[ERROR pktrunner] runnerMcast_activate,650: ADD_PORT Port 0x08 has already been added^[[0m
Jun 27 22:30:13 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 6^[[0m
Jun 27 22:30:13 kernel: ERR: rdpa_if_to_rdd_bridge_port#235: Can't map rdpa_if 891307828 to rdd bridge port
Jun 27 22:30:13 kernel: ^[[0;33;41m[ERROR pktrunner] __fhwPktRunnerActivate,406: Mcast modify Invalid key_in <0:4294967295>; ^[[0m
Jun 27 22:30:13 kernel: ^[[0;33;41m[ERROR pktrunner] __fhwPktRunnerActivate,416: Mcast modify Invalid pktRunner_flow_idx <0:1048575>; ^[[0m
Jun 27 22:30:20 kernel: ^[[0;33;41m[ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 2^[[0m
Jun 27 22:30:20 kernel: ERR: rdpa_if_to_rdd_bridge_port#235: Can't map rdpa_if 891307828 to rdd bridge port
Jun 27 22:30:20 kernel: ^[[0;33;41m[ERROR pktrunner] runnerMcast_activate,650: ADD_PORT Port 0x08 has already been added^[[0m
Jun 27 22:30:20 watchdog: start ddns.
Jun 27 22:30:20 ddns: update CUSTOM , wan_unit 0
Jun 27 22:30:20 ddns: Clear ddns cache.
Jun 27 22:30:20 custom_script: Running /jffs/scripts/ddns-start (args: 78.2.89.42)
Jun 27 22:30:21 ddns: Completed custom ddns update

Mikeyy · Thursday at 4:42 PM

After few minutes of not doing anything, I checked log again.

Code:

Jun 27 22:33:07 kernel: wl0: random key value: E4C3C3E2F5B0D6CE0FA703783E97D330CAFAE1ED50FB05B75B85A8CA9E23BA69
Jun 27 22:33:07 hostapd: eth6: STA 28:6d:97:cd:de:f5 IEEE 802.11: disassociated
Jun 27 22:33:07 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 28:6D:97:CD:DE:F5, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jun 27 22:33:12 wlceventd: wlceventd_proc_event(685): eth6: Auth 28:6D:97:CD:DE:F5, status: Successful (0), rssi:0
Jun 27 22:33:12 hostapd: eth6: STA 28:6d:97:cd:de:f5 IEEE 802.11: associated
Jun 27 22:33:12 wlceventd: wlceventd_proc_event(722): eth6: Assoc 28:6D:97:CD:DE:F5, status: Successful (0), rssi:-51
Jun 27 22:33:12 hostapd: eth6: STA 28:6d:97:cd:de:f5 RADIUS: starting accounting session 4D5934C693EFA093
Jun 27 22:33:12 hostapd: eth6: STA 28:6d:97:cd:de:f5 WPA: pairwise key handshake completed (RSN)
Jun 27 22:33:12 dnsmasq-dhcp[3437]: DHCPDISCOVER(br0) 28:6d:97:cd:de:f5
Jun 27 22:33:12 dnsmasq-dhcp[3437]: DHCPOFFER(br0) 192.168.1.109 28:6d:97:cd:de:f5
Jun 27 22:33:13 dnsmasq-dhcp[3437]: DHCPDISCOVER(br0) 28:6d:97:cd:de:f5
Jun 27 22:33:13 dnsmasq-dhcp[3437]: DHCPOFFER(br0) 192.168.1.109 28:6d:97:cd:de:f5
Jun 27 22:33:13 dnsmasq-dhcp[3437]: DHCPREQUEST(br0) 192.168.1.109 28:6d:97:cd:de:f5
Jun 27 22:33:13 dnsmasq-dhcp[3437]: DHCPACK(br0) 192.168.1.109 28:6d:97:cd:de:f5 hubv3-04021213253

RMerlin · Thursday at 4:56 PM

Mikeyy said:
This is the system log after I turned off internet connection, and then reconnected (from router main network map screen).

The Internet connection is fine according to that log. You get an IP through PPP, and dnsmasq is running. The DDNS client is even able to update its IP address, so the router itself does have Internet access. However you might want to check this:

Code:

Jun 27 22:29:50 openvpn-routing: Applying all killswitches

The new killswitch is stricter. If you have it enabled on a VPN client, then it will get activated even if that client is disabled.

Mikeyy said:
No other custom scripts.

This system log line says otherwise:

Code:

Jun 27 22:30:11 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)

You have a custom firewall-start script. Review its content.

Mikeyy · Thursday at 5:10 PM

RMerlin said:
The new killswitch is stricter. If you have it enabled on a VPN client, then it will get activated even if that client is disabled.

Thank you, this is it. I had some old test config loaded on openVPN client 1, but it was OFF (disabled).

RMerlin · Thursday at 5:14 PM

Mikeyy said:
Thank you, this is it. I had some old test config loaded on openVPN client 1, but it was OFF (disabled).

I guess that at least gives me one report of whether the new killswitch is working properly or not

Caesar the Dictator · Friday at 2:48 AM

I think the new kill switch works like @Viktor Jaep's KILLMON tool. Here's how I can explain Jaep's tool as a regular user: All private IP addresses covered by KILLMON can only use VPN interfaces. If there is no active VPN client, i.e. if VPN tunnel is crashed or manually disabled, the traffic of those IP addresses is never routed to WAN. Even if all or partial traffic of some of those IP addresses is redirected to WAN via the VPN Director, the traffic is never redirected to WAN, so you have to remove that IP addresses from KILLMON range. Sometimes I even use this feature to completely or partially destroy the internet connection of targeted devices.

When WireGuard protocol feature is added to Asuswrt-Merlin firmware, it was emphasized that a kill switch was not needed because by design the WireGuard protocol would not leak traffic to WAN if the tunnel crashed. However, if the WireGuard client was disabled manually, traffic would be routed to WAN. Although some VPN providers suggest to include a syntax in the WireGuard configuration file that will act as a kill switch for WireGuard protocol.

Code:

PostUp  =  iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show  %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show  %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

Anyway, I understand that the firmware will have a kill switch that is also valid for WireGuard protocol, similar to the kill switch function that KILLMON has been performing very successfully for some time, is this correct?

RMerlin · Friday at 10:06 AM

Caesar the Dictator said:
similar to the kill switch function that KILLMON has been performing very successfully for some time, is this correct?

That script uses the firewall, while the firmware implementation uses the routing tables.

MacG32 · Friday at 5:50 PM

I was able to test out the killswitch for OpenVPN. Works very well. I just stopped the VPN Client while loading webpages. Not sure how to setup Wireguard to work with PIA. Thank you @RMerlin for all of your hard work!

SMS786 · Friday at 6:06 PM

OVPN updated to 2.6.11(https://github.com/OpenVPN/openvpn/releases/tag/v2.6.11), friendly reminder just in case it wasn't already on your radar @RMerlin

As always, many thanks for all of your efforts!

pusb87 · Friday at 7:05 PM

MacG32 said:
I was able to test out the killswitch for OpenVPN. Works very well. I just stopped the VPN Client while loading webpages. Not sure how to setup Wireguard to work with PIA. Thank you @RMerlin for all of your hard work!

PIA do not provide WG config files . Its been high priority with them for the last 4 years or so to do so....
Move on to a better provider....

RMerlin · Friday at 8:17 PM

SMS786 said:
OVPN updated to 2.6.11(https://github.com/OpenVPN/openvpn/releases/tag/v2.6.11), friendly reminder just in case it wasn't already on your radar @RMerlin

As always, many thanks for all of your efforts!

Very minor update that came out right as I was starting the beta cycle, so I decided to delay that update to the next release.

kernol · Saturday at 4:37 AM

Confirmed my RT-AX86U-PRO behaves as designed for killswitch settings on the multi NordVPN clients I run.
Some are set with killswitch "Yes" and others "No" - and all work exactly as intended [for the first time as far as I can recall] and with zero leaks.
Also have various options for DNS configurations between VPN clients - and those too are fully respected and operate as intended.

MANY thanks. Everything as per my signature working perfectly as well.

Ripshod · 2024-06-30T16:57:47-0400

One week on the clock and nothing to complain about

Thanks @RMerlin

MayBe · 2024-06-30T17:44:11-0400

Someone can test it in this release.
VPN Director, when enabling custom routing rules for the WG tunnel, disables offloading for traffic between WiFi and Lan clients (limits it at 1Gb\s, puts a full-load on the one CPU core)
LAN - WiFi, not VPN-LAN traffic
Or is this the specifics of VPN Director's work and it normal?

Sweden · 2024-07-01T05:01:27-0400

RMerlin said:
The majority of VPN providers do not support port forwarding, and the few that do require you to use a custom API that is unique to them. That's why it's not something that can be standardized in the router firmware itself, each case is unique.

Aha, i see. I am running OVPN and all you need to do on their homepage is to click "open ports" and up to 8 ports are opened.
Once connected to OVPN i just change my clients to use that specific port and i am connectable. Thats why i wondered, why it
should be so hard to open up a port in the router. On my PC, i dont need to do anything at all. It just work like a charm direcly.
Only thing i need to do is to reconnect to VPN provider. With old VPN it work fine to create custom scripts in router, to open ports,
i just wish the same thing were standardized for wireguard.

By the way, i am running 3004.388.8_beta1, and i installed it almost once it was announced. Has worked fine, but today
dnslookup were soooo slow. Dont know why, but a reboot of router solved the problem instant.

joegreat · 2024-07-01T05:54:54-0400

Two days running on AX88U - dirty update - with no issues!

Thread starter	Title	Forum	Replies	Date
	Release Asuswrt-Merlin 3004.388.7 is now available	Asuswrt-Merlin	435	Apr 26, 2024
	Beta Asuswrt-Merlin 3004.388.7 beta is now available	Asuswrt-Merlin	123	Apr 20, 2024
C	Asuswrt-Merlin 3004.388.6 Memory Leak	Asuswrt-Merlin	13	Mar 24, 2024
	Beta Asuswrt-Merlin 3004.388.6_x test builds (dnsmasq 2.90)	Asuswrt-Merlin	102	Feb 15, 2024
	Release Asuswrt-Merlin 3004.388.6 is now available	Asuswrt-Merlin	767	Jan 20, 2024
	Beta Asuswrt-Merlin 3004.388.6 Beta is now available	Asuswrt-Merlin	279	Jan 5, 2024
	Release Asuswrt-Merlin 3004.388.5 is now available	Asuswrt-Merlin	260	Dec 2, 2023
	Beta Asuswrt-Merlin 3004.388.5-beta is now available	Asuswrt-Merlin	58	Nov 26, 2023
A	Solved Guest Network "Pro" for Asuswrt-Merlin 3004.388.x NOT SUPPORTED	Asuswrt-Merlin	5	Oct 28, 2023
B	Asuswrt-Merlin 3004.388.4_0 Rt-AX68U Link Aggregation	Asuswrt-Merlin	4	Sep 23, 2023

Beta Asuswrt-Merlin 3004.388.8 beta is now available

Asuswrt-Merlin dev

Regular Contributor

Regular Contributor

Asuswrt-Merlin dev

Regular Contributor

Asuswrt-Merlin dev

Occasional Visitor

Asuswrt-Merlin dev

Regular Contributor

Senior Member

Regular Contributor

Asuswrt-Merlin dev

Very Senior Member

Very Senior Member

New Around Here

Occasional Visitor

Very Senior Member

Similar threads

Similar threads

Support SNBForums w/ Amazon

Sign Up For SNBForums Daily Digest