Do you see the DHCPv6 discovery on your DHCP server?
Do you have a DHCPv4 server running at all?
I don't run DHCPv4 or DHCPv6 at all on my network. I'm just using SLAAC. I have so few devices that need IPv4 addresses that I just manually assign them (like, I can count them on one hand).
So here's where I'm at now. I went ahead and did a factory reset on the device, choosing to wipe all of my prior configuration and use the defaults from OpenWRT. Running 23.05.4.
I made the following changes:
Replaced config dhcp 'lan' in /etc/config/dhcp with:
config dhcp 'lan'
option interface 'lan'
option dhcpv4 'disable'
option dhcpv6 'disable'
Replaced the original config interface 'lan' in /etc/config/network with:
config interface 'lan'
option device 'br-lan'
option proto 'dhcpv6'
(There doesn't seem to be option proto 'slaac', which is why I used 'dhcpv6').
That's it. Everything else is stock OpenWRT. Right now I'm only interested in getting the AP a proper IPv6 address. I'm ignoring any clients that connect to the AP.
I apply those settings and reboot. After things settle, I have no IPv6 address on br-lan other than link local. I check the logs and I see
odhcp6c: Failed to send RS (Address not found)
odhcp6c: Failed to send SOLICIT message to ff02::1:2 (Address not found)
At this point, the firewall is up and running.
# /etc/init.d/firewall status
active with no instances
Now here's the weird thing... changing nothing, I run the following:
# /etc/init.d/firewall reload
# /etc/init.d/network restart
(Reminder that I have not touched /etc/config/firewall at all)
I quickly run logread -f and see what happens, and I see the same messages as above about RS and SOLICIT... but then...
odhcp6c: Failed to send RS (Address not found)
odhcp6c: Failed to send SOLICIT message to ff02::1:2 (Address not found)
odhcp6c: Failed to send SOLICIT message to ff02::1:2 (Address not found)
netifd: Interface 'lan' is now up
... abridged dnsmasq messages ...
firewall: Reloading firewall due to ifup of lan (br-lan)
I check ifconfig br-lan again... and voila! My IPv6 assignments are there, just as I expect. (Well, looks like I got an extra ULA, but I don't care about that right now).
This suggests to me that there is some sort of loading order issue.
- if I
reboot, I'm back to no IP assignments. - it seems that the firewall rules work, but that the firewall itself needs to receive an update (ifup) about the interface that it doesn't receive--or receives at the wrong time--during boot
- this behavior is very consistent (tried across 20+ reboots)
As an aside, this also makes me realize that my original issue about IPv6 assignments via SLAAC here was never really resolved, since it was only working when I had the firewall disabled. The above procedure works with the firewall enabled, but only if I manually cycle the network after the device has booted, which... sucks.
What is going on here? I'm thoroughly confused why the exact same configuration fails to secure an IPv6 address at boot (including waiting for at least 10 minutes after boot), but succeeds when manually cycled. 
I can't answer this as I really don't know what might be happening. However, if you just run this alone (without the firewall reload):
/etc/init.d/network restart
... do you get the IPv6 address?
Also, what happens if you put an IPv4 address on the device (even if you don't use it and there's nothing else for it to connect to via IPv4?
Finally, while this is important for device management reasons, the IPv6 address/interace isn't necessary at all for the bridged AP to function. As a bridge, it shoudl be transparent. So it is worth continuing to test the original goal of keeping consistent wifi connectivity on your Apple devices.
(side note: as I think about it, I don't know if Apple devices are completely happy with only IPv6; they may want to have either IPv4 alone or a proper dual-stack IPv4 + IPv6. But, I cannot say this with any evidence or certainty, just an idea/question to consider).
hi,
it is recommended to disable firewall dnsmasq and odhcpd on dumb aps [link] If you need them - it is fine.
For ipv6, you should disable RA service like on the picture .
If firewall needs to be up, try to disable the RA service, DHCPv6 and NDP proxy in lan settings.
Tried that, and no, that doesn't work. Manually reloading the firewall is required.
Not sure what you're asking here... are you wondering if assigning an IPv4 address to the AP might trick the firewall into thinking the interface is up, and thereby allow IPv6 packets at boot like the manual cycle process?
Granted, but I would like to be able to continue testing the original issue by making changes to the AP over SSH, which I can't do over an IPv4 address, as that change spills out beyond the APs and onto my other computers.
I'm tempted to assign a static IPv6 address for now so I can move on... or accept that I'll disable the firewall and figure out how I can re-enable it without this issue before my next upgrade.
I had tried dual stack with several Apple devices earlier in my debugging process and the issue persisted in that situation, so I'm reasonably certain the issue is not related to the IP version.
The issue started when I switched from UniFi to OpenWRT, not when I transitioned from dual stack to IPv6 only.
I was trying to have these running per @psherman 's earlier recommendation:
I like the thought of not having to remember to re-disable these services when I perform upgrades on the AP--which is exactly what happened when I upgraded musubi.
@psherman @danpawlik Wanted to interject a brief interlude to say thank you for all your time, attention, and prompt replies to this issue! 
2 Likes
Ok... thanks for trying it. Honestly, I have no idea why the firewall reload is required there... very odd.
Yes, precisely. You could setup any RFC1918 address, it doesn't need to connect to any other devices (so it can be on an IPv4 subnet that doesn't exist anywhere else on your network), we're just talking about an address in general. You might even be able to make it a /32 which effectively makes it an island anyway.
Understood.
This might be the best approach, at least for now.
Thanks. It was just a thought -- kind of stabbing in the dark. Sounds like there was no merit to it... glad you already had run those experiments.
@psherman Ok, I upgraded all three APs to 23.05.4 and applied your recommended changes to each.
- I factory reset each AP (did not preserve settings), so anything that may have been lingering from when I last tinkered with these a year+ ago should be gone/irrelevant now.
- Firewalls are disabled on all three APs
- 2.4 GHz channels are 1 (musubi), 6 (lily), and 11 (gus)
- 5 GHz channels are 36 (musubi), 100 (lily), and 144 (gus); my list of available channels tops out at 144, so I couldn't set 149 and 165 as you mentioned earlier.
- Country codes have been set on all three APs for both 2.4 GHz and 5 GHz radios
dhcpv4,dhcpv6,ra, andndpare all marked asdisableon all three APs in/etc/config/dhcp
All my devices are back online, so I guess I'm back in my "wait and see" period to see if my original issue happens again. 
Be aware that you may run into DFS issues (info here).
Great... let's see what happens. Fingers crossed!
Ahh, I think my list of available channels changed when I selected the correct country code, as now 149 and 165 are available. Switched to use those.
2 Likes
Good job! Glad that you share all the knowledge what you have done - might be really helpful for others.
Please note, that those channels might give less power comparing to other channels that are on DFS. Check the iw list command.
For example, my output for mt7925:
Frequencies:
* 5180.0 MHz [36] (23.0 dBm)
* 5200.0 MHz [40] (23.0 dBm)
* 5220.0 MHz [44] (23.0 dBm)
* 5240.0 MHz [48] (23.0 dBm)
* 5260.0 MHz [52] (20.0 dBm) (radar detection)
* 5280.0 MHz [56] (20.0 dBm) (radar detection)
* 5300.0 MHz [60] (20.0 dBm) (radar detection)
* 5320.0 MHz [64] (20.0 dBm) (radar detection)
* 5500.0 MHz [100] (26.0 dBm) (radar detection)
* 5520.0 MHz [104] (26.0 dBm) (radar detection)
* 5540.0 MHz [108] (26.0 dBm) (radar detection)
* 5560.0 MHz [112] (26.0 dBm) (radar detection)
* 5580.0 MHz [116] (26.0 dBm) (radar detection)
* 5600.0 MHz [120] (26.0 dBm) (radar detection)
* 5620.0 MHz [124] (26.0 dBm) (radar detection)
* 5640.0 MHz [128] (26.0 dBm) (radar detection)
* 5660.0 MHz [132] (26.0 dBm) (radar detection)
* 5680.0 MHz [136] (26.0 dBm) (radar detection)
* 5700.0 MHz [140] (26.0 dBm) (radar detection)
* 5720.0 MHz [144] (13.0 dBm) (radar detection)
* 5745.0 MHz [149] (13.0 dBm)
* 5765.0 MHz [153] (13.0 dBm)
* 5785.0 MHz [157] (13.0 dBm)
* 5805.0 MHz [161] (13.0 dBm)
* 5825.0 MHz [165] (13.0 dBm)
* 5845.0 MHz [169] (13.0 dBm)
* 5865.0 MHz [173] (13.0 dBm)
* 5885.0 MHz [177] (disabled)
@danpawlik Didn't know about iw list. Thanks!
But I'm unclear about what it is I'm reading... I see 36, 149, and 165 in my list, but how do items in this list compare to each other? Am I comparing the dBm values? Is higher better?
Search in Google 23 dbm to mw. In short, higher gives more power to the antennas, but in WiFi, not every time higher is better
Aaaaaannnnnnddddddd... issue happened again. 
What should I try next?
Gah! I thought we were going to solve this... bummer.
Ok... so what are the circumstances of the drop? Is it affecting an iPhone? Mac? iPad? Was the device moving between APs at the time (as in physically moving from the proximity of one towards another), or was it stationary?
How was the wifi performance just prior to the drop?
Can you identify any patterns, such as "it seems to happen most often when I move in the direction of lily, or when I'm moving away from gus"?
Not sure if this helps - AWDL scans for two channels on a periodic basis for peers - ISM6 and UNII3-149 - those are the default airplay channels. It's a background/triage search with the secondary VIF, so it shouldn't impact the primary connection.
Perhaps the issue really is wrapped around how Apple decides to scan for the primary SSID and thresholds there - Apple will generally scan for better service once the serving AP is around -70 dBm.
If one has multiple AP's broadcasting unique SSID's, and they're all part of the same LAN - keep in mind that an SSID to the client side, represents the same relationship to the LAN - e.g. ESSID vs. BSSID..
If Apple devices on a triage/better service scan sees a new BSSID that might be better than the current, it's going to try to jump, but the BSSID means a new association, not a re-association to the current ESSID.
I can reliably state that this issue happens while the device is stationary and/or roaming. I've seen it in both instances. It seems to predominantly affect iphones and ipads, but I have seen it (very rarely) on my Mac. I'm guessing I've ran into it on my HomePods as well, but those have hardly any interface at all, so that's nothing more than a guess.
I wish I could identify other patterns, but even after months of observation, I still can't detect any. Lily & musubi are the two most-used APs in our household, with lily doing the lion's share of that work: think of our house as a long rectangle, and lily is in the center, while musubi and gus are towards either end.
AFAIK performance is flawless before the drop; definitely not a "slow and steady decline." The drops happen regardless of usage, as I've seen them in the morning when I wake up and find my wife's phone offline while mine is online, other times I'll be in the middle of watching a YouTube video and it'll drop half-way through. The drops happen per-device—one device will go offline while the others in my household are unaffected.
Drops can happen as frequently as 3x per day, or as infrequently as 3x per week. Also the frequency is not tied to the device/OS type, as my iPad may drop 3 times yesterday, then it won't drop again until 2 days later.
Lastly, just wanted to repeat my original post to say that there are two different types of drops with two different recovery mechanisms. Those also do not appear to be device/OS specific, and there is no pattern (that I can detect) about when I'll encounter one type or another.
The infrequent, seemingly non-reproducible nature of the problem is why I waited so long to post about it here on this forum, as I was afraid I'd get a lot of "huh, weird. I dunno. 
" since I was coming in without reliable reproduction steps.
Here's another thing we can try:
Add this line to each of the SSID config stanzas on each AP:
option dtim_period '3'
Then restart the APs and test again.
2 Likes
Applied and rebooted.