What's new

Beta Asuswrt-Merlin 386.2 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.
I'm still having problems - random devices seem to be having connectivity issues.

My house alarm just notified me that it's on cellular backup as it lost internet access, then came back online a minute or so later. It uses a wired ethernet connection to my RT-AX88U main router. Looking further I think there are DHCP issues which might explain why a full factory reset got me working again for a few hours.

The alarm system has an IP address which is NOT the reservation that's been entered in the DHCP server. I've double checked the MAC address and it's not shown in the list of DHCP leases on the System Log - DHCP Leases tab either as the current IP or the reserved IP. Furthermore, hitting the refresh button seems very slow to refresh, and my Ring devices seem to be renewing their leases every few minutes.

I might be seeing problems ahead of others as I use a 2 hour lease duration when in upgrade cycles so that devices refresh their network config frequently when I'm rebooting the router. I use YazDHCP although not sure if this will be the issue.

I was having all kinds of weird wifi connectivity issues with my brand new AX86U that I never had with the AC86U. Pretty much the same as what you are describing. I ended up disabling 802.11ax / Wi-Fi 6 mode and Target Wake Time on the 2.4 Ghz band and I think that has fixed it. I didn't even know that AX mode was applicable to 2.4 Ghz? Not sure if this will help you.
 
Pi-hole is acting as DHCP server in my LAN, not the router.
Yeah, that's fine. You can still use DNSFilter with Router mode as long as the LAN DNS Entries under DHCP are populated with your Pi-hole IP. Or use "Custom" for DNSFilter with the Pi-hole IP there. Both should work.

From what I've read and discussed with the Pi-hole team, the WAN entry should never be an internal DNS entry as you should only be pi-holing LAN requests.
 
Also, in log file I did see this for a few times:
Mar 12 00:16:42 firewall: apply rules error(4485)
 
You can still use DNSFilter with Router mode as long as the LAN DNS Entries under DHCP are populated with your Pi-hole IP. Or use "Custom" for DNSFilter with the Pi-hole IP there. Both should work.

I'll try that.

Thank you!!
 
Ok, a little bit more of struggling with things:
- tried to install/uninstall Skynet again - and no internet at all after that on clients. Restarting wan/rebooting is not helping anymore
- everytime I see "firewall: apply rules error" for multiple times in log
- found that always there are some lines related to YazFi around. Uninstalled YasZi - and internet returned immediately!
- installed SkyNet back - and internet didn't drop, and works just fine

I'll keep watching...
 
tl:dr

How is this implementation of Cake different than using ssh putty to install on e.g. 386.1_2?

Can it be customized too?
 
Last edited:
Last edited:
While using YazFi on guest 1 seems to work, all clients can connect, but once I forward there DNS to the VPN ,it’s a no go. They still have WAN IP
Once I move to guest-2 , there are no issues. They can access the VPN
Just letting you know
 
No, no luck - 5 mins and no internet again. And on every firewall service restart - this annoying "firewall: apply rules error(4485)". Any way to investigate what may cause this error?
 
I was having all kinds of weird wifi connectivity issues with my brand new AX86U that I never had with the AC86U. Pretty much the same as what you are describing. I ended up disabling 802.11ax / Wi-Fi 6 mode and Target Wake Time on the 2.4 Ghz band and I think that has fixed it. I didn't even know that AX mode was applicable to 2.4 Ghz? Not sure if this will help you.
Thanks, in my case my devices have always worked in AX mode and even some of my wired devices have been having issues with this beta. My wireless devices stay connected to WiFi, but they lose connectivity. There's definitely something strange going on, possibly due to something I do differently to most other people, but I'm struggling to narrow it down.
 
Ok, found in the firewall.c that on any error - it is storing the rule set that was applying. Here are files from /tmp/err_rules - in case if that may help
 

Attachments

  • filter_rules_1525496742.txt
    2.1 KB · Views: 153
  • filter_rules_1615502128.txt
    1.5 KB · Views: 142
While using YazFi on guest 1 seems to work, all clients can connect, but once I forward there DNS to the VPN ,it’s a no go. They still have WAN IP
Once I move to guest-2 , there are no issues. They can access the VPN
Just letting you know
Please clarify what you mean by forcing DNS to VPN and which DNS servers you are using?
 
agree and disagree. Yeah its nice to have people that can report everything the right way everytime. but , limiting users to use beta firmware is kinda not good imo. why? real example . on 386.1 and _2 (AC86U) i dont know why. my 2.4ghz radio is borked every few hours. the only thing that fixes it is restarting the radio. i've tried clean WPS reset install both times. and same thing... log doesnt show anything even on highest verbose setting. just some DHCP messages of it disconnecting and reconnecting.. then i went back to 384.19 and it all works fine...

now with this new GPL thats basically brand new, it seems to be fixed.. now i can use the latest firmware with latest security fixes without waiting for Stable Merlin or Asus... here's the thing, its not only because of i want to use the latest firmware, but its about security too. especially since 386 fixes some security issues.

if Merlin was to only publish beta to some users, i wont be able to check it out. and in turn, gonna expose myself to more security issues until Merlin's stable build came out or something like that.. so i think having an open beta is a good thing. even tho not all users usually report things the right way... since it can really help paint a picture on how a particular firmware is doing and well for bug fixes thats critical for some users..

OK I agree AND if that issue you are having was a REAL firmware issue then hundreds of AC86U's with the same firmware would be having exactly the same issue with their 2.4G connection. That clearly is not the case and therefore the issue must be isolated to your environment. Some of the things you could have tried are outlined by LL&D. eg using totally different SSID's -using the recommended settings in professional TAB etc etc. Sometimes these issues like you just confirmed can be "fixed" by flashing new firmware which overwrites areas of NVRAM that may have been the original cause of instability.
 
Ok, found in the firewall.c that on any error - it is storing the rule set that was applying. Here are files from /tmp/err_rules - in case if that may help
This looks wrong. The numbers should be your wan interface name. And there is no WAN interface in the second one after the -o.
Code:
-A FORWARD -o 57 161 165 ! -i br0 -j other2wan
Code:
-A FORWARD -o  ! -i br0 -j other2wan
What do you see if you run this command?
Code:
nvram show 2>/dev/null | grep -E "wan[01]_.*ifname"
 
I have observed the same. This log folder has one or more files (the number increase with time) and its size grows pretty quick compared with other databases (syslog, traffic, etc).

The content of the files has no too much relevant information (at least for me, e.g. lines as { "time": "1613288325", "event_name": "SYS", "node_type": "C", "node_ip": "192.168.1.1", "node_mac": "XX:XX:XX:XX:XX", "fw_ver": "3.0.0.4.386.1_2", "tcode": "EU\/01", "AiProtection": "1", "usb_mode": "1", "acceleration": "0,0" }).

From time to time, I delete the files in this folder through ssh. It seems that it does not produce any harm, but any advice about its nature is welcomed.
Yes. Same. I just removed mine. Is it gonna be fixed or do we need to make a nightly cron to remove em?? I hope it'll be fixed haha.
 
OK I agree AND if that issue you are having was a REAL firmware issue then hundreds of AC86U's with the same firmware would be having exactly the same issue with their 2.4G connection. That clearly is not the case and therefore the issue must be isolated to your environment. Some of the things you could have tried are outlined by LL&D. eg using totally different SSID's -using the recommended settings in professional TAB etc etc. Sometimes these issues like you just confirmed can be "fixed" by flashing new firmware which overwrites areas of NVRAM that may have been the original cause of instability.
Yeah I've done exactly everything that's been recommended lol. I even flashed from 386.1 to 386.1_2 . I tried wps reset. Tried factory reset again from web ui. And well still same thing happens. And remember. This didn't happen on 384.19. and since i rolled back to 384.19 it stopped. and as I suspected, it doesn't happen on the new GPL. So it's something there that interacts with my environment setting or something that made it like that... and remember, i didn't change anything from the advanced wireless settings (just when I tried those suggestions to fix em)

Regarding AC86U I've had some reboots in the past on 384.19 but not on 384.18 . I even RMA my router since i thought it was my 2018 unit failing. But nope. Still rebooting every few days without anything in the logs. It turns out. It was Aiprotection. It just made my router reboot every few days. I disabled mine and now it's going weeks without reboot.. so yeah and in this case I don't see anyone having this issue. Only some has problems with random rebooting. So it is a firmware/software issue with my environment.


It only happening on my environment doesn't make it a NOT REAL firmware issue...
 
A simple example of customizing Cake on Merlin is to use the /jffs/configs/cake-qos.conf.add file. If I want to add the ack-filter option to my upload options, but I don't want to replace the existing firmware-generated options, I can use this syntax:
Code:
ULOPTIONS="$ULOPTIONS ack-filter"
This sets the predefined ULOPTIONS variable to itself, then tacks on my ack-filter option. The double-quotes are needed (instead of single-quotes) so that the $ULOPTIONS variable is expanded.

If I wanted to completely replace the ULOPTIONS generated by the firmware, I would use this syntax without including the variable name within the double-quotes:
Code:
ULOPTIONS="nat triple-isolate wash ack-filter"
The original variable contents are ignored and replaced with my updated variable when qos is started.
Code:
# tc qdisc | grep cake
qdisc cake 8006: dev eth0 root refcnt 2 bandwidth 24576Kbit diffserv3 dual-srchost nat nowash ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
qdisc cake 8007: dev ifb4eth0 root refcnt 2 bandwidth 215040Kbit besteffort dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
I've also added iptables rules for Teams and Zoom to ensure that it takes advantage of the Voice tin in diffserv3 on upload.
This is the contents of my /jffs/scripts/qos-start script. I have IPv6 enabled, so the last 4 lines aren't needed if you do not have IPv6 enabled.
Code:
#!/bin/sh

iptables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF 2>/dev/null
iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF
iptables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF 2>/dev/null
iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF

ip6tables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF 2>/dev/null
ip6tables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF
ip6tables -t mangle -D POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF 2>/dev/null
ip6tables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 8001:8010 -j DSCP --set-dscp-class EF
 
Last edited:
Ok, found in the firewall.c that on any error - it is storing the rule set that was applying. Here are files from /tmp/err_rules - in case if that may help
Looks like there's something broke in the rule generation for '-j other2wan' rules

In the first file
-A FORWARD -o ! -i br0 -j other2wan (there is no output interface specified)

In the second file
-A FORWARD -o 57 161 165 ! -i br0 -j other2wan (looks like maybe a malformed attempt at an address for the output interface?)
 
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