YazFi YazFi v4.x

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Jack Yaz

Part of the Furniture
v4.3.4
Updated 2021-08-04


Feature expansion of guest WiFi networks on AsusWRT-Merlin, including, but not limited to:

* Dedicated VPN WiFi networks
* Separate subnets for organisation of devices
* Restrict guests to only contact router for ICMP, DHCP, DNS, NTP and NetBIOS
* Allow guest networks to make use of pixelserv-tls (if installed)
* Allow guests to use a local DNS server
* Extend DNS Filter to guest networks

This project is hosted on GitHub

YazFi is free to use under the GNU General Public License version 3 (GPL 3.0).

Love the script and want to support future development? Any and all donations gratefully received!
PayPal donation
Buy me a coffee

Supported firmware versions
Core YazFi features
You must be running firmware no older than:
WebUI page for YazFi
You must be running firmware no older than:

Installation
Using your preferred SSH client/terminal, copy and paste the following command, then press Enter:
Code:
/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/jackyaz/YazFi/master/YazFi.sh" -o "/jffs/scripts/YazFi" && chmod 0755 /jffs/scripts/YazFi && /jffs/scripts/YazFi install

Please then follow instructions shown on-screen. An explanation of the settings is provided in the FAQs in post #2

Usage
WebUI
YazFi can be configured via the WebUI, in the Guest Network section.

Command Line
To launch the YazFi menu after installation, use:
Code:
YazFi

If you do not have Entware installed, you will need to use the full path:
Code:
/jffs/scripts/YazFi
 
Last edited:

Jack Yaz

Part of the Furniture
Screenshots
 

Jack Yaz

Part of the Furniture
v4.2.0 is now available
Changelog:

  • NEW: Check for updates in WebUI
  • NEW: DoT DNSFilter rules for YazFi guests
  • FIXED: Restarting VPN clients would lose YazFi routing rules
  • FIXED: Force Asus own "LAN access" to enabled (prevent 386.x creating VLANs and breaking things - "protocol is buggy"). YazFi applies its own firewall rules to prevent LAN access.
  • IMPROVED: Use of quotes throughout script, code improvements in general
  • IMPROVED: Status command will no longer hang when arp is slow
  • CHANGED: Config validation will now continue if an interface fails validation, rather than exiting and applying no configuration
 

cptnoblivious

Regular Contributor
Easy update to 4.2.0, quick question: Is the DoT filtering part of the 'Force DNS' setting? I looked but can't find another place to set this :)

Thanks!
 

juched

Senior Member
Curious about the force client isolation to false. On my AX88U I can change the NVRAM settings and they stick now. I believe this feature can be used with those devices. Can you share what issues were seen?

I also have AX58U (AX3000) devices as AiMesh nodes, which I also see in that force command.

Thanks.
 

Jack Yaz

Part of the Furniture
Curious about the force client isolation to false. On my AX88U I can change the NVRAM settings and they stick now. I believe this feature can be used with those devices. Can you share what issues were seen?

I also have AX58U (AX3000) devices as AiMesh nodes, which I also see in that force command.

Thanks.
On 384.x (I forget which), the nvram setting would not stick for client isolation and revert to 0 whenever wireless was restarted. This meant YazFi would forever restart wireless as the nvram value would never match the configuration YazFi expected to set. Which f/w are you running? It may now be fixed in 386, if so I can add a check.
 

juched

Senior Member
On 384.x (I forget which), the nvram setting would not stick for client isolation and revert to 0 whenever wireless was restarted. This meant YazFi would forever restart wireless as the nvram value would never match the configuration YazFi expected to set. Which f/w are you running? It may now be fixed in 386, if so I can add a check.

It has been working since the 386 betas of merlin. Currently on 386.1_2, but it worked on 386.1 as well. By working I mean I can change the nvram setting and it sticks. I did see it flip back with 384 as we had discussed before.

what is interesting on the Asus Guest Wifi config, whatever rules they configure allows the regular network to ping the devices on the guest network, but not the other way around.
 

bulletdodger

New Around Here
Hi,
Long time lurker, first time poster. First off, thanks a lot for your development. I have a RT-AC86u that I updated with Merlin 386.1-2 yesterday and I also updated to YazFi version v4.2.0 soon thereafter. I reset the router, formatted the JFFS three times, and reconfigured. With YazFi installed, the <Access Intranet> flag on the WebUI Guest Networks tab was forced to Enabled and every time I tried to set it to Disabled, it would revert to Enabled for both of the Guest Networks I had configured. I confirmed with a client that was connected to one of the Guest networks that it could indeed access other clients on my intranet.

I uninstalled YazFi and now the Access Intranet flag is no longer persistent and I can disable intranet access for Guest Networks. I will continue to try other things and perhaps install YazFi again from scratch but wanted to alert everyone in case others are seeing this, or if I am missing something obvious.
 

Jack Yaz

Part of the Furniture
Hi,
Long time lurker, first time poster. First off, thanks a lot for your development. I have a RT-AC86u that I updated with Merlin 386.1-2 yesterday and I also updated to YazFi version v4.2.0 soon thereafter. I reset the router, formatted the JFFS three times, and reconfigured. With YazFi installed, the <Access Intranet> flag on the WebUI Guest Networks tab was forced to Enabled and every time I tried to set it to Disabled, it would revert to Enabled for both of the Guest Networks I had configured. I confirmed with a client that was connected to one of the Guest networks that it could indeed access other clients on my intranet.

I uninstalled YazFi and now the Access Intranet flag is no longer persistent and I can disable intranet access for Guest Networks. I will continue to try other things and perhaps install YazFi again from scratch but wanted to alert everyone in case others are seeing this, or if I am missing something obvious.
Literally in the changelog a few posts up:
FIXED: Force Asus own "LAN access" to enabled (prevent 386.x creating VLANs and breaking things - "protocol is buggy"). YazFi applies its own firewall rules to prevent LAN access.

Make sure you disable one way and one two access in YazFi if you want to disable LAN access
 

bulletdodger

New Around Here
Literally in the changelog a few posts up:
FIXED: Force Asus own "LAN access" to enabled (prevent 386.x creating VLANs and breaking things - "protocol is buggy"). YazFi applies its own firewall rules to prevent LAN access.

Make sure you disable one way and one two access in YazFi if you want to disable LAN access
Thank you--that worked. Yazfi back installed and enabled.

I also experimented with the "Sync to AiMesh Node" flag set to "All" (I have two aiMesh nodes). This was before I read the other thread (Yazfi and AiMesh 2.0 - https://www.snbforums.com/threads/yazfi-and-aimesh-2-0.69102/), which talks more about this. I'll disable that for now. Thanks.
 

Jack Yaz

Part of the Furniture
Thank you--that worked. Yazfi back installed and enabled.

I also experimented with the "Sync to AiMesh Node" flag set to "All" (I have two aiMesh nodes). This was before I read the other thread (Yazfi and AiMesh 2.0 - https://www.snbforums.com/threads/yazfi-and-aimesh-2-0.69102/), which talks more about this. I'll disable that for now. Thanks.
No worries.

It's something I hope to be able to support but there's too many issues at the moment
 

New2This

Senior Member
Thanks for the update, wondering, if Im running Unbound, would the guest still be able to access DoT?
if so, what would I have to do?
 

JJohnson1988

Occasional Visitor
Is there a way to have YazFi respect both the manual disabling of the wireless radios (i.e. the command: radio off) as well as the built-in wireless off-time scheduler?

Both some cron jobs I made as well as the built-in scheduler worked great at router bootup during off-time hours; they disabled the wireless radios on both bands correctly. But then moments later, YazFi forces the radios back on to apply its settings but then doesn't re-disable them when finished, thus causing quite a headache. I tried looking for an event I could listen to, to solve the issue on my own, but I couldn't find anything relevant.

YazFi might also run again when changing various router settings, also forcing the scheduled-down radios to be enabled even after the boot phase.

I've tried making a sh script that YazFi can execute, but the execution doesn't happen late enough for anything to be effectively disabled.

Apologies if I should have made a dedicated thread for this.

Update: I've implemented a temporary solution that should prevent YazFi from doing its thing until the radios are back on, at least on router bootup. I don't know if it's a good idea to keep the script locked in a loop for 8 hours at the most, but I guess I'll find out.

Bash:
Config_Networks(){
        if [ $(wl isup) = "0" ]; then logger "Radios are down! YazFi will wait until uptime..."; fi

        radio_timeout=0
        while [ $(wl isup) = "0" ] && [ $radio_timeout -lt 28800 ]; do
                radio_timeout=$((radio_timeout + 60))
                sleep 60
        done
        
        ...
 
Last edited:

SubNoize

New Around Here
My GN1 clients aren't being assigned their own subnet. When I check the IP's they're given they all have 192.168.1.xxx when YazFi should be chucking them on 192.168.2.x and 192.168.5.x

The Guest network predates the YazFi installation, does it need to be created after Yaz is installed?
 
Last edited:

bennor

Senior Member
My GN1 clients aren't being assigned their own subnet. When I check the IP's they're given they all have 192.168.1.xxx when YazFi should be chucking them on 192.168.2.x and 192.168.5.x
Where are you checking for the Guest Network IP address assignments? On the Network Map, on the Wireless Log, on the Guest WiFi client itself, through the YazFi command line interface, or via some other method?

For new YazFi users who don't know, use the System Log > Wireless Log and not the Network Map to see the correct IP address assignments given out by YazFi to Guest Network clients.
 

Markster

Senior Member
Is YazFi creating 2 additional bridges br1 and br2 on rt86U? Just wanted to verify if this may be the case. Cannot confirm since I did not run ifconfig or examined /etc/dnsmasq.conf before installing.

I see 2 bridges on my rt86u (386.1_2) and additional dhcp config

interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1
 

Jack Yaz

Part of the Furniture
Is YazFi creating 2 additional bridges br1 and br2 on rt86U? Just wanted to verify if this may be the case. Cannot confirm since I did not run ifconfig or examined /etc/dnsmasq.conf before installing.

I see 2 bridges on my rt86u (386.1_2) and additional dhcp config

interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1
no, that's 386.x firmware for guest 1 on 2.4 and 5ghz
 

Sign Up For SNBForums Daily Digest

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