Flock Camera Detection Arms Race: What Changed in 2026

If your Flock-You detector has gone quiet on a route that used to catch cameras every time, you are not imagining it, and your hardware probably is not broken. Flock Safety’s camera hardware and firmware have changed at least twice in the last year in ways that broke the community’s detection methods, and open-source researchers have had to reverse-engineer a new signature each time.

This is a fast-moving story. The detection method and OUI list below reflect the colonelpanichacks/flock-you main branch as of September 2026. Check the GitHub repository before assuming your device is defective.

The video above, from Valleytech Custom Solutions, documents exactly the symptom this article explains: a routine war drive that suddenly returns zero detections across multiple firmware builds, on a route where cameras were reliably detected before, in a county where several previously-flagged cameras had physically disappeared.

A War Drive That Suddenly Turned Up Nothing #

The pattern shows up the same way for almost everyone who reports it. A driver runs a route they have driven dozens of times. Their detector, running current firmware, has caught the same cameras before. Then, on one drive, it catches nothing. Not a single beep, not a single log entry, across every custom firmware build they try.

The Valleytech video above describes exactly this: a daily route to the post office that always registered at least one Flock camera stopped registering any, and a second route past Micro Center that used to flag five cameras now shows only one still active, with the other four physically uprooted from their poles.

Two things were happening on the same timeline, and it is easy to confuse them:

• Cameras are being physically removed or relocated in some areas, which genuinely reduces the number of devices there are to detect.
• The wireless signature the cameras broadcast has changed, which means even a camera still sitting on its pole will not trigger detection hardware running outdated firmware.

Two separate GitHub issues on the colonelpanichacks/flock-you repository, filed months apart, document the second problem in detail. Reading them in order tells the story of how the community’s detection method has had to evolve twice already.

Issue #20: The Management AP Went Dark #

Issue #20 , opened in January 2026, started with a familiar complaint: a user tested their device next to a known Flock camera, documented on DeFlock, and got nothing. Over the following weeks, more users piled on with the same result, from Florida to Indiana to Atlanta to the Midwest, using different hardware and different antennas.

One commenter asked the question that turns out to matter most: had Flock changed something on their end, in a way that broke detection for everyone at roughly the same time?

The project maintainer, colonelpanichacks, eventually confirmed exactly that. Around December 2025, Flock deactivated the management access point their cameras used to broadcast. That AP was the original basis for wireless detection. When it disappeared, the community pivoted to Bluetooth Low Energy (BLE) signals as a substitute. That substitute also stopped working reliably by spring 2026.

Every custom firmware built around the old AP or BLE detection paths is now looking for a signal the cameras stopped sending. That is why a device that used to work goes completely silent without anything being wrong with the hardware.

The Replacement Method: Wildcard Probes and Frame Fingerprinting #

The current flock-you firmware runs in dedicated 802.11 promiscuous mode. The radio never transmits and never joins a network. It only listens, hopping WiFi channels 11, 6, and 1 at a 250-millisecond dwell time to keep pace with how often the cameras themselves change channel.

A detection now requires all of the following to line up before the firmware alerts:

1. The frame is an 802.11 Management Probe Request (type 0, subtype 4).
2. The SSID Information Element is present with length 0, meaning it is a wildcard probe rather than one asking for a specific network.
3. The transmitter address (addr2) matches one of the known Flock OUI prefixes.
4. The rest of the frame’s Information Elements match the fingerprint pattern the DeFlockJoplin community documented, based on Pintor and Atzori’s 2022 research on WiFi probe request IE fingerprinting .

This method is named wifi_wildcard_probe_ie_sig in the firmware. Field testing by the DeFlockJoplin community caught 11 of 12 known cameras with only 2 false positives along their test route, the same field-verified baseline cited in the project’s own hardware guide . The 12th camera used an OUI that has since been added to the list below.

The Current OUI List #

The wildcard-probe fingerprint above only fires after the transmitter’s MAC address matches one of the OUI prefixes the community has confirmed against real Flock hardware. The list is maintained primarily by researcher @NitekryDPaul, with the 31st entry contributed by the DeFlockJoplin community after it caught a camera the original 30-entry list missed.

70:c9:4e  3c:91:80  d8:f3:bc  80:30:49  b8:35:32
14:5a:fc  74:4c:a1  08:3a:88  9c:2f:9d  c0:35:32
94:08:53  e4:aa:ea  f4:6a:dd  f8:a2:d6  24:b2:b9
00:f4:8d  d0:39:57  e8:d0:fc  e0:4f:43  b8:1e:a4
70:08:94  58:8e:81  ec:1b:bd  3c:71:bf  58:00:e3
90:35:ea  5c:93:a2  64:6e:69  48:27:ea  a4:cf:12
82:6b:f2

This list is not static. The upstream research notes several prefixes that were tested and then demoted (one turned out to be a Sony media player, another an early placeholder that never matched anything). Two entries are flagged as low-confidence and one, 82:6b:f2, is deliberately kept even though it is a locally-administered address, because filtering it out would have silently dropped a real, confirmed DeFlockJoplin detection.

If you maintain your own firmware fork, pull the OUI list from the upstream datasets/ folder rather than hardcoding a copy. The list changes as the research does, and a stale copy is a slow, silent way to start missing cameras again.

Issue #43: New SSID Pattern, 5GHz, and MAC Anti-Fingerprinting #

Three months after Issue #20 closed, a second report arrived that describes what looks like a deliberate anti-detection countermeasure rather than an incidental firmware change. Issue #43 , filed in May 2026, is built on WiGLE wardriving data captured against a camera already confirmed on DeFlock, and it documents three findings none of the existing tooling accounted for.

Finding 1: A Different SSID Format #

The documented Flock hotspot SSID has always followed the pattern Flock-XXXXXX. The camera in this report broadcast Flock Camera net. instead, a completely different naming convention. Anyone searching WiGLE for the Flock-* wildcard, as several researchers had been doing, would get zero results for this camera even though it was actively broadcasting.

Finding 2: A Confirmed 5GHz Hotspot #

The same camera broadcast simultaneously on 2.4GHz channel 1 and 5GHz channel 157, using sequential MAC addresses on each band (...9f:a2:de and ...9f:a2:df), which points to a single dual-band WiFi module assigning adjacent addresses to each radio rather than two unrelated devices. A separate, independent report from researcher nsm_barii had already logged a Flock probe request on 5GHz channel 149, so this is now two data points confirming 5GHz operation is real and not a one-off misconfiguration.

Every detection method described earlier in this article, including the current wildcard-probe firmware, only listens on 2.4GHz. A camera broadcasting exclusively (or primarily) on 5GHz is invisible to that hardware regardless of OUI list accuracy.

Finding 3: Locally Administered MAC Addresses on the Hotspot #

Both captured MAC addresses have the locally administered bit set, meaning they were not assigned from Flock’s real IEEE-registered OUI block. The standard flock-you detection logic deliberately skips locally administered addresses, because that is the standard way to filter out MAC-randomizing phones and laptops.

That filter, which exists specifically to reduce false positives, means a Flock camera using a locally administered MAC on its hotspot interface gets filtered out by the exact same logic meant to clean up noise. The sequential last bytes on the two captured addresses rule out random generation, which is what makes this look like intentional, structured address assignment rather than coincidence.

SSID-based matching is the one method in this table that keeps working regardless of which band the camera uses or how its MAC address is assigned. That is the practical argument for adding broader SSID pattern support rather than relying on OUI matching alone.

Is Flock Deliberately Evading Detection? #

Neither GitHub issue proves intent, and it is worth being precise about that. Issue #43’s own author raised it as an open question rather than a conclusion: is this consistent across Flock’s deployments, or specific to one firmware version on one camera?

But look at the pattern across both issues together. A detection surface goes dark. The community finds a replacement. The replacement’s blind spots (2.4GHz-only scanning, OUI-based matching, filtering out locally administered MACs) line up closely with exactly the properties a new SSID format, a 5GHz radio, and a locally administered MAC address would exploit. That could be coincidence produced by an unrelated firmware upgrade cycle, or it could be a vendor tightening its own wireless footprint in ways that happen to break third-party detection as a side effect, intentional or not.

The most useful stance is not to argue which one it is. It is to build detection that does not depend on any single assumption holding forever, because on this project’s own two-year track record, none of them have.

What This Means for Your Detection Hardware #

If your device has gone quiet, work through this checklist before assuming it is broken:

1. Update your firmware first. If you are running anything older than the current main branch, you are likely still looking for the deactivated management AP or dead BLE beacons. Pull the latest firmware and reflash.
2. Confirm the camera is still there. Some of the “zero detections” reports turned out to be genuinely uprooted or relocated hardware, not a detection failure. Cross-reference against Flock Finder or DeFlock before troubleshooting your device.
3. Slow down at intersections. The 250ms channel-hop dwell means a fast pass carries you past a camera’s detection window before your radio lands on the right channel. A 30-60 second stop catches far more cameras than a fast drive-by with a bigger antenna.
4. Report what you see. A confirmed zero-detection result next to a visually verified camera is exactly the kind of data point that turned into Issues #20 and #43. Open a new issue rather than assuming someone else already reported it.
5. Know the current limits. WiFi-only, 2.4GHz-only firmware will not see a camera that has moved to 5GHz or gone quiet on the bands it scans. That is a real gap right now, not a bug in your specific build.

None of this makes the hardware pointless. The OUI list and wildcard-probe fingerprint still catch the overwhelming majority of deployed cameras today. It means treating any detector, DIY or purchased, as a snapshot of the current arms race rather than a permanent solution.

Shop Now — Save up to 20% Today Code: SIMEONONSECURITY

What the Community Is Doing About It #

The response to both issues followed the same pattern that has kept this project useful for two years: someone reports a gap, someone else contributes the fix, and the fix ships as an update rather than sitting in a backlog.

• Issue #20 ended with a confirmed root cause and a firmware rewrite around the wildcard-probe signature, credited to the DeFlockJoplin community’s field research.
• Issue #43 remains open as of this writing, with the SSID pattern-matching suggestion still pending implementation. If you want to help close that gap, the fix (adding Flock Camera as an additional match pattern) is a small, well-scoped contribution for anyone comfortable with the firmware’s match logic.
• The underlying OUI dataset is versioned and dated in the repository, with demoted and low-confidence entries documented rather than silently dropped, so anyone forking the project sees exactly what changed and why.

This is the practical case for open-source detection tooling over a closed-source alternative. A proprietary detector cannot be patched by the person who found the gap. This one already has been, twice.

Conclusion: Detection Is a Moving Target, Not a Fixed Answer #

A silent detector on a route that used to catch cameras is not proof your hardware failed. It is evidence that the wireless signature it was built to recognize has changed, again, in a pattern that has now repeated twice inside a single year. The management AP, BLE beaconing, and now potentially the 2.4GHz-only, OUI-only assumptions baked into the current firmware have each had a limited shelf life.

The fix has never been to give up on wireless detection. It has been to keep the detection method’s assumptions visible, documented, and open to correction the next time a report like Issue #20 or Issue #43 comes in. That is the argument for open-source firmware over any closed alternative: the fix ships as soon as the community finds the gap, not on the vendor’s schedule.

Key Takeaways #

• Two documented detection surfaces have already gone dark: the management WiFi AP (deactivated around December 2025) and BLE beaconing (unreliable by spring 2026).
• The current method, wildcard probe requests plus OUI and IE fingerprint matching, has a field-verified 11-of-12 detection rate, but it is WiFi-only and 2.4GHz-only.
• A pending report describes a new SSID format, a confirmed 5GHz hotspot, and locally-administered MAC addresses that the current OUI-based, 2.4GHz-only method cannot see.
• A zero-detection result on a known camera does not automatically mean your hardware is broken. Update your firmware first, then confirm the camera is physically still there.
• This is an open-source project that keeps shipping fixes as the community finds gaps. Read the GitHub issues, not only the README, to know the current state of detection.

Next Steps #

1. Update your firmware to the current main branch before troubleshooting anything else: github.com/colonelpanichacks/flock-you
2. Read the full hardware guide if you have not already: Flock-You Detection Project: Counter-Surveillance Hardware Guide
3. Cross-reference suspected dead zones against Flock Finder before assuming your device missed something
4. Understand what you are up against: Flock Safety Camera Surveillance: Prevalence, Privacy Concerns, and Protection Strategies
5. Pair WiFi detection with cellular detection using Rayhunter for a fuller counter-surveillance picture, since none of this article’s methods detect cell-site simulators

Related Articles #

References #

1. Flock-You GitHub Repository - colonelpanichacks
2. GitHub Issue #20 - Flock cameras not detected, but other devices detected
3. GitHub Issue #43 - 5GHz signal? New OUI / MAC address filtering
4. NitekryDPaul OUI Research Dataset
5. nitekry/nite-oui-collection
6. DeFlock Joplin - Community ALPR Research
7. Pintor, L. & Atzori, L. (2022) - Analysis of Wi-Fi Probe Requests Towards Information Element Fingerprinting, IEEE GLOBECOM
8. The Hunt for the Hidden Probe - Hidden SSID Wildcard Probe Behavior
9. DeFlock - Crowdsourced ALPR Camera Map
10. Colonel Panic Tech - OUI-SPY and Detection Hardware
11. STS Collective - FlockYou Devices
12. Something Strange Is Happening With Flock Cameras - Valleytech Custom Solutions