YazFi 4.4.2 version, one 2.4 GHz + one 5GHz Guest network. RT-AC86U running AsusWRT-Merlin 386.5_0 F/W.
I have found 2 problems in the YazFi WebGUI tab where connected clients' information is displayed. The 1st problem is that sometimes the wrong IP address for a Guest client is shown. The 2nd problem is that sometimes a client device is shown as being "connected" to a Guest network, but the device is in fact no longer connected to the network at all.
Here is a screenshot of the YazFi WebGUI showing the 2 problems in one entry. An "Unknown" device is shown as connected to the 5GHz Guest network. However, the IP address is incorrect (it's from the Main WLAN IP range, *not* from the Guest WLAN IP range). In addition, this device is actually not connected at all to the network at this time, so the entry should not even be there.
For a little more context, here is a screenshot of related information obtained via CLI while the GUI problem was happening.
In the above screenshot, note the following:
1) The output from
2) The
3) The output from
4) The output from
My curiosity then led me to review the YazFi script, and I found the section of code where the problems occur. The root cause is essentially similar to the one causing the GUI problem I reported for the "Wireless Log" tab from "System Log" (see details here in this thread, particularly post #20). As recommended in that previous thread, the key is getting the ARP cache entries for each client's MAC address, and when found, one must check if the 2nd flag (3rd column from the left) indicates an "incomplete" entry. If so, the client device should be ignored.
Here are my proposed code changes to implement the fix in the YazFi script.
FROM current code [Lines #2702]
TO fixed code:
FROM current code [Lines #2715 to #2722]
TO fixed code:
I have already made & tested the above changes in the YazFi script that's installed on my own router & my relative's router (same model), and everything has been working fine for the last 36 hours or so. The "Unknown" device is gone, and we have not seen any clients with the wrong IP address anymore.
@Jack Yaz, ignoring any differences in coding style, what do you think about the code modifications I have proposed above?
I have found 2 problems in the YazFi WebGUI tab where connected clients' information is displayed. The 1st problem is that sometimes the wrong IP address for a Guest client is shown. The 2nd problem is that sometimes a client device is shown as being "connected" to a Guest network, but the device is in fact no longer connected to the network at all.
Here is a screenshot of the YazFi WebGUI showing the 2 problems in one entry. An "Unknown" device is shown as connected to the 5GHz Guest network. However, the IP address is incorrect (it's from the Main WLAN IP range, *not* from the Guest WLAN IP range). In addition, this device is actually not connected at all to the network at this time, so the entry should not even be there.
For a little more context, here is a screenshot of related information obtained via CLI while the GUI problem was happening.
In the above screenshot, note the following:
1) The output from
wl -i wl1.1 assoclist command shows 2 devices "associated" with the 5GHz Guest network.2) The
arp -an | grep -i "xx:xx:xx:E0:DB:25" command returns no output.3) The output from
cat /var/lib/misc/dnsmasq.leases | grep -i "xx:xx:xx:E0:DB:25" command shows an IP address from the Main WLAN, not from the Guest WLAN.4) The output from
cat /proc/net/arp | grep -i "xx:xx:xx:E0:DB:25" command shows that the device is no longer found in the network (flag says it's an "incomplete" entry), and that it was previously associated with the br0 interface (i.e. Main LAN).My curiosity then led me to review the YazFi script, and I found the section of code where the problems occur. The root cause is essentially similar to the one causing the GUI problem I reported for the "Wireless Log" tab from "System Log" (see details here in this thread, particularly post #20). As recommended in that previous thread, the key is getting the ARP cache entries for each client's MAC address, and when found, one must check if the 2nd flag (3rd column from the left) indicates an "incomplete" entry. If so, the client device should be ignored.
Here are my proposed code changes to implement the fix in the YazFi script.
FROM current code [Lines #2702]
Bash:
ARPDUMP="$(arp -an)"TO fixed code:
Bash:
ARP_CACHE="/proc/net/arp"
NOT_LANIP="grep -v "$(nvram get lan_ipaddr | cut -d'.' -f1-3)""FROM current code [Lines #2715 to #2722]
Bash:
...
GUEST_MACADDR="$(echo "$GUEST_MAC" | awk '{print $2}')"
GUEST_ARPINFO="$(echo "$ARPDUMP" | grep "$IFACE" | grep -i "$GUEST_MACADDR" | grep -v "$(nvram get lan_ipaddr | cut -d'.' -f1-3)")"
GUEST_IPADDR="$(echo "$GUEST_ARPINFO" | awk '{print $2}' | sed 's/(//g;s/)//g')"
GUEST_HOST=""
if [ -z "$GUEST_IPADDR" ]; then
GUEST_IPADDR=$(grep -i "$GUEST_MACADDR" /var/lib/misc/dnsmasq.leases | awk '{print $3}')
fi
...TO fixed code:
Bash:
...
GUEST_MACADDR="$(echo "$GUEST_MAC" | awk '{print $2}')"
GUEST_ARPCOUNT="$(cat $ARP_CACHE | grep -ic "$GUEST_MACADDR")"
if [ $GUEST_ARPCOUNT -lt 2 ] ; then
GUEST_ARPENTRY="$(cat $ARP_CACHE | grep -i "$GUEST_MACADDR")"
GUEST_ARPINFO="$(echo "$GUEST_ARPENTRY" | grep "$IFACE" | eval "$NOT_LANIP")"
else
GUEST_ARPENTRY="$(cat $ARP_CACHE | grep -i "$GUEST_MACADDR" | grep "$IFACE")"
GUEST_ARPINFO="$(echo "$GUEST_ARPENTRY" | eval "$NOT_LANIP")"
fi
GUEST_IPADDR="$(echo "$GUEST_ARPINFO" | awk '{print $1}')"
GUEST_ARPFLAG="$(echo "$GUEST_ARPENTRY" | awk '{print $3}')"
# Skip guest client when ARP entry is marked as "incomplete" #
if [ "$GUEST_ARPFLAG" = "0x0" ] ; then continue ; fi
GUEST_HOST=""
if [ -z "$GUEST_IPADDR" ]; then
GUEST_IPADDR=$(grep -i "$GUEST_MACADDR" /var/lib/misc/dnsmasq.leases | eval "$NOT_LANIP" | awk '{print $3}')
fi
...I have already made & tested the above changes in the YazFi script that's installed on my own router & my relative's router (same model), and everything has been working fine for the last 36 hours or so. The "Unknown" device is gone, and we have not seen any clients with the wrong IP address anymore.
@Jack Yaz, ignoring any differences in coding style, what do you think about the code modifications I have proposed above?
