I'm not sure that all of the ports and the bridge should have MAC addresses defined. I'm not sure what happens if the bridge has a different MAC than the ports within. That said, are they all the same?
Never touched any of that. AFAIK, they're OW defaults. If a compromise or conflict is suspect, how would it manifest? The only difference between the pre and post-ASU configs aside from the firmware related output info resulting from the ubus call system board command was the addition of the pio folder entry in the config odhcpd subsection and that folder is empty.
option piofolder '/tmp/odhcpd-piofolder'
As for over-redacting, I hear you and will curtail the parsing of everything ... next time, seeing as how I've already obliterated the pre-ASU config results.
It is a good idea to set the guest bridge with the empty_bridge option to ensure it comes up properly:
Guest Wifi is operable when enabled. A search of OpenWRT site does not find info about empty_bridge in the documentation and am uncertain if you're referring to replacing an existing entry (more likely) or adding another entry. Would appreciate pointer to learning resource.
On the wifi... do you have multiple APs? I generally recommend avoiding 802.11r because it can often cause more issues than it solves.
Yes, this is the main router to which a hardwired Dumb-AP is also connected.
For the 2G band, it's recommended to stick with one of the three non-overlapping channels: 1, 6, 11.
Tell that to my neighbor who blasts 10 separate 80MHz wide mesh routers over the entire spectrum! It's damn near impossible to find any open bandgap.
The dhcpleasemax line should probably not be there, and it isn't really recommended to use the sequential option:
Hmm, my thinking is that if there isn't any room for another device to obtain an address then it limits the attack surface. Novice logic. Everything has fixed IPs so it seems to work as expected.
The netmask should not be used, and if that force option is actually required, it means something else is happening on your network -- you need to make sure there is exactly one DHCP server.
Yes, this is the only DHCP server. Forced is there for redundancy; it is not needed. The Guest network is subbed and restricted to a very small number of leases.
Input for the default should usually be REJECT.
The lan zone should not have masquerading enabled -- remove that line:
Hmm, I don't recall touching those.
Ok, I've assessed all the recommendations and made some revisions. Do any of these suggest a cause of Androids no longer being able to connect beyond 24.10.6?
There was some issue with everything (wired or not) being unable to get to the WAN side but reloading the config backup made just before installing 24.10.7 (w/o preserving settings) returned functionality. The 24.10.7 install had to be Forced as it stated it had an unrecognized format or similar such message. The SHA256 matched tho.