Solved Wrong IPs shown on "Wireless Log" webpage.

[RMerlin]

I suspect entries with a flag of 0x00 might be devices that have disappeared from the network, and something tried to reach them, which caused the entry to be set to FAILED rather than just STALE. Right now my TV is off, and its ARP entry shows a flag of 0x00 (that's my only client with a flag of 0x00).

Another oddity in your case is that you have an entry on the wl0.2 interface. Here, all my clients are on the br0 interface, including my Grovee lights which are on a Guest Network. This might be a side effect of using that script, where the client possibly switched to a virtual network interface, and obtained a new IP address then, causing the ARP cache to have two different entries for that MAC.

In any case, it should be safe to ignore/skip entries with a flag of 0x00 while parsing the arp cache.

 

[Martinski]

I suspect entries with a flag of 0x00 might be devices that have disappeared from the network, and something tried to reach them, which caused the entry to be set to FAILED rather than just STALE. Right now my TV is off, and its ARP entry shows a flag of 0x00 (that's my only client with a flag of 0x00).

In several header files (from different sources) that I saw where the ARP cache flag values are defined, the value of 0x00 simply indicates an "incomplete" entry, and it's not explained what scenarios or events can set that particular value. It seems to be a "catch-all" value for any condition that is not clearly defined by the non-zero values.

Another oddity in your case is that you have an entry on the wl0.2 interface. Here, all my clients are on the br0 interface, including my Grovee lights which are on a Guest Network. This might be a side effect of using that script, where the client possibly switched to a virtual network interface, and obtained a new IP address then, causing the ARP cache to have two different entries for that MAC.

Yeah, maybe running YazFi to configure the Guest Networks in a different way from the built-in method throws a small wrench into the works. It has worked fine for my use cases so far, so functionally I see no problems; but perhaps it might need some "fine-tuning" during the reboot setup sequence.

In any case, it should be safe to ignore/skip entries with a flag of 0x00 while parsing the arp cache.

OK, sounds good.

Thanks.

 

[Martinski]

In any case, it should be safe to ignore/skip entries with a flag of 0x00 while parsing the arp cache.

I saw that you implemented the fix described in post #20 of this thread, and that fix is already included in the latest F/W 386.5_2 version. However, I completely missed & failed to point out before that the equivalent code used for the GUEST wireless networks (e.g. "wl0.1" & "wl1.1") also has the same bug (see lines #680-#681 in the same source file web-broadcom-am.c). The fix is exactly the same as before.

FROM current code:

...
if ( (sscanf(line,"%15s %*s %*s %17s",ipentry,macentry) == 2) &&
     (!strcasecmp(macentry, ether_etoa((void *)&auth->ea[ii], ea))) ) {
         found = 1;
         break;
} else
...

TO fixed code:

...
if ( (sscanf(line,"%15s %*s %x %17s", ipentry, &flagentry, macentry) == 3) &&
     (!strcasecmp(macentry, ether_etoa((void *)&auth->ea[ii], ea))) &&
     (flagentry != 0) ) {
         found = 1;
         break;
} else
...

Thank you for the great work, and congratulations on the 10-year anniversary of your custom F/W project. My hat's off to you!

 

[RMerlin]

However, I completely missed & failed to point out before that the equivalent code used for the GUEST wireless networks (e.g. "wl0.1" & "wl1.1") also has the same bug

Thanks, I'll take a look at it.

 

[alan6854321]

I just updated my AX86S to the latest beta - 386.7_beta1 and now it's all gone very wrong on the Wireless log page.

All the clients on Guest network #1 now show the same address - 192.168.2.81
DHCP leases page is correct.
Network map contents is also correct, but only shows main network, not guests.
(I use YazFi to configure guest networks).