What's new

Beta Asuswrt-Merlin 3004.388.8 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.
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".
 
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
 
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
 
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.

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.
 
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).
 
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 😀
 
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?
 
Last edited:
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.
 
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!
 
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....
 
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. 👍
 
One week on the clock and nothing to complain about :cool:
Thanks @RMerlin
 
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?
 
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.
 
Two days running on AX88U - dirty update - with no issues! 👍
 
I get IPV6 from my ISP, Can I create static definitions using IPV6 ?
 
Since upgrading to beta, Tahoma (Somfy) app / hub fails to connect, randomly disconnects every other day. Never had this issue with any other versions before this beta.
 

Attachments

  • signal-2024-07-02-122552_002.jpeg
    signal-2024-07-02-122552_002.jpeg
    21.4 KB · Views: 70
Since upgrading to beta, Tahoma (Somfy) app / hub fails to connect, randomly disconnects every other day. Never had this issue with any other versions before this beta.
Zero SDK/driver/Wifi changes in this update.
 
Status
Not open for further replies.

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top