I just tested and indeed it seems Windows sends out DNS query through IPv6 (fd62...), and then I see that OpenWrt sends it out through port 853 using IPv4 and responds to the Windows client through IPv6.
2 Likes
Interesting! Thanks for testing.
Many megabytes of data from numerous busy public wifi venues showing Apple and Android devices with (useless and unnecessary, but default) dhcp allocated ipv6 addresses where the client cannot get Internet access despite also having ipv4 address allocations.
Debugging at the client device end showed the device, if allocated ipv6, did not try ipv4.
The solution was to disable ipv6-dhcp on the router (just dhcp, not the entire ipv6 stack).
I am saying that this has not been a hypothesis since the issue was researched and a successful configuration change was tested, then implemented at a number of effected sites.
How is that data that implies in any way, that @Lynx's wife iphone is suffering from that issue? Correlation versus causality?
So did you send bug reports that Happy Eyeballs (which is integrated into iOS deeply) was failing?
I am saying that in the context of this thread, where we are talking about a specific single iphone, we do not have sufficient supporting data to claim more than a hypothesis.
Look, I am not claiming that your theory is wrong (it likely is true for the data set you developed it for) I am just trying to convince you that because action A helped under condition B it is not guaranteed to help under condition C as well; again it might, hence "valid hypothesis" worth testing, but not "verified problem and valid solution" (for the iphone under discussion).
Within the context of discussing dhcp for ipv6, @Lynx reported identical symptoms to those I researched, thus indicating a very high probability that the cause was the same.
My reply to his question was:
Yes, both Apple and Android devices default to using ipv6 if offered by dhcp. But if ipv6 routing to the Internet is not available, the Apple/Android device lingers on ipv6 for a while before trying ipv4.
So yes, if you want to be pedantic, you could say that my statement of the very high probability of this being the same issue is in fact a hypothesis.
At no point in this discussion has it been suggested that ipv6 be disabled:
Rather, it was suggested it be disabled because it is known to cause issues in situations effectively identical to this.
Anyway, an interesting discussion (hijacking the OP), that highlights some potential issues of default ipv6 support (including dhcp) in cases where the ISP does not have ipv6 support.
So here is a different way of testing the idea that the "dead-end" IPv6 connectivity might confuse the iphone:
https://openwrt.org/docs/guide-user/network/ipv6/ipv6_henet
just make sure you have internet access via (tunneled) IPv6 
which even if it should not be the solution (I do hope it is) will leave you with an improved home-network.
Getting back to the OP's question... I recently went through this as well. There is a really good video on Dumb Access Point by OneMarcFifty on YouTube for setting this up. Also this support page on OpenWRT.org was a real help.
Marc's video
1 Like
Where you have main router on 5Ghz and two AP's connected via WDS, then do the two AP's need to offer the 5Ghz masters on the same channel as that offered by the main router?
That looks super cool by the way. And free as well. Wonder if that could be set up through WireGuard, albeit that seems to add quite a bit of complexity.
I have not had a chance to go and test the solutions you guys have provided. These topics are quite interesting, glad to see the level of support on these forums you guys are really engaged. 
Once I have tested my config will come back to share the results
Thank you
If you do not pipe all uploads through wireguard (didn't you exclude some like streaming services) you might be able to get away with this IPv6 in IPv4 tunnel simply because your ISP might not peek into the IPv6 header at all?
P.S.: Given the length of that sub-thread so far, maybe you could be convinced to the test whether the "no DHCPv6 configuration" remedies the spurious iphone issue?
I would do the following:
- Make a profile with the desired band 5gz or 2gz
- Declare Master mode, create SSID, security, declare country, and transmit power
- Apply to which network you want it to be an AP for.
- Go to interfaces and make a device for the name of the SSID and say unmanaged
do NOT add the wifi as a bridge to br-lan.
I may be mistaken but I believe this particular issue is not the cause of my problem because the issue occurs regardless of whether the iPhone is connected to my normal network (in which DHCPv6 is enabled) or my guest WiFi network in which DHCPv6 is not enabled. At least this is my understanding because in LuCi I see:
So does this not rule out effects from DHCPv6 on LAN since effect still exists when iPhone connected to the guest interface in which I believe DHCPv6 is not activated? I am not 100% sure because the iPhone may be able to change over to the main LAN since WiFi settings for that are also saved in its settings.
Looking at the logs from such an event this morning I see this. IPhone was manually reconnected at 11:02:16 (and in failure state shortly before then in which it remains connected to WiFi but no internet connectivity following iPhone having been left in sleep state and then picked up for use).
I label logread events as MR1 (main router), AP1 (access point 1) and AP2 (access point 2):
MR1: Tue Jun 14 08:29:39 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
MR1: Tue Jun 14 08:59:09 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 08:59:09 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 09:05:09 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 09:05:09 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 09:18:08 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: associated (aid 1)
MR1: Tue Jun 14 09:18:08 2022 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED XX:XX
MR1: Tue Jun 14 09:34:47 2022 daemon.notice hostapd: wlan0-1: AP-STA-POLL-OK XX:XX
MR1: Tue Jun 14 09:34:47 2022 daemon.notice hostapd: wlan0-1: AP-STA-DISCONNECTED XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: authenticated
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: associated (aid 1)
MR1: Tue Jun 14 11:02:16 2022 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX RADIUS: starting accounting session E292831196291A36
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX WPA: pairwise key handshake completed (RSN)
MR1: Tue Jun 14 11:02:16 2022 daemon.notice hostapd: wlan0-1: EAPOL-4WAY-HS-COMPLETED XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-guest) 192.168.2.234 XX:XX
AP1: Tue Jun 14 10:23:02 2022 daemon.info hostapd: wlan0-2: STA XX:XX WPA: group key handshake completed (RSN)
AP1: Tue Jun 14 11:02:13 2022 daemon.notice hostapd: wlan0-2: AP-STA-DISCONNECTED XX:XX
AP1: Tue Jun 14 11:02:13 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: disassociated
AP1: Tue Jun 14 11:02:14 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
AP1: Tue Jun 14 11:05:23 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: associated (aid 2)
AP1: Tue Jun 14 11:05:23 2022 daemon.notice hostapd: wlan0-2: AP-STA-CONNECTED XX:XX
AP2: Tue Jun 14 09:25:46 2022 daemon.notice hostapd: wlan0-2: AP-STA-CONNECTED XX:XX
AP2: Tue Jun 14 09:34:45 2022 daemon.notice hostapd: wlan0-2: AP-STA-DISCONNECTED XX:XX
AP2: Tue Jun 14 09:34:45 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: disassociated due to inactivity
AP2: Tue Jun 14 09:34:46 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
AP2: Tue Jun 14 11:03:53 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: associated (aid 2)
AP2: Tue Jun 14 11:03:53 2022 daemon.notice hostapd: wlan0-2: AP-STA-CONNECTED XX:XX
I guess relevant chronology is:
AP1: Tue Jun 14 10:23:02 2022 daemon.info hostapd: wlan0-2: STA XX:XX WPA: group key handshake completed (RSN)
AP1: Tue Jun 14 11:02:13 2022 daemon.notice hostapd: wlan0-2: AP-STA-DISCONNECTED XX:XX
AP1: Tue Jun 14 11:02:13 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: disassociated
and then:
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: authenticated
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX IEEE 802.11: associated (aid 1)
MR1: Tue Jun 14 11:02:16 2022 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX RADIUS: starting accounting session E292831196291A36
MR1: Tue Jun 14 11:02:16 2022 daemon.info hostapd: wlan0-1: STA XX:XX WPA: pairwise key handshake completed (RSN)
MR1: Tue Jun 14 11:02:16 2022 daemon.notice hostapd: wlan0-1: EAPOL-4WAY-HS-COMPLETED XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-guest) 192.168.2.234 XX:XX
MR1: Tue Jun 14 11:02:16 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-guest) 192.168.2.234 XX:XX
so maybe error state is between these lines:
AP1: Tue Jun 14 10:23:02 2022 daemon.info hostapd: wlan0-2: STA XX:XX WPA: group key handshake completed (RSN)
AP1: Tue Jun 14 11:02:13 2022 daemon.notice hostapd: wlan0-2: AP-STA-DISCONNECTED XX:XX
I would tend to agree with you here, but since it seems relatively easy to test and @bluewavenet was quite adamant about that being the root-cause of your troubles I still think this is worth testing on your main network (I assume that the disconnects happen often enough so that testing will not take too long).
Again I agree with your theory but can equally not rule it out fully.
Does this always occur when coming out of sleep state?
Yes I think so.
The relevant log lines I think may be:
Tue Jun 14 09:28:59 2022 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Jun 14 09:28:59 2022 daemon.info hostapd: wlan0-2: STA XX:XX IEEE 802.11: associated (aid 2)
Tue Jun 14 09:28:59 2022 daemon.notice hostapd: wlan0-2: AP-STA-CONNECTED XX:XX
Tue Jun 14 10:23:02 2022 daemon.info hostapd: wlan0-2: STA XX:XX WPA: group key handshake completed (RSN)
I think there may be something broken there but I am not 100% sure.
The key addition failed error message seems to be something everyone sees with 802.11r? @_FailSafe do you see these too? But maybe the 'group key handshake' did not work properly. I am just speculating entirely.
But this issue seems to be happening multiple times each day now so at least it is repeatable and I can test different things.
Silly question, is the iphone configured to generate MAC addresses, and if yes does its MAC address change after waking up from sleep? (Probably not, so do not spend time on this )
I wondered about that too. I do see on the phone these settings:
I think that private address listed is maintained but then that wouldn't make sense given the description. Hmm.
Not sure why it's stating that encrypted DNS is blocked because DNS queries go through via stubby. Or at least they should be.
Just tested: DNS goes via 53 to OpenWrt then OpenWrt indeed passes out through 853 via stubby.
In theory, given the description, private wifi addresses could be stable on the same network. But again should be easy to test whether toggling this settings has a positive effect (which is unlikely).
Questions:
- After a sleep will the iphone connect when still closest to the AP it was connected too when it fell asleep?
- Does the same occur if the phone starts sleeping when outside of wifi reach (so without being associated to your WLAN)?
I am not 100% sure. My wife ways that she sees this issue even when picking up and trying to use phone in same place it was put down.
My wife doesn't think so but is not entirely sure.
By the way we have main router with 2.4 and 5Ghz WDS access points. And then two additional access points that connect as WDS clients to the main router and offer 2.4 and 5Ghz access points on the same channel as those of the main router. I believe the latter is the only option with WDS. The SSIDs are all the same and default Fast Transition enabled with only change being to switch FT over DS to FT over air.
From https://support.apple.com/en-us/HT211227:
Starting with iOS 14, iPadOS 14, and watchOS 7, your device improves privacy by using a different MAC address for each Wi-Fi network. This unique MAC address is your device's private Wi-Fi address, which it uses for that network only.
In some cases, your device will change its private Wi-Fi address:
- If you erase all content and settings or reset network settings on the device, your device uses a different private address the next time it connects to that network.
- Starting with iOS 15, iPadOS 15, and watchOS 8, if your device hasn’t joined the network in 6 weeks, it uses a different private address the next time it connects to that network. And if you make your device forget the network, it will also forget the private address it used with that network, unless it has been less than 2 weeks since the last time it was made to forget that network.
2 Likes
So it looks like private WiFi-address' was/is a red herring here.