Hub stuck in groupRole: none and blockingUpdate: 1 — mesh points cannot join — backend provisioning

[letolkki]

Device: Google Nest WiFi Hub H2D, Software 14150.883.17 ISP: Verizon Home Internet (fixed wireless, CGNAT) Case: 7-9057000040939

Summary of problem: All three mesh WiFi points went offline simultaneously on February 25, 2026. Since then no points can be added to the mesh. Every setup attempt fails with "Connection problem during setup."

What I have tried:

• Factory reset of original Hub — same failure
• Purchased brand new replacement Hub — mesh points connected successfully and worked briefly in full mesh mode
• Within minutes of initial setup a Google-pushed update hit the replacement Hub — mesh stopped working immediately and has not worked since
• Multiple factory resets of both Hub devices
• Multiple factory resets of mesh points
• Reinstalled Google Home app
• Disabled Verizon WiFi, connected phone exclusively to Hub network during setup
• Inverse power cycle, network restart from app

Key technical evidence from Hub API (http://192.168.86.1/api/v1/status😞

"groupRole": "none""blockingUpdate": 1"updateStatus": "idle""updateNewVersion": "0.0.0.0""oobeDetailedStatus": "OOBE_COMPLETE""migrationMode": "voobed"

This state persists on two different Hub devices across multiple factory resets. The Hub completes setup successfully, is online, but groupRole never changes from none to primary. Google's backend never assigns primary mesh router status.

The smoking gun — doorbell test: A brand new Nest Doorbell (Wired, 3rd Gen) failed repeatedly to set up while the Hub was online. The moment I powered off the Hub, the doorbell connected instantly on the first try. This proves the Hub's broken provisioning state is actively corrupting the Assisting Device handshake for ALL device setup, not just mesh points. My local network and ISP are not the issue.

Bridge mode confirmation: Verizon admin page explicitly shows "Network Connection: Bridge" for the Hub. Hub receives 192.168.1.166 directly from Verizon gateway. Screenshots provided to Google support.

What I believe is happening: blockingUpdate: 1 indicates Google's backend has flagged a required update but updateStatus remains idle and no update is ever delivered. The backend appears to be refusing to provision groupRole: primary until the blocking update is applied, but the update is never pushed. This creates a deadlock that only Google's backend team can resolve.

Google support feedback submitted: Keywords: GWT3 + 39822 + Failed to add Nest WiFi Point

Has anyone else experienced groupRole: none persisting after full Hub setup? Any Google engineers able to look at the backend provisioning state for this account?

Just for completeness here is the status json:

{
"dns": {
"mode": "automatic",
"servers": [ "192.168.1.1" ]
},
"setupState": "GWIFI_OOBE_COMPLETE",
"software": {
"blockingUpdate": 1,
"softwareVersion": "14150.883.17",
"updateChannel": "stable-channel",
"updateNewVersion": "0.0.0.0",
"updateProgress": 0.0,
"updateRequired": false,
"updateStatus": "idle"
},
"system": {
"countryCode": "us",
"groupRole": "none",
"hardwareId": "MISTRAL D2B-A2C-C3Q-I4H",
"lan0Link": false,
"ledAnimation": "CONNECTED",
"ledIntensity": 30,
"modelId": "MISTRAL",
"oobeDetailedStatus": "OOBE_COMPLETE",
"uptime": 1067
},
"vorlonInfo": {
"migrationMode": "voobed"
},
"wan": {
"captivePortal": false,
"ethernetLink": true,
"gatewayIpAddress": "192.168.1.1",
"invalidCredentials": false,
"ipAddress": true,
"ipMethod": "dhcp",
"ipPrefixLength": 24,
"leaseDurationSeconds": 86400,
"localIpAddress": "192.168.1.166",
"nameServers": [ "192.168.1.1" ],
"online": true,
"pppoeDetected": false,
"vlanScanAttemptCount": 0,
"vlanScanComplete": true
}
}

[Qualia]

i currently am having the exact same issue

[letolkki]

Thanks for responding! Can you share the following so we can build a stronger case:
1. What is your ISP?
2. Did your mesh points all go offline suddenly at the same time?
3. Did it happen after an automatic update?
4. Can you run this in a browser while connected to your Hub network and paste the output:
http://192.168.86.1/api/v1/status
(your IP may be different — check your default gateway first)
5. Do you have an open Google support case number?
Specifically looking to see if you also show groupRole: none and blockingUpdate: 1 in your status output. Three users with identical API signatures on different ISPs would be definitive proof this is a Google backend bug.

[stevegoulet]

I am having the same issue.

1. ISP: Verizon 5G Home Internet
2. Yes, points went offline suddenly
3. Unknown if it was after an update, but I noticed the yellow lights on 3 devices at 3am on the 24th of March
4. Status output is below
5. No open support case number yet

{
   "dns": {
      "mode": "automatic",
      "servers": [ "xxx" ]
   },
   "setupState": "GWIFI_OOBE_COMPLETE",
   "software": {
      "blockingUpdate": 1,
      "softwareVersion": "14150.883.17",
      "updateChannel": "stable-channel",
      "updateNewVersion": "0.0.0.0",
      "updateProgress": 0.0,
      "updateRequired": false,
      "updateStatus": "idle"
   },
   "system": {
      "countryCode": "us",
      "groupRole": "root",
      "hardwareId": "xxx",
      "lan0Link": false,
      "ledAnimation": "CONNECTED",
      "ledIntensity": 30,
      "modelId": "MISTRAL",
      "oobeDetailedStatus": "OOBE_COMPLETE",
      "uptime": 34537
   },
   "vorlonInfo": {
      "migrationMode": "voobed"
   },
   "wan": {
      "captivePortal": false,
      "ethernetLink": true,
      "gatewayIpAddress": "xxx",
      "invalidCredentials": false,
      "ipAddress": true,
      "ipMethod": "dhcp",
      "ipPrefixLength": 30,
      "leaseDurationSeconds": 60,
      "localIpAddress": "xxx",
      "nameServers": [ "xxx" ],
      "online": true,
      "pppoeDetected": false,
      "vlanScanAttemptCount": 0,
      "vlanScanComplete": true
   }
}

[Seanbuc]

I am having the same issue.

1. ISP: Xfinity cable internet
2. Yes, points went offline suddenly
3. Unknown if it was after an update
4. Status output is below
5. No open support case number

{
"dns": {
"mode": "automatic",
"servers": [ "xxx", "xxx" ]
},
"meshInfo": {
"mesh-channel": 197,
"mesh-interface": "mesh-6000mhz"
},
"setupState": "GWIFI_OOBE_COMPLETE",
"software": {
"blockingUpdate": 1,
"softwareVersion": "3.78.518349",
"updateChannel": "stable-channel",
"updateNewVersion": "0.0.0.0",
"updateProgress": 0.0,
"updateRequired": false,
"updateStatus": "idle"
},
"system": {
"countryCode": "us",
"groupRole": "root",
"hardwareId": "SIROCCO MP-MP1-KIOX3130527200-SAMS3130752900",
"lan0Link": true,
"ledAnimation": "CONNECTED",
"ledIntensity": 100,
"modelId": "SIROCCO",
"oobeDetailedStatus": "OOBE_COMPLETE",
"uptime": 687017
},
"vorlonInfo": {
"migrationMode": "voobed"
},
"wan": {
"captivePortal": false,
"ethernetLink": true,
"gatewayIpAddress": "xxx",
"invalidCredentials": false,
"ipAddress": true,
"ipMethod": "dhcp",
"ipPrefixLength": 23,
"leaseDurationSeconds": 345600,
"localIpAddress": "xxx",
"nameServers": [ "xxx", "xxx" ],
"online": true,
"pppoeDetected": false,
"vlanScanAttemptCount": 0,
"vlanScanComplete": true
}
}

[michael092478]

March 24 — all wireless mesh nodes offline, wired backhaul nodes survived, all leaves show blockingUpdate: 1
Nest WiFi Pro 6-node mesh, model SIROCCO (G6ZUC), firmware 3.78.518349, Comcast ISP.

On March 24, three of my five secondary nodes went offline simultaneously. No configuration changes on my end.

The only nodes that remained functional are the ones connected via wired Ethernet backhaul. Three leaf nodes connected through a switch with Ethernet stayed online. Two leaf nodes relying entirely on wireless mesh went offline and cannot rejoin. They show amber light and appear offline in Google Home. I have not yet attempted factory reset on those two wireless nodes.

I did factory reset one of the wired leaf nodes and re-add it. blockingUpdate: 1 was immediately re-applied after setup completed. The flag is not stored on the device — it is set by Google's backend on check-in.

Full /api/v1/status output from all four reachable nodes below. You can check yours at http://192.168.86.1/api/v1/status or http://10.0.0.1/api/v1/status — use whatever your Nest primary's LAN IP is, from a browser on your local network.

Primary node (root) — the only node without blockingUpdate:

json{
"dns": { "mode": "automatic", "servers": [] },
"meshInfo": { "mesh-channel": 197, "mesh-interface": "mesh-6000mhz" },
"setupState": "GWIFI_OOBE_COMPLETE",
"software": {
"blockingUpdate": 0,
"softwareVersion": "3.78.518349",
"updateChannel": "stable-channel",
"updateNewVersion": "0.0.0.0",
"updateProgress": 0,
"updateRequired": false,
"updateStatus": "idle"
},
"system": {
"countryCode": "us",
"groupRole": "root",
"lan0Link": true,
"ledAnimation": "CONNECTED",
"ledIntensity": 100,
"modelId": "SIROCCO",
"oobeDetailedStatus": "OOBE_COMPLETE",
"uptime": 30059
},
"vorlonInfo": { "migrationMode": "voobed" },
"wan": {
"captivePortal": false,
"ethernetLink": true,
"gatewayIpAddress": "xx.xx.xx.xx",
"invalidCredentials": false,
"ipAddress": true,
"ipMethod": "dhcp",
"ipPrefixLength": 22,
"leaseDurationSeconds": 7200,
"localIpAddress": "xx.xx.xx.xx",
"nameServers": [],
"online": true,
"pppoeDetected": false,
"vlanScanAttemptCount": 0,
"vlanScanComplete": true
}
}

Leaf node (wired Ethernet backhaul — online but flagged). All three wired leaf nodes are identical except uptime (127202, 106121, 26932):

json{
"dns": { "mode": "automatic", "servers": [] },
"meshInfo": { "mesh-channel": 197, "mesh-interface": "mesh-6000mhz" },
"setupState": "GWIFI_OOBE_COMPLETE",
"software": {
"blockingUpdate": 1,
"softwareVersion": "3.78.518349",
"updateChannel": "stable-channel",
"updateNewVersion": "0.0.0.0",
"updateProgress": 0,
"updateRequired": false,
"updateStatus": "idle"
},
"system": {
"countryCode": "us",
"groupRole": "leaf",
"lan0Link": false,
"ledAnimation": "CONNECTED",
"ledIntensity": 100,
"modelId": "SIROCCO",
"oobeDetailedStatus": "OOBE_COMPLETE",
"uptime": 127202
},
"vorlonInfo": { "migrationMode": "voobed" },
"wan": {
"captivePortal": false,
"ethernetLink": false,
"gatewayIpAddress": "xx.xx.xx.xx",
"invalidCredentials": false,
"ipAddress": true,
"ipMethod": "dhcp",
"ipPrefixLength": 24,
"leaseDurationSeconds": 86400,
"localIpAddress": "xx.xx.xx.xx",
"nameServers": [],
"online": true,
"pppoeDetected": false,
"vlanScanAttemptCount": 0,
"vlanScanComplete": true
}
}

Leaf nodes 4 & 5 (wireless mesh — offline):
Cannot reach API. These nodes are powered on but show amber light and are listed as offline in Google Home. They rely entirely on wireless mesh with no Ethernet option. I have not yet attempted factory reset on these two.

Observations:

Root node has blockingUpdate: 0. All three reachable leaf nodes have blockingUpdate: 1. All on identical firmware 3.78.518349.

No update is being delivered — updateStatus: idle, updateNewVersion: 0.0.0.0, updateRequired: false. The flag says an update is blocking but no update exists.

All three wired leaf nodes report ethernetLink: false and lan0Link: false despite being physically connected via Ethernet and functioning normally with sub-1ms ping latency. This field does not appear to accurately reflect wired backhaul status.

The wired nodes survived because Ethernet backhaul does not require wireless mesh re-negotiation. The wireless-only nodes lost their mesh connection and have not been able to re-establish it.

Factory resetting a node and re-adding it to the mesh does not clear blockingUpdate. The flag is re-applied immediately by Google's backend after setup completes.

[letolkki]

Some work is being done for this problem. Here is a portion of an email I received from Google Tech Support:

Hello,
We sincerely appreciate your cooperation throughout the troubleshooting process and for sharing your suggestions. 
I wanted to provide you with an update: Our engineering team is actively working on a fix of the issue. While there isn’t an exact timeframe for the resolution, please rest assured that the team is doing their best to address it as quickly as possible.
There’s no need to worry. Once the issue has been resolved, I will notify you immediately. Thank you again for your patience and understanding.

[jroth93]

Also been having this issue for about a week. Hubs are offline as well as my Home Minis. Strangely, all Chromecasts and my Nest Hub Display work fine.

1. Verizon 5G
2. Yes
3. I believe so, I didn’t do any configuration changes.
4. Output Below
5. Case number is 5-5867000040347

{
"dns": {
"mode": "custom",
"servers": [ "8.8.8.8", "8.8.4.4" ]
},
"setupState": "GWIFI_OOBE_COMPLETE",
"software": {
"blockingUpdate": 1,
"softwareVersion": "14150.883.17",
"updateChannel": "stable-channel",
"updateNewVersion": "0.0.0.0",
"updateProgress": 0.0,
"updateRequired": false,
"updateStatus": "idle"
},
"system": {
"countryCode": "us",
"groupRole": "root",
"hardwareId": "MISTRAL D2B-A2C-A3Q-I8M",
"lan0Link": false,
"ledAnimation": "CONNECTED",
"ledIntensity": 30,
"modelId": "MISTRAL",
"oobeDetailedStatus": "OOBE_COMPLETE",
"uptime": 185505
},
"vorlonInfo": {
"migrationMode": "voobed"
},
"wan": {
"captivePortal": false,
"ethernetLink": true,
"gatewayIpAddress": "97.179.236.21",
"invalidCredentials": false,
"ipAddress": true,
"ipMethod": "dhcp",
"ipPrefixLength": 29,
"leaseDurationSeconds": 60,
"localIpAddress": "97.179.236.20",
"nameServers": [ "198.224.148.135", "198.224.149.135" ],
"online": true,
"pppoeDetected": false,
"vlanScanAttemptCount": 0,
"vlanScanComplete": true
}
}

[197]

F B I 

[letolkki]

I understand the frustration — I've been dealing with this since February 25th. The good news is Google engineering has officially acknowledged the issue on case 7-9057000040939 and confirmed they are actively working on a fix. No timeframe given but it is confirmed.

If you are affected, open a support case and reference keywords GWT3 + 39822 + Failed to add Nest WiFi Point when submitting feedback through the Google Home app. The more cases linked to this engineering investigation the higher the priority.

Hang in there — we're closer to a resolution than we were a week ago.

[stevegoulet · Accepted solution]

The following worked for me and a few other (no thanks to Google Support): Change your DNS in the home app from Automatic to ISP

[letolkki]

Yep that worked for me. Mega thanks! Never would have considered that change.

[jroth93]

Worked for me too! Thanks stevegoulet!

[letolkki]

Resolved! Huge thank you to stevegoulet for finding the fix.

The Fix: Google Home app → WiFi → Settings → Advanced Networking → DNS → change from Automatic to ISP

That's it. After weeks of fighting with Google support, two Hub replacements, and months of technical documentation, it was a single DNS setting change. All three mesh points are back online in full mesh mode.

Nothing to do with double NAT or ISP configuration as Google support repeatedly insisted.

To everyone still affected — try this first before anything else. Takes 30 seconds.