YazFi YazFi and Routers with 6GHz band

[Martinski]

This past evening, I was talking with one of my cousins, and he mentioned that he wanted to upgrade his almost 5-year-old RT-AC86U router and was thinking about getting a tri-band, or perhaps a quad-band, ASUS router. His current RT-AC86U is still working fine, but his network needs have grown quite a bit since we first set it up: from about ~15 clients back then to almost 40 now - a mix of various IoT devices (smart thermostat, light bulbs, switches, watches, cameras, etc.), plus the usual assortment of smartphones, tablets & laptop PCs.

Some of his requirements are that the new router must run Asuswrt-Merlin F/W and the YazFi add-on (which is currently set up to isolate all his IoT devices on the 2.4GHz Guest Network). Also, he'd like to get a router that supports the 6GHz band, given that he's already got 3 smartphones & 2 laptops that are WiFi 6E capable, and more such devices are likely to come in the next few years.

AFAICT, currently there are only 2 choices that may meet his criteria: GT-AXE11000 (tri-band) & GT-AXE16000 (quad-band). However, it looks like there might be some issues with YazFi & the 6GHz band.

WRT the GT-AXE11000 router, I believe YazFi works fine *except* for the mislabeling of the "6GHz" Guest Network as "5GHz-2" on the WebGUI.

Could someone running YazFi on the GT-AXE11000 please confirm that this is indeed the case?

Based on my recent review of the YazFi code, there's nothing that prevents the 6GHz Guest Network from working. However, on the GT-AXE16000 router, the issue appears to be that the 2.4GHz Guest Network is no longer available for configuration (see this post here). This issue would be a deal-breaker, but I believe I can make the necessary code changes to fix the problem (and I'll have some time during the Christmas holidays). But, in order to do that I'd like to request the owner of a GT-AXE16000 router to send me the output of the following commands:

nvram get wl3_vifnames
nvram get rc_support

I'd appreciate someone's help in getting the requested information. Thanks.

 

[ugandy]

wl3.1 wl3.2 wl3.3 wl3.4 wl3.5

and

mssid 2.4G 5G update usbX2 switchctrl manual_stb 11AX pwrctrl WIFI_LOGO nandflash movistarTriple wifi2017 app ofdma wpa3 reboot_schedule ipv6 ipv6pt s46 PARENTAL2 dnsfilter am_addons cake ntpd dnspriv dualwan pptpd openvpnd utf8_ssid printer modem webdav rrsut cloudsync media appnet timemachine hdspindown diskutility nfsd dnssec email 5G-2 bwdpi wrs_wbl ookla snmp tor HTTPS letsencrypt ssh vpnc repeater psta wl6 wifi_tog_btn user_low_rssi wifiradar tcode usericon stainfo realip lacp wanbonding alexa ipsec_srv mumimo netool cfg_sync no_finiwl betaupg amas bcmwifi boostkey bcmhnd mbo conndiag eula proxysta iperf3 wifi6e account_binding gameMode owe_trans wireguard ftp_ssl acl96 dhdlog dis11b smart_connect smart_connect_v2

 

[Martinski]

wl3.1 wl3.2 wl3.3 wl3.4 wl3.5

and

mssid 2.4G 5G update usbX2 switchctrl manual_stb 11AX pwrctrl WIFI_LOGO nandflash movistarTriple wifi2017 app ofdma wpa3 reboot_schedule ipv6 ipv6pt s46 PARENTAL2 dnsfilter am_addons cake ntpd dnspriv dualwan pptpd openvpnd utf8_ssid printer modem webdav rrsut cloudsync media appnet timemachine hdspindown diskutility nfsd dnssec email 5G-2 bwdpi wrs_wbl ookla snmp tor HTTPS letsencrypt ssh vpnc repeater psta wl6 wifi_tog_btn user_low_rssi wifiradar tcode usericon stainfo realip lacp wanbonding alexa ipsec_srv mumimo netool cfg_sync no_finiwl betaupg amas bcmwifi boostkey bcmhnd mbo conndiag eula proxysta iperf3 wifi6e account_binding gameMode owe_trans wireguard ftp_ssl acl96 dhdlog dis11b smart_connect smart_connect_v2

Thanks again. I appreciate the fast reply.

 

[Martinski]

Since I got all the necessary info (thanks to @ugandy for the assist), and the new code was pretty much planned out & "written in my head" by now, I decided to start making the modifications in the YazFi sources.

The shell script was the simplest to do since it didn't have a lot of references to the Guest Network band "UI labels" (e.g. "2.4GHz" vs "5GHz" vs "5GHz-2"). The JavaScript is taking a bit longer but it's about 75% completed.

Here are screenshots of what the modified YazFi WebGUI would look like for a "Tri-Band" and a "Quad-Band" router that supports the 6GHz band, with each virtual interface mapping to the correct WiFi band "UI label."

I should be able to finish the rest of the changes and start a full round of testing Friday evening.

Just FYI.

 

[Jack Yaz]

Since I got all the necessary info (thanks to @ugandy for the assist), and the new code was pretty much planned out & "written in my head" by now, I decided to start making the modifications in the YazFi sources.

The shell script was the simplest to do since it didn't have a lot of references to the Guest Network band "UI labels" (e.g. "2.4GHz" vs "5GHz" vs "5GHz-2"). The JavaScript is taking a bit longer but it's about 75% completed.

Here are screenshots of what the modified YazFi WebGUI would look like for a "Tri-Band" and a "Quad-Band" router that supports the 6GHz band, with each virtual interface mapping to the correct WiFi band "UI label."

View attachment 46576


View attachment 46577

I should be able to finish the rest of the changes and start a full round of testing Friday evening.

Just FYI.

hopefully the JS isn't too bad, I tried to plumb in as much dynamic UI generation as I could!

 

[Martinski]

hopefully the JS isn't too bad, I tried to plumb in as much dynamic UI generation as I could!

Oh no, the JS code is not bad at all; I actually found it to be very organized, well structured & readable. The dynamic UI strings generation that you implemented has been vital in making the addition of new code and the modification of previous "old" code a fairly smooth process overall.

Most of the changes so far have been made in the function that parses the configuration file & dynamically generates the UI strings as it goes. I’m using object-oriented programming techniques to replace some of the hard-coded values within the UI generation and decouple the WiFi bands info & config file field names from that part of the code to make it easier to manage in the future (it's similar to what I did with the "DHCP" constant objects I created in my previous code changes that were merged into your develop branch).

Anyway, I’m having fun making these small contributions to your YazFi project. And I must give you full credit for creating this very useful tool. Also, I tip my hat to @RMerlin, and anyone else who helped, for creating the infrastructure & framework to be able to "plug in" these useful add-ons.

Happy Holidays to all.

 

[Martinski]

Well, I've finished making the changes in the JavaScript code and tested as much as I could on my RT-AC86U router. I also did exercise the sections of the new code dealing with the 6GHz band that's available in some tri-band (e.g. GT-AXE11000) & quad-band (e.g. GT-AXE16000) routers via unit testing/debugging code that simulates those conditions, but I don't have the actual hardware to run 100% true tests.

If anyone is interested in trying the modified YazFi files, here are the instructions:

1) Download 4 files from PasteBin with the following commands:

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/iQR8qBdz | tr -d '\r' > /jffs/scripts/Setup_YazFi_TEST.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/sErJC27s | tr -d '\r' > /jffs/scripts/YazFi.v4.4.3.MOD.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/d1RtW2wL | tr -d '\r' > /jffs/addons/YazFi.d/config.v4.4.3.ADD.txt
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/Bh3LTNKK | tr -d '\r' > /jffs/addons/YazFi.d/YazFi_www.asp.v4.4.3.MOD.ASP
chmod 755 /jffs/scripts/*.sh

2) Run the helper shell script without any arguments:

/jffs/scripts/Setup_YazFi_TEST.sh

The script will prompt you to make sure you want to set up YazFi with the modified files; if yes simply hit the ENTER key. The script will save current files, replace them with the new versions, and remount the YazFi webpage. Wait until the remount is fully completed, and then you can open up the YazFi webGUI tab.

Three final points:

- Before you start, I'd recommend saving a copy of your current configuration file "/jffs/addons/YazFi.d/config" so you have a backup.

- Do *not* change the names of the modified YazFi files that were downloaded because the helper script is looking for them with the exact names specified above with the curl commands.

- If you want to *restore* your previous YazFi files after you're done testing, simply run the helper script again, answer 'n' or 'N' for the 1st prompt, then answer 'y' or 'Y' for the 2nd prompt. Let the script remount the previous webpage, and YazFi should be back to its original state.

HTH.

 

[Jack Yaz]

Well, I've finished making the changes in the JavaScript code and tested as much as I could on my RT-AC86U router. I also did exercise the sections of the new code dealing with the 6GHz band that's available in some tri-band (e.g. GT-AXE11000) & quad-band (e.g. GT-AXE16000) routers via unit testing/debugging code that simulates those conditions, but I don't have the actual hardware to run 100% true tests.

If anyone is interested in trying the modified YazFi files, here are the instructions:

1) Download 4 files from PasteBin with the following commands:

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/iQR8qBdz | tr -d '\r' > /jffs/scripts/Setup_YazFi_TEST.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/sErJC27s | tr -d '\r' > /jffs/scripts/YazFi.v4.4.3.MOD.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/d1RtW2wL | tr -d '\r' > /jffs/addons/YazFi.d/config.v4.4.3.ADD.txt
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/Bh3LTNKK | tr -d '\r' > /jffs/addons/YazFi.d/YazFi_www.asp.v4.4.3.MOD.ASP
chmod 755 /jffs/scripts/*.sh

2) Run the helper shell script without any arguments:

/jffs/scripts/Setup_YazFi_TEST.sh

The script will prompt you to make sure you want to set up YazFi with the modified files; if yes simply hit the ENTER key. The script will save current files, replace them with the new versions, and remount the YazFi webpage. Wait until the remount is fully completed, and then you can open up the YazFi webGUI tab.

Three final points:

- Before you start, I'd recommend saving a copy of your current configuration file "/jffs/addons/YazFi.d/config" so you have a backup.

- Do *not* change the names of the modified YazFi files that were downloaded because the helper script is looking for them with the exact names specified above with the curl commands.

- If you want to *restore* your previous YazFi files after you're done testing, simply run the helper script again, answer 'n' or 'N' for the 1st prompt, then answer 'y' or 'Y' for the 2nd prompt. Let the script remount the previous webpage, and YazFi should be back to its original state.

HTH.

Equally we could throw this on the develop branch too

 

[Jack Yaz]

Oh no, the JS code is not bad at all; I actually found it to be very organized, well structured & readable. The dynamic UI strings generation that you implemented has been vital in making the addition of new code and the modification of previous "old" code a fairly smooth process overall.

Most of the changes so far have been made in the function that parses the configuration file & dynamically generates the UI strings as it goes. I’m using object-oriented programming techniques to replace some of the hard-coded values within the UI generation and decouple the WiFi bands info & config file field names from that part of the code to make it easier to manage in the future (it's similar to what I did with the "DHCP" constant objects I created in my previous code changes that were merged into your develop branch).

Anyway, I’m having fun making these small contributions to your YazFi project. And I must give you full credit for creating this very useful tool. Also, I tip my hat to @RMerlin, and anyone else who helped, for creating the infrastructure & framework to be able to "plug in" these useful add-ons.

Happy Holidays to all.

Nice one!

 

[Martinski]

Equally we could throw this on the develop branch too

Yes, I'm planning to submit a PR for these latest changes as well, but first I wanted to do another round of unit testing just to be sure I didn't break anything in the process and confirm that the new code is "titanium carbide" solid , or as solid as s/w can be.

Probably by Sunday evening since tomorrow (actually today, it's 24th already!) will be a busy day with family being at home all day, and more family coming over in the evening.

Enjoy your Christmas Holiday weekend!

 

[Jack Yaz]

Yes, I'm planning to submit a PR for these latest changes as well, but first I wanted to do another round of unit testing just to be sure I didn't break anything in the process and confirm that the new code is "titanium carbide" solid , or as solid as s/w can be.

Probably by Sunday evening since tomorrow (actually today, it's 24th already!) will be a busy day with family being at home all day, and more family coming over in the evening.

Enjoy your Christmas Holiday weekend!

i hope you enjoy your Christmas too!

 

[ugandy]

Well, I've finished making the changes in the JavaScript code and tested as much as I could on my RT-AC86U router. I also did exercise the sections of the new code dealing with the 6GHz band that's available in some tri-band (e.g. GT-AXE11000) & quad-band (e.g. GT-AXE16000) routers via unit testing/debugging code that simulates those conditions, but I don't have the actual hardware to run 100% true tests.

If anyone is interested in trying the modified YazFi files, here are the instructions:

1) Download 4 files from PasteBin with the following commands:

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/iQR8qBdz | tr -d '\r' > /jffs/scripts/Setup_YazFi_TEST.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/sErJC27s | tr -d '\r' > /jffs/scripts/YazFi.v4.4.3.MOD.sh
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/d1RtW2wL | tr -d '\r' > /jffs/addons/YazFi.d/config.v4.4.3.ADD.txt
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/Bh3LTNKK | tr -d '\r' > /jffs/addons/YazFi.d/YazFi_www.asp.v4.4.3.MOD.ASP
chmod 755 /jffs/scripts/*.sh

2) Run the helper shell script without any arguments:

/jffs/scripts/Setup_YazFi_TEST.sh

The script will prompt you to make sure you want to set up YazFi with the modified files; if yes simply hit the ENTER key. The script will save current files, replace them with the new versions, and remount the YazFi webpage. Wait until the remount is fully completed, and then you can open up the YazFi webGUI tab.

Three final points:

- Before you start, I'd recommend saving a copy of your current configuration file "/jffs/addons/YazFi.d/config" so you have a backup.

- Do *not* change the names of the modified YazFi files that were downloaded because the helper script is looking for them with the exact names specified above with the curl commands.

- If you want to *restore* your previous YazFi files after you're done testing, simply run the helper script again, answer 'n' or 'N' for the 1st prompt, then answer 'y' or 'Y' for the 2nd prompt. Let the script remount the previous webpage, and YazFi should be back to its original state.

HTH.

working great!

 

[Martinski]

working great!

Glad to know that it's working great for you.

BTW, if you happen to run AMTM to check for updates, you may see that YazFi has an "update notification" which is being triggered by the different MD5 hash signatures between the official YazFi "4.4.2" shell script version and the modified shell script from the "4.4.3_TEST" version that you're running now.

So if you see that, do *not* run the update from AMTM. The reason is that the newly-modified configuration file "/jffs/addons/YazFi.d/config" is *not* compatible with the current "4.4.2" release (or any previous versions) because of the new config variables ("wlXX_DHCPLEASE" and "wl3X_*") that have been introduced with my latest additions/modifications since 4.4.2.

As explained in my instructions (post #7 above), if you want to go back to your previous official YazFi version, simply run the "/jffs/scripts/Setup_YazFi_TEST.sh" helper script again, and select to *restore* the files when prompted.

 

[Martinski]

Equally we could throw this on the develop branch too

I finally had time to do another round of testing on Monday night; it went well and found nothing amiss, although, admittedly, it's limited testing since I don't have multiple router models to test with. OTOH, the good thing about writing & testing front-end presentation logic is that one can easily insert test/debug code to simulate the specific conditions that trigger different logic paths, and so I can exercise different branches of the execution flow without having the actual hardware available.

In any event, I've now submitted a PR for all my latest changes.

 

[Jeffrey Young]

It is really great seeing another forum member taking on maintainence of Jack's scripts. Good show @Martinski

 

[Viktor Jaep]

It is really great seeing another forum member taking on maintainence of Jack's scripts. Good show @Martinski

Agreed! Much appreciated, @Martinski!!

 

[ugandy]

i just noticed something strange.
i have one guest network #2 enabled using 192.16.3.xx
i have one guest network #3 enabled using 192.16.4.xx
they are both on 5GHz-1

all my clients that are not connected to the guest networks correctly get IPs on the 192.168.50.xx range
if they are on 2.4, 5-1 or 5-2 all is good, but my client on 6Ghz gets IP 192.168.4.xx

more to this:
my 6GHz client is connected and it is not a guest network.
on the wireless network map it''s reported as 192.168.50.239, but on the system wifi log is reported as 192.168.4.6
this is a windows PC and ipconfig reports 192.168.50.239, so the problem appears to be with the system log wifi page

 

[Martinski]

It is really great seeing another forum member taking on maintainence of Jack's scripts. Good show @Martinski

Agreed! Much appreciated, @Martinski!!

Thanks, I appreciate the thumbs-up & words of encouragement. But also, I’d like to set the proper expectations here & clarify that I haven’t really taken up the role of maintaining @Jack Yaz's add-on scripts (I’m barely scratching the surface with YazFi alone). It would certainly be interesting & fun to do, but at this point, due to my regular job responsibilities & the workloads that are normally expected during the s/w dev cycles of the projects I'm working on, plus family commitments, and two other personal hobbies of mine, my plate is rather full already, so I honestly don't have enough spare time to properly take the role of maintaining Jack’s add-ons and do them justice.

WRT YazFi, I certainly intend to continue and try to address any issues that I happen to find, or someone else might find & report on this forum, but I can do that only when/if time permits (which is usually not a lot) and on a best-effort basis.

Hope you understand.

 

[Martinski]

i just noticed something strange.
i have one guest network #2 enabled using 192.16.3.xx
i have one guest network #3 enabled using 192.16.4.xx
they are both on 5GHz-1

all my clients that are not connected to the guest networks correctly get IPs on the 192.168.50.xx range
if they are on 2.4, 5-1 or 5-2 all is good, but my client on 6Ghz gets IP 192.168.4.xx

more to this:
my 6GHz client is connected and it is not a guest network.
on the wireless network map it''s reported as 192.168.50.239, but on the system wifi log is reported as 192.168.4.6
this is a windows PC and ipconfig reports 192.168.50.239, so the problem appears to be with the system log wifi page

Have you checked the IP addresses reported in the "System Log - DHCP Leases" webGUI tab? I find this to be more reliable in terms of reporting a client device's assigned IP address.

If there's a discrepancy between the "DHCP Leases" and what's being reported by the "System Log - Wireless Log" webpage, the "DHCP Leases" page has been more accurate in my experience, at least with all the RT-AC86U & RT-AC68U routers I have access to.