Passive Mesh Topology Discovery from Orbi Beacon Frames
I was pulling apart a Netgear Orbi WiFi 7 mesh system for Network Weather and found an undocumented 31-byte Qualcomm vendor IE in the 5 GHz beacons from each mesh node. In these captures, one six-byte field appears to encode the node’s current upstream parent, another matches the BSSID of the radio sending the beacon, and the parent field changes when the mesh re-parents a satellite. That makes passive recovery of the current backhaul tree possible from nearby captures alone.
I couldn’t find this IE documented anywhere. Wireshark knows the OUI (8C:FD:F0) belongs to Qualcomm but doesn’t parse the payload. The Linux kernel references it as VENDOR_QCA in ath11k/cfr.h, but only for Channel Frequency Response headers, not beacon IEs.
The reroute
I’ll start with the punch line, because this is the part that convinced me the IE carries live topology state and not just manufacturing metadata.
My test setup is an RBE771 router and two RBE770 satellites running firmware V10.5.10.10. Both satellites initially connected directly to the router (star topology). Here’s Satellite-2’s type=0 IE at that point:
00 01 03 00 01 00 00 CE 10 2F 06 EE AE CC 05 C8 10 2F 07 8C D6 00 00 00 00 00 00
| header | flags | parent address | ?? | transmit BSSID | unknown |The parent address is CE:10:2F:06:EE:AE, a derived address related to the router. Some time later, the mesh’s SON (Self-Organizing Network) daemon rerouted Satellite-2 through Satellite-1, and the IE changed:
00 01 03 00 01 00 00 CE 10 2F 07 6F 72 70 0A C8 10 2F 07 8C D6 00 00 00 00 00 00
| header | flags | parent address | ?? | transmit BSSID | unknown |The parent address flipped to CE:10:2F:07:6F:72, which is Satellite-1.
The six bytes at offset 7 flipped from CE:10:2F:06:EE:AE (a derived address related to the router) to CE:10:2F:07:6F:72 (a derived address related to Satellite-1). I confirmed this against three independent sources: the router’s SOAP API (GetAllSatellites showed the new ParentMac), the satellite’s own OpenWrt ubus interface (hop_count went from 1 to 2), and the beacon IE. All three agreed.
Three nodes, three IEs
Here’s the complete set of type=0 IEs from the 5 GHz beacons on my testbed, captured after the reroute:
Router (BSSID C8:10:2F:06:EE:AE): parent = all zeros (mesh root)
00 01 03 00 00 01 00 00 00 00 00 00 00 FF FF C8 10 2F 06 EE AE 00 00 00 00 00 00Satellite-1 (BSSID C8:10:2F:07:6F:72): parent = CE:10:2F:06:EE:AE (router)
00 01 03 00 01 00 00 CE 10 2F 06 EE AE FF FF C8 10 2F 07 6F 72 00 00 00 00 00 00Satellite-2 (BSSID C8:10:2F:07:8C:D6): parent = CE:10:2F:07:6F:72 (Satellite-1, daisy-chain)
00 01 03 00 01 00 00 CE 10 2F 07 6F 72 70 0A C8 10 2F 07 8C D6 00 00 00 00 00 00The parent field at bytes 7-12 is all zeros on the router (mesh root), and contains a derived address of the upstream node on each satellite. Bytes 15-20 match the transmitting BSSID in each capture. Bytes 4-6 differ between root (00 01 00) and satellites (01 00 00); the evidence supports “a role/flags field somewhere in bytes 4-6” but I can’t pin it to a single byte yet.
Field summary
Here’s my current decode with confidence levels:
| Offset | Size | Field | Confidence | Notes |
|---|---|---|---|---|
| 0-3 | 4 | Header/version | Medium | Always 00 01 03 00 in my captures |
| 4-6 | 3 | Role/flags | Medium | 00 01 00 on router, 01 00 00 on satellites |
| 7-12 | 6 | Parent address | High | All zeros = root. Non-zero = upstream node. Confirmed via SOAP, ubus, and reroute observation |
| 13-14 | 2 | Unknown | Low | FF FF on root and some direct links, CC 05 and 70 0A on others. Could be band, opclass, or path metric |
| 15-20 | 6 | Transmitting BSSID | High | Matches the BSSID of the beacon in all captures |
| 21-26 | 6 | Unknown | Low | Always zeros. Suspiciously MAC-sized; could be a grandparent or secondary-link field in longer chains |
A note on the parent address
The parent field carries a derived address, not the raw AP MAC or BSSID. The router’s LAN MAC is C8:10:2F:06:EE:AB, its WAN MAC is C8:10:2F:06:EE:AC, and the parent address that appears in satellite IEs is CE:10:2F:06:EE:AE. Several bits differ, not just the locally-administered bit. This is consistent with how WiFi 7 MLO separates AP MLD addresses from per-link BSSIDs, but I haven’t confirmed which specific address derivation scheme is in use. The defensible statement is that the parent field carries a derived address related to the parent node’s AP MLD identity, and you can correlate it across beacons because all nodes referencing the same parent will have the same six bytes.
What I don’t know yet
This is based on four captures from a single three-node Orbi testbed, all on 5 GHz. Open questions:
- Does the IE appear on 2.4 GHz and 6 GHz beacons from the same nodes?
- Does it appear on guest and IoT SSIDs, or only the primary?
- Is it in probe responses, or only beacons?
- What do bytes 13-14 encode? Experiments to try: same parent with different backhaul bands; same band with different RSSI; wired vs wireless backhaul.
- Do the trailing six zero bytes ever become non-zero in a longer daisy-chain (3+ hops)?
- Does the same IE structure appear on non-Orbi Qualcomm mesh gear? I’ve seen the
8C:FD:F0OUI on other QCA-chipset APs but haven’t yet confirmed the same payload structure.
If you have a Qualcomm-based mesh system and want to compare captures, I’m at [email protected].
Testbed details
- Hardware: Netgear Orbi WiFi 7: RBE771 router + 2x RBE770 satellites
- SoC: Qualcomm IPQ5332 (all nodes)
- Firmware: Router V10.5.10.10_2.2.29, Sat-1 V10.5.19.5, Sat-2 V10.5.10.10
- Capture: 5 GHz channel 40, macOS CoreWLAN scan, vendor IEs extracted via WiFiIEParser
Why I was looking
I’m building Network Weather, a Mac app for diagnosing home network problems. A lot of “why is my WiFi slow” turns out to be in the mesh layer: a satellite with a bad backhaul link, a topology change that added a hop, a node that’s overloaded. The mesh vendor apps show you a map but won’t tell you when things change or why your call just got choppy.
Being able to read mesh parentage from beacons means Network Weather can show you your mesh topology without you entering a router password. That’s the practical payoff here.
If you’re a router vendor and want to work with us on diagnostics for your customers, drop me a line.