YazFi YazFi & vlan isolation issue

[PavelAnd]

Hello,

I have encountered guest Wi-Fi connection issues when trying to use YazFi in combination with custom scripts for VLAN creation on RT-AC86U: the Wi-Fi devices (phone and laptop) connect for a short time (8 seconds max) to the guest network and are disconnected; they appear for a short time in the Connected guests list, but on the device themselves they do not appear as having established a successful connection. On the main networks there is no problem, and the devices are in close proximity to the router (1-2 meters max, open air).

The vlan configuration scripts were modified from the ones presented here: RT-86U - vlanctl & ethctl usage puzzle

---

Environment:
HW : RT-AC86U ; SW: Asuswrt-Merlin 386.5_2; Yaz-Fi 4.4.2

Yaz-Fi network config: See attached YazFi_GuiCFG photo.

Modified scripts:

Spoiler: /jffs/scripts/services-start

#!/bin/sh

/jffs/scripts/YazFi startup & # YazFi
/jffs/scripts/scmerlin startup & # scMerlin
sleep 30s
/jffs/scripts/vlan-isol-final & # setup vlan ctl rules
/jffs/scripts/fw-vlan-isol-final & # setup vlan ipconfig rules

Spoiler: /jffs/scripts/vlan-isol-final

#!/bin/sh

# Physical port to interface map for RT-AC86U:
# eth0 WAN
# eth1 LAN 4
# eth2 LAN 3
# eth3 LAN 2
# eth4 LAN 1
# eth5 2.4 GHz Radio
# eth6 5 GHz Radio

logger -t "vlan-isol" "Entered vlan-isol"

brctl delif br0 eth4
brctl delif br0 eth3

# management network
vlanctl --mcast --if-create eth4 1
vlanctl --if eth4 --rx --tags 1 --filter-vid 1 0 --pop-tag --set-rxif eth4.v1 --rule-append
vlanctl --if eth4 --tx --tags 0 --filter-txif eth4.v1 --push-tag --set-vid 1 0 --rule-append
ifconfig eth4.v1 up

# home network vlan
vlanctl --mcast --if-create eth4 10
vlanctl --if eth4 --rx --tags 1 --filter-vid 10 0 --pop-tag --set-rxif eth4.v10 --rule-append
vlanctl --if eth4 --tx --tags 0 --filter-txif eth4.v10 --push-tag --set-vid 10 0 --rule-append
ifconfig eth4.v10 up

# work network vlan
vlanctl --mcast --if-create eth4 20
vlanctl --if eth4 --rx --tags 1 --filter-vid 20 0 --pop-tag --set-rxif eth4.v20 --rule-append
vlanctl --if eth4 --tx --tags 0 --filter-txif eth4.v20 --push-tag --set-vid 20 0 --rule-append
ifconfig eth4.v20 up

vlanctl --if eth4 --set-if-mode-rg
vlanctl --if eth4 --tx --tags 0 --default-miss-drop


brctl addif br0 eth4.v1
brctl addbr br10
brctl addif br10 eth4.v10
brctl addbr br20
brctl addif br20 eth4.v20
brctl addbr br100
brctl stp br100 on
brctl addif br100 eth3
brctl setfd br100 2

ifconfig br10 192.168.10.1 netmask 255.255.255.0 up
ifconfig br20 192.168.20.1 netmask 255.255.255.0 up
ifconfig br100 192.168.100.1 netmask 255.255.255.0 up

nvram set lan_ifnames="eth1 eth2 eth4.v1 eth5 eth6"
nvram set br0_ifnames="eth1 eth2 eth4.v1 eth5 eth6"
nvram set br10_ifname=br10
nvram set br10_ifnames="eth4.v10"
nvram set lan1_ifname=br10
nvram set lan1_ifnames="eth4.v10"
nvram set br20_ifname=br20
nvram set br20_ifnames="eth4.v20"
nvram set lan2_ifname=br20
nvram set lan2_ifnames="eth4.v20"
nvram set br100_ifname=br100
nvram set br100_ifnames="eth3"
nvram set lan3_ifname=br100
nvram set lan3_ifnames="eth3"
nvram commit

killall eapd
eapd

ethswctl -c hw-switching -o disable
logger -t "vlan-isol" "Exited vlan-isol"

Spoiler: /jffs/scripts/fw-vlan-isol-final

#!/bin/sh

# Make sure the script is indeed invoked
logger -t "br10" "firewall-start: applying fw rules for br10"

# limit br10 to wan access

iptables -I INPUT -i br10 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br10 -o ppp0 -j ACCEPT
iptables -I FORWARD -i br10 -o br10 -j ACCEPT
iptables -t nat -I POSTROUTING -o br10 -j MASQUERADE

# Make sure the script is indeed invoked
logger -t "br20" "firewall-start: applying fw rules for br20"

# limit br20 to wan access
iptables -I INPUT -i br20 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br20 -o ppp0 -j ACCEPT
iptables -I FORWARD -i br20 -o br20 -j ACCEPT
iptables -t nat -I POSTROUTING -o br20 -j MASQUERADE

# Make sure the script is indeed invoked
logger -t "br100" "firewall-start: applying fw rules for br100"

# limit br100 to wan access
iptables -I INPUT -i br100 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i br100 -o ppp0 -j ACCEPT
iptables -I FORWARD -i br100 -o br100 -j ACCEPT
iptables -t nat -I POSTROUTING -o br100 -j MASQUERADE

service restart_dnsmasq

Spoiler: /jffs/configs/dnsmasq.conf.add

interface=br10
dhcp-range=br10,192.168.10.10,192.168.10.254,255.255.255.0,24h
dhcp-option=br10,3,192.168.10.1

interface=br20
dhcp-range=br20,192.168.20.10,192.168.20.254,255.255.255.0,24h
dhcp-option=br20,3,192.168.20.1

interface=br100
dhcp-range=br100,192.168.100.10,192.168.100.254,255.255.255.0,24h
dhcp-option=br100,3,192.168.100.1

Bridges configuration:

username@RT-AC86U-2698:/tmp/home/root# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.244bfebd2698       yes             eth1
                                                        eth2
                                                        eth4.v1
                                                        eth5
                                                        eth6
                                                        wl0.2
                                                        wl1.2
br10            8000.244bfebd2698       no              eth4.v10
br100           8000.244bfebd2698       yes             eth3
br20            8000.244bfebd2698       no              eth4.v20

Wireless log snippet:

Aug 21 22:56:58 RT-AC86U-2698 wlceventd: wlceventd_proc_event(527): wl0.2: Auth AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 22:56:58 RT-AC86U-2698 wlceventd: wlceventd_proc_event(556): wl0.2: Assoc AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 22:57:06 RT-AC86U-2698 wlceventd: wlceventd_proc_event(491): wl0.2: Deauth_ind AC:57:75:10:EA:CB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-43
Aug 21 22:59:47 RT-AC86U-2698 wlceventd: wlceventd_proc_event(527): wl0.2: Auth AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 22:59:47 RT-AC86U-2698 wlceventd: wlceventd_proc_event(556): wl0.2: Assoc AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 22:59:56 RT-AC86U-2698 wlceventd: wlceventd_proc_event(491): wl0.2: Deauth_ind AC:57:75:10:EA:CB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-48
Aug 21 22:59:59 RT-AC86U-2698 wlceventd: wlceventd_proc_event(527): wl0.2: Auth AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 22:59:59 RT-AC86U-2698 wlceventd: wlceventd_proc_event(556): wl0.2: Assoc AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 23:00:07 RT-AC86U-2698 wlceventd: wlceventd_proc_event(491): wl0.2: Deauth_ind AC:57:75:10:EA:CB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-46
Aug 21 23:00:17 RT-AC86U-2698 wlceventd: wlceventd_proc_event(527): wl0.2: Auth AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 23:00:17 RT-AC86U-2698 wlceventd: wlceventd_proc_event(556): wl0.2: Assoc AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 23:00:25 RT-AC86U-2698 wlceventd: wlceventd_proc_event(491): wl0.2: Deauth_ind AC:57:75:10:EA:CB, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-43
Aug 21 23:00:31 RT-AC86U-2698 wlceventd: wlceventd_proc_event(527): wl0.2: Auth AC:57:75:10:EA:CB, status: Successful (0), rssi:0
Aug 21 23:00:31 RT-AC86U-2698 wlceventd: wlceventd_proc_event(556): wl0.2: Assoc AC:57:75:10:EA:CB, status: Successful (0), rssi:0

 

[ZebMcKayhan]

The vlan configuration scripts were modified from the ones presented here: RT-86U - vlanctl & ethctl usage puzzle

The author suggested to use ip link instead of the more complicated vlanctl
https://www.snbforums.com/threads/rt-86u-vlanctl-ethctl-usage-puzzle.54375/post-652666

Don't know if it would make any difference for you though.

 

[eibgrad]

Ugg, this is why I'm NOT a fan of trying to force user-defined VLANs on routers that don't support it natively. To make matters worse, it's multiple hacks, each trying to reconfigure the underlying network interfaces, both of which are unknown to the firmware. And who knows where the conflicts might arise.

On the face of it, they would seem to function independently, but you just never know. YazFi is a pretty complicated piece of machinery under that nice GUI. I'd hate to have to dig through the code to find any conflicts.

Did you try simply changing the order of execution so YazFi was executed last? You then wouldn't need the sleep command either (which who knows, perhaps that itself might cause problems) since it's there based on the assumption those operations might NOT have completed by the time YOU need access.

 

[Yota]

I've used VLANs on non-HND models once, and back then VLANs were pretty simple to configure and rarely went wrong, but there were always weird bugs when working with guest networks.

I recommend that you first debug your VLAN configuration without the YazFi script, because as @eibgrad said, YazFi only adds to the complexity of the problem.

In addition, a suggestion, restart the wireless service before running eapd, because on non-HND models, the VLAN of the guest network always fail to complete WPA handshake, I initially suspected that the problem was caused by eapd, but restarting the wireless solved it.

 

[PavelAnd]

It seems that after configuring the guest networks I forgot to add their respective interfaces to the bridge when writing the NVRAM entries in the VLAN scripts.

The current setup is a combination of the edit mentioned above and a wireless_restart command (Thanks @Yota); it seems to be working after a cmdline issued reboot and power button reboot (1 min wait).

@eibgrad , the sleep command's purpose was indeed that, to make sure it did not interfere with the add-ons. I have tried to changed the order of execution, but that would be lost when the router is switched off and on manually from what I have seen; this results in the commands coming from add-ons being added to the end of the user written ones.

 

[Yota]

it seems to be working

You're welcome, glad it's working for you now, you can post the scripts and configs you successfully got it working so that it can be a direct reference for someone in the future who wants to achieve the same.

 

[Jeffrey Young]

Since you are adding firewall/NAT rules, don't forget to write firewall-start and nat-start scripts to handle those occasions that ASUS decides to restart the firewall as a firewall restart will wipe out your rules. A simple -D, then -I of each rule would do it..

Also, like you, I have a AC86U in AP mode with custom VLANS setup to act as my AP to my Ubuntu RasPi 4 router. Not ideal as @eibgrad has pointed out. However, for me, a good Unifi AP runs about 200 bucks in my neck of the woods and the AC86U is worth about the same. Could not justify simply putting the AC86U on the self and spend another 200 bucks in a Unifi AP. The AC86U is more than capable of doing the work, it is just the unknowns of what Asus is doing from time to time under the hood that can bite you.

That said, I found that when Asus just up and restarts the wireless or network services (and who knows what else), my network settings in in the services-start were wiped out and reset to the standard AP settings with one 2.4G guest enabled. I had to make a service-event script that checked for the existence of my VLANS and Bridges on completion of any event and set them up again if the network was reset.

Cheers

 

[Jeffrey Young]

Also, another thought. YazFi is a fine piece of work and I used it on my AC86U (still do actually, I have delayed my RasPi router plans until after a family crisis has passed as I will be away from home a bit until the crisis is over). But at the end of the day, all YazFi is doing is tearing down any ebtable rules and performing all the magic with iptables and dnsmasq additions. To keep the benefit of YazFi (unless you want the GUI stuff), study what changes Jack made to the system, dump YazFi to avoid any interference and script your own stuff. If you are up to it, that is.

 

[eibgrad]

It seems that after configuring the guest networks I forgot to add their respective interfaces to the bridge when writing the NVRAM entries in the VLAN scripts.

Since you didn't post the changes, I have to mention.

Beware that YazFi works by removing the guest networks from their respective bridges. It then creates firewall rules based on the "raw" network interfaces (e.g., wl0.2 and wl1.2). You can't then add those network interfaces back to a bridge an expect those firewall rules to continue working! And don't be fooled by the fact that brctl shows them still bound to the default bridge (br0). YazFi uses other means to remove them, and which are NOT reflected in brctl.

That's why I'm NOT all that comfortable w/ mixing your own VLANs and something as complex as YazFi. As I said, there's a lot going on there w/ YazFi, and unless you examine it closely, you may break it, your script, or both.

 

[PavelAnd]

@eibgrad
I didn't know that YazFi removed somehow the guest networks from the bridge, as I didn't see any brctl or nvram set usage regarding the wireless guest interfaces in his script like the ones used for configuring VLANs. I will try to investigate further down the line.

Regarding the script changes (marked with red), they are fairly minimal:

Spoiler: /jffs/scripts/fw-vlan-isol-final changes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nvram set lan_ifnames="eth1 eth2 eth4.v1 eth5 eth6 wl0.2 wl1.2"
nvram set br0_ifnames="eth1 eth2 eth4.v1 eth5 eth6 wl0.1 wl1.2"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

killall eapd
service restart_wireless
eapd

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jeffrey Young]

@eibgrad
I didn't know that YazFi removed somehow the guest networks from the bridge, as I didn't see any brctl or nvram set usage regarding the wireless guest interfaces in his script like the ones used for configuring VLANs. I will try to investigate further down the line.

Regarding the script changes (marked with red), they are fairly minimal:

Spoiler: /jffs/scripts/fw-vlan-isol-final changes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nvram set lan_ifnames="eth1 eth2 eth4.v1 eth5 eth6 wl0.2 wl1.2"
nvram set br0_ifnames="eth1 eth2 eth4.v1 eth5 eth6 wl0.1 wl1.2"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

killall eapd
service restart_wireless
eapd

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Every router model handles the guest network differently. In order to standardize his script, Jack dismantles the guest network (that Asus builds), rather the guest network was being setup by Asus as a separate bridge and /or through ebtables, and then Jack uses iptables/different subnets/dnsmasq to maintain separation, setup paths, etc. I have never dove into his script deep as I did not have too. I did, however, study the iptables after Jack was finished with his setup to see what did and learn from him. I actually used Jack's template iptables in another router project I built (RasPi4 Ubuntu).