What's new

YazFi YazFi - enhanced AsusWRT-Merlin Guest WiFi inc. SSID <-> VPN Client

  • 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!

Jack Yaz,

I am running an RT-AC3100 as the main router and an RT-AC68U as an AP.

I'm not sure if your script can support this setup? If it does; great!

If it doesn't; I'm willing to drop the RT-AC68U to test your v3.0 script out. Having it be 'amtm' compliant is a huge boost in usabilty. I've just recently started using amtm and I know I'm lost without it.

If you want feedback from a newbie, I'll do my best to help.
YazFi should run just fine on the router, but AP mode is not supported (I'm actually building checks into the installer for that as we speak!). You'll only be able to make use of clients connecting to Guest Networks on the main router,though. (If VLANs weren't such a nightmare in AsusWRT I would be willing to give AP support a go)
 
Any John's fork users: Please can you post the output of the below? Thanks!

Code:
nvram show | grep "buildno"
 
Any John's fork users: Please can you post the output of the below? Thanks!

Code:
nvram show | grep "buildno"
Always remains the same, for obvious reasons. Use $(nvram get buildno) for a test:
Code:
buildno=374.43
 
Always remains the same, for obvious reasons. Use $(nvram get buildno) for a test:
Code:
buildno=374.43
Thanks - I'm looking for a way to determine if the running f/w is newer than a certain version. I don't have a Fork-compatible device to test with :(
(it's only to show a helpful warning that a particular feature won't work)
 
Thanks - I'm looking for a way to determine if the running f/w is newer than a certain version. I don't have a Fork-compatible device to test with :(
(it's only to show a helpful warning that a particular feature won't work)
If you want to show the router model, use something like the following. The model is dependent on the SKU:
Code:
[ -z "$(nvram get odmpid)" ] && routerModel=$(nvram get productid) || routerModel=$(nvram get odmpid)

For the version test I have a function that I use for other comparisons, hence the four fields:
Code:
version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';}
It can then be used in a test such as:
Code:
[ "$(version_check $(nvram get buildno))" -lt "$(version_check '380.61')" ]
 
If you want to show the router model, use something like the following. The model is dependent on the SKU:
Code:
[ -z "$(nvram get odmpid)" ] && routerModel=$(nvram get productid) || routerModel=$(nvram get odmpid)

For the version test I have a function that I use for other comparisons, hence the four fields:
Code:
version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';}
It can then be used in a test such as:
Code:
[ "$(version_check $(nvram get buildno))" -lt "$(version_check '380.61')" ]
Cheers - that'll suit the Merlin builds nicely. I'm effectively trying to detect if service-event support is available on the installed firmware
 
That's perculiar indeed, that file would only be modified if there was a YazFi change (usually). When YazFi runs it builds a temporary config file and compares it to the existing - replacing the existing if there is anything different. Could you grab a syslog output from around the time it stops working please?

It may be linked to a scheduled reboot taking place. It happened last night and having looked at the syslog it's not come back up following a system reboot scheduled for 04:45. Comparing that reboot with a manual one the log is quite different - the manual one looks controlled whereas the scheduled one looks like it's being treated as unexpected:

Manual:
rc_service: httpds 331:notify_rc reboot​

Scheduled:
kernel: SysRq : Emergency Sync
kernel: Emergency Sync complete
kernel: IDPfw: Exit IDPfw
kernel: mod epilog takes 0 jiffies
kernel: IDPfw: Exit IDPfw​

When YazFi starts up it logs both the 2.4GHz and 5GHz SSIDs as "sending all interface internet traffic over WAN interface" but then, in the scheduled reboot, I see "YazFi: Lock file found (age: 26 seconds) - stopping to prevent duplicate runs".

I'm not sure how to send you the syslog files securely and I don't want to just attach them here.
 
Jack Yaz,

I am running an RT-AC3100 as the main router and an RT-AC68U as an AP.

I'm not sure if your script can support this setup? If it does; great!

If it doesn't; I'm willing to drop the RT-AC68U to test your v3.0 script out. Having it be 'amtm' compliant is a huge boost in usabilty. I've just recently started using amtm and I know I'm lost without it.

If you want feedback from a newbie, I'll do my best to help.
I tried to include you on the PM for testing, but it said I wasn't allowed to invite you :eek:
 
I tried to include you on the PM for testing, but it said I wasn't allowed to invite you :eek:

Jack Yaz, my apologies! I'll go check the settings right now. oops. :oops:


Edit: I hope I made the right change (accept conversations?). Please try again. Thank you.
 
Jack Yaz, I am off to work right now, but can't wait to get back home to try this. Thanks again!
 
Hey Jack Yaz, I have an RT-AX88U, that I am setting up to replace my AC3100, and would like to find out if your script will work with it?
 
I just ran an update of YazFi and noticed it installed v2.3.10 ???
Couldn't find any changelog for this version - bug fixes? or feature addition?
 
I just ran an update of YazFi and noticed it installed v2.3.10 ???
Couldn't find any changelog for this version - bug fixes? or feature addition?
Apologies - i appear to have neglected to post the update in here. It was a bugfix update (proper radio isolation)

I'll do a proper post when I get home from work.
 
Hey Jack Yaz, I have an RT-AX88U, that I am setting up to replace my AC3100, and would like to find out if your script will work with it?
I can't see why it wouldn't, but I think you'll be the first AX88u user, so let me know!
 
Apologies - i appear to have neglected to post the update in here. It was a bugfix update (proper radio isolation)

I'll do a proper post when I get home from work.

All good - REALLY enjoy your work on this guest WiFi adaptation - many thanks for your efforts :).
 
I can't see why it wouldn't, but I think you'll be the first AX88u user, so let me know!

Has anybody else tried it with V384.9 Final firmware, as I am getting repeating errors that I had to turn it off, and wanted to see if it is in relation to the firmware, or specific to the RT-AX88U.

I see that most people's firmware version in their signatures is 384.8_2.

What commands or error logs would you like to see for troubleshooting purposes?
 
Has anybody else tried it with V384.9 Final firmware, as I am getting repeating errors that I had to turn it off, and wanted to see if it is in relation to the firmware, or specific to the RT-AX88U.

I see that most people's firmware version in their signatures is 384.8_2.

What commands or error logs would you like to see for troubleshooting purposes?
I'm running 384.9 final on 86U without issue. What issues are you seeing?
 
All I'm trying to run is a Guest Wireless 2G connection of the RT-AX88U Router, no VPN, very basic. Here is what my system log continues to spam until I disable the guest wireless: PART 1 of 2 for CODE

Code:
Feb  7 13:18:33 rc_service: cfg_server 1318:notify_rc restart_wireless;restart_qos;restart_firewall;
Feb  7 13:18:33 custom_script: Running /jffs/scripts/service-event (args: restart wireless) - max timeout = 120s
Feb  7 13:18:34 YazFi: Wireless restarted - sleeping 30s before running YazFi
Feb  7 13:18:35 kernel: br0: port 6(eth6) entered STP off state
Feb  7 13:18:35 kernel: device eth6 left promiscuous mode
Feb  7 13:18:35 kernel: br0: port 6(eth6) entered STP off state
Feb  7 13:18:35 kernel: br0: port 7(eth7) entered STP off state
Feb  7 13:18:35 kernel: device eth7 left promiscuous mode
Feb  7 13:18:35 kernel: br0: port 7(eth7) entered STP off state
Feb  7 13:18:35 kernel: ubi1: attaching mtd9
Feb  7 13:18:35 kernel: ubi1: scanning is finished
Feb  7 13:18:35 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Feb  7 13:18:35 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Feb  7 13:18:35 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Feb  7 13:18:35 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Feb  7 13:18:35 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Feb  7 13:18:35 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Feb  7 13:18:35 kernel: ubi1: max/mean erase counter: 58/30, WL threshold: 4096, image sequence number: 1862459137
Feb  7 13:18:35 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Feb  7 13:18:35 kernel: ubi1: background thread "ubi_bgt1d" started, PID 9518
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 9535
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Feb  7 13:18:36 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID <REMOVED BY JS>, small LPT model
Feb  7 13:18:37 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Feb  7 13:18:37 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Feb  7 13:18:37 kernel: ubi1: detaching mtd9
Feb  7 13:18:37 kernel: ubi1: mtd9 is detached
Feb  7 13:18:38 kernel: ubi1: attaching mtd9
Feb  7 13:18:38 kernel: ubi1: scanning is finished
Feb  7 13:18:38 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Feb  7 13:18:38 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Feb  7 13:18:38 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Feb  7 13:18:38 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Feb  7 13:18:38 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Feb  7 13:18:38 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Feb  7 13:18:38 kernel: ubi1: max/mean erase counter: 58/30, WL threshold: 4096, image sequence number: 1862459137
Feb  7 13:18:38 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Feb  7 13:18:38 kernel: ubi1: background thread "ubi_bgt1d" started, PID 9594
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 9615
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID <REMOVED BY JS>, small LPT model
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Feb  7 13:18:39 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Feb  7 13:18:39 kernel: ubi1: detaching mtd9
Feb  7 13:18:39 kernel: ubi1: mtd9 is detached
 
Last edited:
Part 2 of 2 of CODE

Code:
Feb  7 13:18:47 BWDPI: fun bitmap = ff
Feb  7 13:18:47 A.QoS: qos_count=0, qos_check=0
Feb  7 13:18:50 custom_script: Running /jffs/scripts/service-event (args: restart firewall) - max timeout = 120s
Feb  7 13:18:50 miniupnpd[29125]: shutting down MiniUPnPd
Feb  7 13:18:50 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb  7 13:18:50 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Feb  7 13:18:50 miniupnpd[11663]: HTTP listening on port <REMOVED BY JS>,
Feb  7 13:18:50 miniupnpd[11663]: Listening for NAT-PMP/PCP traffic on port <REMOVED BY JS>
Feb  7 13:18:50 YazFi: Lock file found (age: 16 seconds) - stopping to prevent duplicate runs
Feb  7 13:18:50 adaptive QOS: Applying - Iptable Down Rules
Feb  7 13:18:51 adaptive QOS: Applying - Iptable Up   Rules (eth0)
Feb  7 13:18:51 adaptive QOS: TC Modification Delayed Start (5min)
Feb  7 13:19:04 YazFi: wl0.1 (SSID: guest2G) - sending all interface internet traffic over WAN interface
Feb  7 13:19:07 rc_service: service 16530:notify_rc restart_wireless
Feb  7 13:19:07 custom_script: Running /jffs/scripts/service-event (args: restart wireless) - max timeout = 120s
Feb  7 13:19:07 YazFi: YazFi v2.3.10 completed successfully
Feb  7 13:19:07 YazFi: Forcing YazFi Guest WiFi clients to reauthenticate
Feb  7 13:19:07 YazFi: Wireless restarted - sleeping 30s before running YazFi
Feb  7 13:19:09 kernel: br0: port 6(eth6) entered STP off state
Feb  7 13:19:09 kernel: device eth6 left promiscuous mode
Feb  7 13:19:09 kernel: br0: port 6(eth6) entered STP off state
Feb  7 13:19:09 kernel: br0: port 7(eth7) entered STP off state
Feb  7 13:19:09 kernel: device eth7 left promiscuous mode
Feb  7 13:19:09 kernel: br0: port 7(eth7) entered STP off state
Feb  7 13:19:09 avahi-daemon[1541]: Interface wl0.1.IPv4 no longer relevant for mDNS.
Feb  7 13:19:09 avahi-daemon[1541]: Leaving mDNS multicast group on interface wl0.1.IPv4 with address <REMOVED BY JS>.
Feb  7 13:19:09 kernel: br0: port 8(wl0.1) entered STP off state
Feb  7 13:19:09 avahi-daemon[1541]: Withdrawing address record for <REMOVED BY JS> on wl0.1.
Feb  7 13:19:09 kernel: device wl0.1 left promiscuous mode
Feb  7 13:19:09 kernel: br0: port 8(wl0.1) entered STP off state
Feb  7 13:19:09 kernel: ubi1: attaching mtd9
Feb  7 13:19:09 kernel: ubi1: scanning is finished
Feb  7 13:19:09 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Feb  7 13:19:09 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Feb  7 13:19:09 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Feb  7 13:19:09 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Feb  7 13:19:09 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Feb  7 13:19:09 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Feb  7 13:19:09 kernel: ubi1: max/mean erase counter: 58/30, WL threshold: 4096, image sequence number: 1862459137
Feb  7 13:19:09 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Feb  7 13:19:09 kernel: ubi1: background thread "ubi_bgt1d" started, PID 16635
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 16651
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID <REMOVED BY JS>, small LPT model
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Feb  7 13:19:10 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Feb  7 13:19:10 kernel: ubi1: detaching mtd9
Feb  7 13:19:10 kernel: ubi1: mtd9 is detached
Feb  7 13:19:11 kernel: ubi1: attaching mtd9
Feb  7 13:19:11 kernel: ubi1: scanning is finished
Feb  7 13:19:11 kernel: ubi1: attached mtd9 (name "misc1", size 8 MiB)
Feb  7 13:19:11 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Feb  7 13:19:11 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Feb  7 13:19:11 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Feb  7 13:19:11 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Feb  7 13:19:11 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Feb  7 13:19:11 kernel: ubi1: max/mean erase counter: 58/30, WL threshold: 4096, image sequence number: 1862459137
Feb  7 13:19:11 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Feb  7 13:19:11 kernel: ubi1: background thread "ubi_bgt1d" started, PID 16711
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 16727
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): reserved for root: 275879 bytes (269 KiB)
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID <REMOVED BY JS>, small LPT model
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Feb  7 13:19:12 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Feb  7 13:19:12 kernel: ubi1: detaching mtd9
Feb  7 13:19:12 kernel: ubi1: mtd9 is detached
Feb  7 13:19:14 kernel: device eth6 entered promiscuous mode
Feb  7 13:19:14 kernel: br0: port 6(eth6) entered listening state
Feb  7 13:19:14 kernel: br0: port 6(eth6) entered listening state
Feb  7 13:19:14 kernel: device eth7 entered promiscuous mode
Feb  7 13:19:14 kernel: br0: port 7(eth7) entered listening state
Feb  7 13:19:14 kernel: br0: port 7(eth7) entered listening state
Feb  7 13:19:14 avahi-daemon[1541]: Joining mDNS multicast group on interface wl0.1.IPv4 with address <REMOVED BY JS>.
Feb  7 13:19:14 avahi-daemon[1541]: New relevant interface wl0.1.IPv4 for mDNS.
Feb  7 13:19:14 avahi-daemon[1541]: Registering new address record for <REMOVED BY JS> on wl0.1.IPv4.
Feb  7 13:19:14 kernel: device wl0.1 entered promiscuous mode
Feb  7 13:19:14 kernel: br0: port 8(wl0.1) entered listening state
Feb  7 13:19:14 kernel: br0: port 8(wl0.1) entered listening state
Feb  7 13:19:14 adaptive QOS: Applying  TC Down Rules
Feb  7 13:19:15 adaptive QOS: Applying  TC Up   Rules
Feb  7 13:19:15 adaptive QOS: Modifying TC Class Rates
Feb  7 13:19:15 kernel: HTB: quantum of class 10010 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10011 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10014 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10016 is big. Consider r2q change.
Feb  7 13:19:15 kernel: HTB: quantum of class 10017 is big. Consider r2q change.
 

Similar threads

Latest 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