Motorola Moto G7 Stuck in a Wifi connection loop

A little while ago we bought a Motorola Moto G7 but found that it had issues when connected to our wifi.

After connecting, the phone would aquire an IP, report there was no internet connection and then disconnect (before automatically trying to connect again), leading to it repeatedly looping through several states

  Connecting -> Obtaining IP -> Connected
      ^                            |
      |                            V
    Saved <------------------ No Internet

Our main wifi is dual band, exposing 2.4Ghz and 5Ghz networks using the same SSID. So, at the time, I assumed that (like many devices at the time), the phone didn't like this.

Not wanting to shut off our 5Ghz network for the sake of a single device, I instead associated the phone with our (2.4Ghz only) Guest wifi network and it's worked happily ever since.

However, I was recently looking at swapping out our Wifi and wanted to try moving this phone back to the main wifi (so that it can reach cast to Chromecast etc).

Despite the change in Wifi access-point, as soon as I connected the phone to the main SSID it went straight back into the connection loop I'd seen before.

There are lots of pages talking about resolving Wifi issues on the G7 but they all seem to be focused on a phone that won't connect, or that periodically experiences dropouts rather than a device that connects but won't stay connected for more than a few seconds (even Motorola's troubleshooting page doesn't list it as a possible issue).

So, having finally got to the bottom of our issues, I thought it might be useful to detail what I found in case it provides a pointer to others.

Things it wasn't

There were a few things that didn't cause this, but are definitely worth checking before embarking on a path of deeper troubleshooting.

• Privacy MAC Addresses: these are on by default and a lot of online troubleshooting guides suggest that they can cause issues (seperately, I've noted in the past that these can be problematic for those with kids)
• The phone supports 5GHz Wifi
• Switching the network to 2.4GHz only didn't resolve the issue
• Could see in my Pihole logs that the phone was (successfully) resolving connectivitycheck.gstatic.com
• Checked some OpenWRT Specific stuff

It's always DNS

As mentioned above, my Pi-hole logs showed that the phone was successfully resolving connectivitycheck.gstatic.com and receiving both an A and a AAAA record back in response.

However, it turned out that this was only a part of the picture.

In the brief moments that the phone was connected, it showed two DNS server addresses - one ipv4 and one ipv6.

My pihole deployment is only available via ipv4, the ipv6 address being advertised related to an old server that I dismantled years ago (but apparently never removed from my router's IPv6 config)

It turns out that the Moto's connectivity check was (attempting) to send a test query to each of these, and the IPv6 one was (obviously) failing.

Other devices on the wifi, presumably, have had the same issue but silently fall back to using the v4 resolver.

The Moto, though, saw the failure and decided that the entire connection was bad, triggering a disconnect from the Wifi.

Poor Design

My network was, by any measure, borked.

But, a wide range of other devices (both Android and non-Android) handled this misconfiguration so transparently that I wasn't even aware that it was there. Of course, that's not necessarily a win: there's definitely a valid argument in favour of making issues like this visible so they get fixed.

The problem is, the Moto's design meant that it didn't make the nature of the issue visible and in fact made the issue extremely difficult to troubleshoot. The phone doesn't surface any meaningful information about why it decided to drop the wifi.

Even collecting any information about the phone's state whilst on the wifi is problematic because it only stays on for about a second before disconnecting. Some information is displayed so briefly that even recording the screen won't reliably capture it.

Status information about the network's advertised/configured DNS servers was absolutely essential in pointing me in the right direction, but it was only available to me because I had another phone (which wasn't misbehaving) to check on - the Moto flashed the information up too briefly for a human to properly read and recognise.

There doesn't need to be a detailed report, but it'd have been really helpful for the interface to have noted that it was having issues connecting to a resolver.

And, of course, if a network is considered bad it probably doesn't make sense to try and reconnect a second later: the network's not changed, so all that's actually happening is the phone is spamming the access point with Authentication, Association and Disassociation requests.

Conclusion

With the benefit of hindsight, the Moto's behaviour was a warning about a misconfiguration on the network. The problem is, no other device was complaining, so it was easy to assume that the issue was something specific to the Moto.

That assumption, though, was not entirely unfair: the G7 has historically had a reputation for having Wifi issues and didn't expose any information to the operator about the issues it was encountering.

It looks as though the Moto G7 is a little over-sensitive about its connectivity tests (which may well explain some of the drops that others have reported), so if there are issues remaining connected to Wifi it's always worth checking whether there was some brief connectivity issue at the time.

Clearly, having rock-solid ipv4 connectivity isn't enough - if ipv6 is available it also needs to work, because the phone's tests won't seem to accept failing back as an option.