Wi-Fi Module v1 with Companion FW ch0 h0 and no error

[wiilover22]

So I'm using a Wi-Fi Module v1, which I bought with the flipper many years back. I'm able to successfully flash the wroom firmware, but when I launch the app and run the Flock / ALPR Detect...the ch stays 0, and nothing on the screen changes. I also get no errors saying something isn't working =\

How should I go about pulling some kind of error log or live debug?

Edit: adding info and picture (to verify I don't have some strange knockoff):
App: FlipDeFlock v0.83 Nightly
Unleashed FW: unlshd-092e [22-08-2026]

Originally posted by @wiilover22 in #20 (comment)

Well, the new changes and firmware "appear" to be working - however after driving past a few known ALPR's, the app didn't pick anything up. I'm not sure this is an issue related to the RPC GPS - so I'll probably have to start a new issue.

[ReconGrunt]

The ch 0 is the tell. That means the app never got a single status line from the board, so the companion firmware was not running or not reaching the UART. It was not scanning and finding nothing, it was not talking at all.

Turned out to be the chip. The Wi-Fi Module v1 is an ESP32-S2, and the S2 has no Bluetooth radio, so the Arduino core ships no BLE library for it and the companion sketch did not compile for that target at all. It died on BLEAddress. So it was never a binary we forgot to publish, the firmware genuinely could not run on your board, and flashing the WROOM image just left you with something that came up and stayed silent.

Fixed in v0.86. All the Bluetooth code now sits behind a capability flag, so the sketch builds Wi-Fi only on chips without the radio, and CI builds and releases flipdeflock_companion_esp32s2.bin next to the WROOM one. It attaches on tagged releases, so grab it from the next release, or from the Actions artifact on the ESP32 workflow if you want it right now.

One thing to be clear about before you flash it: that build is degraded on purpose. Probe and OUI camera detection work exactly as they do on any other board, but the BLE half of Flock detection is gone permanently, because the hardware cannot do Bluetooth. The app now shows "WiFi only" in its header when it sees that SoC, so you can tell which you are running. A classic ESP32 WROOM is around five dollars and does the whole job if you would rather have full coverage.

Also worth grabbing v0.86 for another reason. It writes a per-session diagnostic to apps_data/flipdeflock/diag.csv with the companion frame and hit counters next to the app side counts. If esp_lines is 0 in that row it confirms nothing ever came up the wire, which is what your case would have shown immediately instead of an empty screen with no error.

Reopen if the S2 build still sits at ch 0 and I will dig in.

[wiilover22]

Seems like everything is working. I'll update this comment once I test it successfully against an ALPR.

I was afraid I was doing something wrong at first, since I thought the Wi-Fi Module v1 was supported >.< Glad I mentioned something.

I've bought a standalone ESP32-WROOM, that I guess I'll have to simply use dupont cables to connect to the flipper. Was looking for a slightly more elegant plug-in solution, like the original Wi-Fi dev board...oh well.

Update: Drove past several active ALPR's, still no hit. Perhaps the tiny onboard antenna on the dev board isn't enough, or this app is more biased towards using BT for detection? Not sure. I was within 15ft for about a minute. I'll update this comment a second time if anything new happens...otherwise /shrug

[wiilover22]

Is there a chance that despite the UI "looking" like everything is working...it's not? Pretty sure I was close enough this time, for well over 10 minutes =P

I never once got an update/hit on the app, and I drove past an additional 10+ cameras x.x There's too many.

[ReconGrunt]

Working on this today and doing a deep dive. There could be a few things going on so the easiest way to help me since I don't have a v1 Wifi module is to send over the diagnostic CSV (reports take OPSEC into account and redact any personal identifiers, you can copy/paste it directly as a reply)
It could be any of these:

1. An incorrect GPIO setting on your end that isn't throwing errors. Can you confirm that the pin-out is correct for your board so we can rule that out?
2. The actual ALPR itself isn't broadcasting anything (which is a win IMO lol)
3. FDF's channel hopping isn't working properly with the Flipper Wifi Module
4. I introduced a bug in the code which caused a regression. The whole code is getting a full-sweep as we speak to rule this out.

[h00die]

Is the v1 running marauder and what version?

[wiilover22]

Is the v1 running marauder and what version?

No, I was running the latest .86 nightly with the new s2 companion firmware flashed.

Can you confirm that the pin-out is correct for your board so we can rule that out?

Sure, I'll update this post later. An ESP32-WROOM just arrived in the mail today, and I've successfully flashed the WROOM firmware. I'll also update this post after driving past some ALPR's. Then I'll know for sure there's some kind of bug with the v1 board...even though I'm less inclined to look into it now lol - But I'll try to figure out how to grab a diagnostic CSV sometime.

Edit1: Wanted to add - I've used the ESP32 wifi marauder app, and firmware successfully together to scan for AP's, and log information...so I guess that means the pinout is correct, and the device does work correctly.

[ReconGrunt]

Thanks for confirming the Marauder bit, that was the useful detail. It rules out the pinout and the board, so whatever is wrong is on our side.

Here is where I landed. Your board comes up healthy, counts a channel, throws no errors, and detects nothing. A promiscuous receive callback that never fires looks exactly like that from the outside. Our setup puts the radio in WIFI_MODE_NULL before turning promiscuous on, which is the normal way to do it on a classic ESP32 and is well proven there, but it is not guaranteed to actually deliver packets on the S2. STA mode is the portable form.

So there is an S2 build with that changed, in the nightly:

https://github.com/ReconGrunt/FlipDeFlock/releases/tag/nightly

Grab flipdeflock_companion_esp32s2_UNVERIFIED.bin and flash it to the v1 module. Pair it with the nightly .fap for your firmware from the same release.

Being straight with you about what this is: nobody here owns an S2, so I could not test it. It is a hypothesis I could reason my way to but not verify, which is why it is a nightly with UNVERIFIED in the filename rather than a release. The change is gated to the S2 alone and I checked the classic image comes out byte for byte identical, so nobody else can be affected either way.

Whether it works or not, the thing that actually answers this is one number. After a scan, grab apps_data/flipdeflock/diag.csv off the SD card and paste the last row. The column to look at is esp_frames:

• climbing, with esp_hits at 0, means the radio is capturing fine and the problem is in what we score, or those particular cameras are not emitting what we match on
• at or near 0 means the capture never ran at all, which is this bug

Those point in completely opposite directions and I cannot tell them apart from here. Counts only in that file, no MACs, no SSIDs, no positions, so it is safe to paste as is.

No rush, and if you would rather just use the WROOM now that it has arrived, that is entirely fair. Even one diag row from the v1 before you shelve it would help, since you are the only person testing that board.

[wiilover22]

Huh...well now I'm extra confused. I just did a quick drive past 2 ALPR's, doing at least 5 passes total...one of which I sat at a traffic light for 30s with the window open and the WROOM searching with FlipDeFlock running...and I never got a hit.

I just loaded the 0.87 firmware on my v1 dev board, and here's the .csv info:

# FlipDeFlock session diagnostics v1 -- counts only, no MAC/SSID/position
start,end,dur_s,ver,backend,band_req,band_act,band_ch,proto,esp_lines,esp_dropped,esp_reboots,esp_frames,esp_hits,reports,accepted,rej_conf,rej_full,table
1788560087,1788560103,16,v0.86,0,0,0,13,1,21,0,0,220,0,0,0,0,0,0
1788560141,1788560149,8,v0.86,0,0,0,13,1,14,0,0,92,0,0,0,0,0,0
1788614458,1788614459,1,v0.86,0,0,0,13,1,7,0,0,0,0,0,0,0,0,0
1788614467,1788614992,525,v0.86,0,0,0,13,1,553,0,0,11015,0,0,0,0,0,0
1788617191,1788617200,9,v0.86,0,0,0,13,1,16,0,0,317,0,0,0,0,0,0
1788617218,1788617935,717,v0.86,0,0,0,13,1,734,0,0,18656,0,0,0,0,0,0
1788623730,1788624794,1064,v0.86,0,0,0,13,1,1072,0,0,11975,0,0,0,0,0,0
1788624794,1788625173,379,v0.86,0,0,0,13,1,385,0,0,7942,0,0,0,0,0,0
1788625406,1788627269,1863,v0.86,0,0,0,13,1,1880,0,0,83916,0,0,0,0,0,0
1788627270,1788627277,7,v0.86,0,0,0,13,1,14,0,0,105,0,0,0,0,0,0
1788627278,1788629253,1975,v0.86,0,0,0,13,1,1990,0,0,28034,0,0,0,0,0,0
1788724824,1788724834,10,v0.86,0,0,0,13,1,16,0,0,68,0,0,0,0,0,0
1788725829,1788725875,46,v0.86,0,0,0,13,1,114,0,0,263,0,0,0,0,0,0
1788728899,1788729899,1000,v0.86,0,0,0,13,1,1496,0,0,6778,0,0,0,0,0,0
1788729900,1788730822,922,v0.86,0,0,0,13,1,1499,0,0,5836,0,0,0,0,0,0
1788730826,1788730829,3,v0.86,0,0,0,13,1,9,0,0,35,0,0,0,0,0,0
1788730973,1788731012,39,v0.86,0,0,0,13,1,48,0,0,271,0,0,0,0,0,0
1788731017,1788731022,5,v0.86,0,0,0,13,1,14,0,0,0,0,0,0,0,0,0
1788731037,1788731039,2,v0.86,0,0,0,13,1,9,0,0,14,0,0,0,0,0,0
1788731614,1788731616,2,v0.87,0,0,0,13,1,7,0,0,0,0,0,0,0,0,0
1788731633,1788731646,13,v0.87,0,0,0,13,1,20,0,0,252,0,0,0,0,0,0

I'm really confused now why the WROOM also didn't get any hits...

Edit1: Side question - are there pros/cons to using 3.3v vs 5v for the WROOM?

[ReconGrunt]

That CSV answered it, and it says I was wrong. Thank you for pulling it.

esp_frames is 83,916 over 31 minutes in one of those rows, and every other session shows healthy counts too. Your radio was capturing the entire time, on the v1 and on the WROOM. So the promiscuous-mode theory I gave you was wrong, and the S2 nightly I asked you to flash does not fix anything. Do not waste a drive on it. I should have asked for this file before I shipped a guess.

What the numbers actually say is narrower and more useful: the companion saw tens of thousands of management frames and not one of them scored above zero. esp_hits counts ANY candidate at all, so zero means nothing you drove past matched anything we ship. Not a weak match, nothing.

There are two ways that happens, and this codebase already warns about the second one in its own comments:

1. Those cameras are on hardware whose OUI is not in our list.
2. They have moved to randomised MACs, which collapses the entire OUI ladder. The designed answer to that is a probe fingerprint table, and it currently ships empty.

Either way the detector cannot tell you, because it only ever reports what it already recognises. A camera we do not have a signature for and an empty street produce identical output. That is the actual bug here, and it is ours.

So there is a survey mode in tonight's nightly:

https://github.com/ReconGrunt/FlipDeFlock/releases/tag/nightly

Flash flipdeflock_companion_esp32wroom.bin to the WROOM (or the S2 image for the v1, both have it) and take the matching .fap. It records EVERY device sending wildcard probe requests, matched or not, with its MAC, signal, channel, a sighting count, and an IE fingerprint. After a scan it writes apps_data/flipdeflock/survey.csv.

The useful thing to do with it: park where you can SEE a camera, scan for a few minutes, then look at the file. A camera probes roughly every 125 ms and does not stop, so it shows up with a count in the hundreds while phones sit at 1 to 6. On my bench a known transmitter came out at count 124 while everything else was under 7, so the signal is not subtle.

The fingerprint column is the one that matters most. It is computed from the probe body rather than the address, so it survives MAC randomisation. My first capture caught one fingerprint appearing on four different randomised MACs, which is a single device tracked straight through its own rotation. If your cameras are randomising, that column is what will catch them, and it is what would let us finally populate the fingerprint table.

survey.csv is counts and signatures only. No SSID, no position, same as the diagnostic file.

If you get a row with a big count next to a camera you can see, paste it and we will have the signature we have been missing.

[ReconGrunt]

Missed your side question, sorry.

3.3V vs 5V on the WROOM: feed 5V into the VIN / 5V pin and let the board's own regulator make the 3.3V. That is what the regulator is there for.

The 3V3 pin bypasses it and wires more or less straight to the module. That only works if your 3.3V source is clean AND can deliver the current, and the current is the catch: the ESP32 is a low-draw part right up until the radio transmits, then it pulls short spikes of roughly 250 to 350 mA. A rail that sags under those spikes browns the module out mid-transmit, and you get resets or intermittent behaviour that looks like a software bug and is miserable to chase. The Flipper's 3.3V pin in particular is not built to source that.

And the one that actually kills hardware: never put 5V into 3V3. The regulator is not in that path, so it goes to the module directly.

Two Flipper-specific notes:

• The 5V pin only has power when the 5V rail is on. FlipDeFlock turns it on for you if Settings > Auto 5V for ESP is enabled, which it is by default, so you should not need to visit the GPIO menu first.
• That rail is a boost converter off the battery and it cannot run while the Flipper itself is plugged into USB. On USB the header takes its 5V from the host instead. So if you are testing at a desk with a cable in, that is normal and it is still powered.

Worth adding, since it is relevant to your actual problem: your CSV already rules power out. esp_reboots is 0 in every single row, including the 31 minute session. A companion that was browning out would be resetting, and yours never did once. So whatever is going on with the missing detections, it is not a supply issue.

[wiilover22]

After a scan it writes apps_data/flipdeflock/survey.csv.

Unless I've done something wrong, there's no survey.csv being made. I'm running the new .88 version. diag.csv is being written to correctly, so idk what's wrong on my end.

1788776132,1788776139,7,v0.88,0,0,0,13,1,17,0,0,17,0,0,0,0,0,0
1788777066,1788777080,14,v0.88,0,0,0,13,1,23,0,0,155,0,0,0,0,0,0
1788777138,1788777164,26,v0.88,0,0,0,13,1,36,0,0,542,0,0,0,0,0,0

Glad I checked right before wasting my time going out on a drive =\

Edit: Using the WROOM with matching companion firmware

[ReconGrunt]

You did not do anything wrong. That was our bug, and thank you for checking before you drove.

The survey only asked the companion for its table once when a scan opened, at which point the board has nothing yet, and then not again for thirty seconds. Then the save gave up early because there were no rows, so no file was created at all. Your sessions were 7, 14 and 26 seconds. Every one of them was under that interval, so every one produced nothing, and there was no way for you to tell a feature that had not run from one that was broken. I only ever tested it with one long scan, which is exactly why I did not catch it.

Fixed in tonight's nightly:

https://github.com/ReconGrunt/FlipDeFlock/releases/tag/nightly

The survey is now pulled one last time before the link closes, which is the only moment the whole session exists and the link is still there to carry it. The periodic poll is down to ten seconds and no longer wastes its first request on an empty table. And the file is written even when nothing was seen, so you will always get a file, with a header and no rows if the air was quiet. Verified with a 7 second scan, which is shorter than any of yours.

While testing that I found a second bug that mattered more, because it would have sent you after the wrong device. The counts live on the companion and it kept counting until it was power-cycled, so they were "since the board booted" rather than "this scan". On my bench a neighbour's device was sitting at 729 purely from accumulating over hours. That directly contradicts the advice I gave you, which was that a count in the hundreds is your camera -- an ordinary phone would have looked exactly like one. The board's table is now cleared at the start of every scan, so the numbers mean this outing and nothing else.

With that fixed, here is what the method actually looks like on my bench with a known transmitter running: it comes out at 94 over a three minute scan while everything else nearby sits between 1 and 16. Over a 7 second scan it was 9 against 1. So it is the ratio to its neighbours that identifies it, not a fixed number, and you do not need a long scan for it to show.

Grab the WROOM image and matching .fap from that nightly. Park where you can see a camera, scan for two or three minutes, then send the file. If a row stands well above the others, that is the signature we have been missing, and the fingerprint column is what would let us catch it even if the MAC is randomized.
I'm genuinely interested to see why you aren't getting any hits, I've got plenty of ESP-32 WROOMS to test on so I'll try to get some readings as well and diagnose it.

Sorry for the runaround on this one. You have now found two real bugs for us and neither of them should have reached you.

[ReconGrunt]

There's a proper release now, so you can stop using the nightly: https://github.com/ReconGrunt/FlipDeFlock/releases/tag/v0.89

One thing that will look wrong. The nightly I pointed you at was built from code stamped 0.90, and this release is v0.89, so it looks like a downgrade. It isn't. I'd been bumping the version internally without ever cutting a tag, and the numbers had drifted five versions ahead of what was actually released. v0.87 was the last real tag, so this picks up from there. v0.89 is newer than anything you have.

Grab flipdeflock.fap (or the one for your firmware) and flipdeflock_companion_esp32wroom.bin. Both survey fixes are in it, plus the counts are per scan now instead of counting up since the board was last powered on.

While testing this I found a few more things that were biting you and I hadn't spotted:

Every export was tagged as a Flock ALPR camera no matter what it actually was, so if you'd sent in a GeoJSON with an Axon pole or an acoustic sensor in it, it would have gone onto the map as a Flock camera. Fixed.

Exports are also redacted by default now. The redacted version keeps the camera coordinates and replaces anything that isn't a Flock name with its shape, so you can attach one to an issue without thinking about it. There's a RAW option if you want the full thing for yourself, and it puts _RAW in the filename but still verify before sending it out.

The companion firmware reports its own version now, and the ESP32 Firmware screen shows it. That was the thing I couldn't answer earlier when you asked what was on your board.

If you get a chance to do that drive, the survey file is still what I'm most interested in but no pressure. I'll do a drive later myself today.

Edit: I'll keep this issue open until it's been confirmed as resolved :)

[wiilover22]

Just got back from being out, was able to grab a quick log before heading home. Didn't stop too long, but hopefully this info helps. I parked near (within 50ft) of a camera, sat for about a minute, then drove off and past a second camera. Turned the flipper off after leaving the range of the second camera. Assuming the 06:FC MAC is the first camera? Without more info, it's hard tell =\

This is with the nightly build (didn't get home before your latest post) not the proper release.

diag.csv

start,end,dur_s,ver,backend,band_req,band_act,band_ch,proto,esp_lines,esp_dropped,esp_reboots,esp_frames,esp_hits,reports,accepted,rej_conf,rej_full,table
1788811782,1788811914,132,v0.90,0,0,0,13,1,268,0,0,319,0,0,0,0,0,0

survey.csv

mac,rssi,channel,ie_fp,count
06:FC:CB:3A:F8:9E,-26,3,89c3debf,10
7E:68:F0:04:F6:6B,-87,5,96fcd1b2,1
7E:68:F0:8E:5A:48,-77,6,96fcd1b2,2
7E:68:F0:B0:CE:FB,-82,6,96fcd1b2,1
7E:68:F0:80:2E:5C,-79,7,96fcd1b2,1
7A:B2:1B:2C:F2:AD,-37,8,ba9fafa0,2
F8:D2:AC:C5:97:AC,-87,6,c4e51f77,1

Edit: Potential future note for myself - 7A:B2 might be the second camera.

[ReconGrunt]

This is the most useful thing anyone has sent me on this issue. It answers the original question.

Look at the first octet of every MAC in your survey:

06:FC:CB:3A:F8:9E   0x06   locally administered
7E:68:F0:04:F6:6B   0x7E   locally administered
7E:68:F0:8E:5A:48   0x7E   locally administered
7E:68:F0:B0:CE:FB   0x7E   locally administered
7E:68:F0:80:2E:5C   0x7E   locally administered
7A:B2:1B:2C:F2:AD   0x7A   locally administered
F8:D2:AC:C5:97:AC   0xF8   real vendor OUI

Six of the seven have bit 1 set in the first byte, which means the address is locally administered. It's made up. There is no manufacturer behind it, so there is nothing for an OUI table to match. Every project doing this, including ours, is matching MAC prefixes against a list of vendors, and a randomised address defeats all of it before scoring even starts.

So "no hits" wasn't a bug in the end. Your board was working the whole time. The cameras just aren't announcing a vendor any more.

Which row is the camera

06:FC:CB:3A:F8:9E almost certainly. It's at -26 dBm, which is very close, matching the 50ft park, and it probed 10 times while nothing else in the file managed more than 2. That's the ratio I described, and it showed up over roughly a minute of sitting still.

Your guess about 7A:B2:1B:2C:F2:AD for the second one is reasonable. -37 dBm is strong and 2 probes is what you'd expect from driving past instead of parking. It's thinner evidence, but it fits.

F8:D2:AC is Vantiva, who make ISP routers and set-top boxes, at -87 dBm. That's a neighbour.

Don't chase the 7E:68:F0 group

Four addresses, all different, all carrying the same fingerprint 96fcd1b2. That's one device rotating its MAC, and I can tell you exactly what that fingerprint is because my bench emitter produces it: it's the IE layout of a plain ESP32 doing an ordinary WiFi scan. A featureless probe request. Phones and IoT gear generate it constantly.

If I'd added that to our tables on the strength of "four devices near a camera", it would have matched half the phones in any street. Worth saying out loud since it looked like the most interesting cluster in the file.

The fingerprint is the way out

ie_fp is a hash of the shape of the probe request, the order and sizes of its information elements. It has nothing to do with the address, so it survives randomisation. 89c3debf appears once in your file, on the device I think is the camera, and matches nothing else.

You can test that right now without waiting for a build. Make a file called signatures.json in apps_data/flipdeflock/ on the SD card:

{
  "ie_fps": ["89c3debf", "ba9fafa0"]
}

It's load-only and offline. A user fingerprint is capped at "Class?" and can never reach Confirmed, so it can't over-claim on you.

Then go back to the same camera. If 89c3debf turns up again on a different MAC, that's the proof: the fingerprint is tracking the camera and not the address, and it's a signature we can ship for everyone. If it comes back with a different fingerprint too, then the model randomises its IEs as well and we need another angle.

That one test is the whole thing. No rush on it, it could give us more valuable data. I'll release a build that does just that for this session if you feel hesitant towards getting a signatures.json on there. I might implement as a permanent features so everyone's individual version of FDF will have a "self learning feature".

Your diag looks healthy

268 lines, 0 dropped, 0 reboots, 319 management frames in 132 seconds. The board and the link are both fine, which is worth knowing given how much of this thread was spent wondering whether your hardware was the problem. It wasn't.

Also grab v0.90 when you get a chance. Since the nightly you're on, there's a fix for the 5V rail never coming up when the Flipper is plugged in, which would leave a header board dead.

Edit: Just to be sure that the cameras are spitting out randomized macs, have you gotten any hits using other Flipper apps or previously got hits from FDF on those cams? If they spit out random mac addresses, there might be a way to have FDF tag them depending on the way they rotate them. Very interesting. And thank you for the CSVs, any data helps me improve FlipDeFlock.

[ReconGrunt]

In the meantime I'm going to mark this issue as closed since the original companion issue has been solved. If any issues persist or new ones arise, please let me know and it'll be taken care of pronto :)

[wiilover22]

In the meantime I'm going to mark this issue as closed since the original companion issue has been solved.

Oh - ok? I mean neither the v1 S2 or WROOM board is detecting cameras correctly...which I thought we were still figuring out...but I guess I'll open a new issue when I have some more time.

I'll try the same camera tomorrow morning. I'll update to w/e the latest build is by then.

Been super busy, guess this will be the start of the new issue. Should have some time later today to sit near a camera.

[ReconGrunt]

The Flock camera introduced a rotating mac address as mentioned above. If you pick that camera up with another app, then it'll be confirm an issue on my end but FDF is clearly picking the camera up, it's just not confirming it because the camera isn't announcing a vendor anymore. Not a board issue or app issue, most likely due to Flock trying to become harder to detect but thats where fingerprints come in. I'll gladly eat my words though if I'm wrong.

[wiilover22]

The Flock camera introduced a rotating mac address as mentioned above.

Is this something new? Like...am I the first person to have found a camera with rotating MAC's? Is there just really few people who actually use this project? Figured with 77 stars, and the increasing public awareness...I couldn't possibly be the first person to use this app, and not have it detect over 8 different known ALPR's, from at least 2 different brands...

[h00die]

I've noticed that flocks in the parking lot of one big brand/box store never show up. Their competitor has the same cameras and they do show up. Why? Unknown. I went to two different store locations a few hours driving apart and it was the same behavior, so likely not isolated. I've speculated in a different post that you'd need to bring a wifi card and dump traffic from every(?) chanel for a few minutes to try to determine if it was still using wifi still as I don't see a hardwire cable.

As for using other apps, there is a similar app I originally compared this app to. However, I stuck around here because the PR and issues I brought up on the other app were ignored. Seems to be abandonware. As for people around, I'm here. As for wider spread adoption, it's tough. Not only would people need a flipper zero, but then another card on top of that. Maybe they bought the wifi card, but that's not as good. If they got the card I have, you also need a companion board for the card. That's 2 purchases from different vendors just to run this (and that other) app. Not as trivial as you'd hope. Maybe flipper one will be AIO for this purpose.

[ReconGrunt]

Fixed in v0.93, and the fix turned out to be bigger than the fingerprint idea.

Two things were wrong.

First, you could never have seen that camera on the screen. The app drops anything scoring nothing before it reaches the list, and a randomised MAC scores nothing, so a camera with no vendor prefix was being binned silently. That is why ten cameras gave you an empty screen. The survey already had the answer in it, but it only existed as survey.csv, so the only way to use it was to pull the card and have someone read the file. Which is what we did.

There is now an Air Survey screen on the main menu. Same data, on the device, ranked the way I read your CSV by hand: how hard a device is probing compared to everything else in that capture, how close it is, and whether one fingerprint is showing up on several addresses. ~ means a randomised address, g a common scan pattern shared with phones. In your capture the camera would have sorted to the top and the four 7E:68:F0 rows to the bottom.

It is not a detection list and nothing in it enters the hit table. It tells you where to point your eyes.

Second, when I told you to use "Confirm: I saw it" on the row you thought was the camera, that would not have worked. That button only exists on detections, and your camera never became one. It works on a survey row now, so the loop I described is actually closed.

A bug worth knowing about too: confirming a row wrote whatever fingerprint it carried, with no check. If you had picked one of the 7E:68:F0 rows you would have taught your app 96fcd1b2, the stock ESP32 scan pattern, and it would have started flagging phones at you permanently. That is refused now, along with two others, and the check runs at match time as well, so if one is already on your card it goes inert when you update.

Your 89c3debf and ba9fafa0 are still tracked as candidates. Neither ships, because one sighting is not evidence. If you get back to that camera, what I still want is 89c3debf on a different MAC. That is the proof the fingerprint tracks the camera and not the address.

Grab v0.93 plus the companion .bin for your board. Thanks for sticking with this one, the CSV is what made it solvable.

[wiilover22]

Grab v0.93 plus the companion .bin for your board. Thanks for sticking with this one, the CSV is what made it solvable.

Alright...I'll test that version later. I still have signatures.json that I manually made with those 2 signatures...so I guess we'll see what happens.

[ReconGrunt]

I've noticed that flocks in the parking lot of one big brand/box store never show up. Their competitor has the same cameras and they do show up. Why? Unknown. I went to two different store locations a few hours driving apart and it was the same behavior, so likely not isolated.

Worth ruling out the boring explanation before anything clever. I had a run of cameras near me that I could not get a hit on either, so I pointed a camera at them to see whether the IR illuminator fired on motion. It did not. They were not powered on at all. Two sites a few hours apart makes that less likely in your case, but it costs nothing to check and it would save you a lot of chasing.

I've speculated in a different post that you'd need to bring a wifi card and dump traffic from every(?) chanel for a few minutes to try to determine if it was still using wifi still as I don't see a hardwire cable.

That is roughly what v0.93 does now, without the laptop. There is an Air Survey screen that lists every wildcard-probe transmitter the board heard, matched or not, ranked by how persistently it probes compared to everything else in that capture, how close it is, and whether one fingerprint keeps turning up on different addresses.

So the box store question is directly readable in the field: park, run a scan, open Air Survey. If nothing is sitting there probing, it is not talking wifi and no amount of signature work will ever find it. If something is there and we simply do not recognise it, you get a row instead of an empty screen. That distinction did not exist before, which is most of why this thread ran as long as it did.

Rotating MACs are a much smaller problem now too. Confirming a row you have physically looked at teaches the app that unit's probe fingerprint, which hashes the shape of the request rather than the address, so it survives the MAC changing. Learned signatures stay capped at Class? and can never auto-confirm, and commodity scan patterns are refused outright. Accuracy is the golden rule here, and I would rather miss a camera than hand you a list of phones.

As for using other apps, there is a similar app I originally compared this app to. However, I stuck around here because the PR and issues I brought up on the other app were ignored.

Noted, and thanks for staying. Issues and PRs here get answered.

As for wider spread adoption, it's tough. Not only would people need a flipper zero, but then another card on top of that. [...] That's 2 purchases from different vendors just to run this (and that other) app. Not as trivial as you'd hope.

Agreed, and it is the thing I keep coming back to. I am working on a standalone version that runs entirely on one device, no Flipper and no companion board. It works as expected on the bench and I am waiting on supplier quotes before I put a date on it. The whole point is the gap you just described: someone who is never going to source two boards from two vendors and wire them together should still be able to use this.

[wiilover22]

So I sat near that same camera again, glad I copied the survey.csv to my phone before starting a new search...since it got overwritten, because when I was scanning again later on down the road - where I drove past a new set of cameras (in a nearby town interestingly enough) - I got a hit.

Here's the survey.csv from the original "undected camera"...looks like the same MAC:

mac,rssi,channel,ie_fp,count
06:FC:CB:3A:F8:9E,-21,8,89c3debf,8
E2:CE:F4:61:64:96,-33,4,ba9fafa0,11

Also, here's the info I got from a hit later on (hits.csv):

mac,ssid,rssi,channel,ftype,conf,ie_fp,lat,lon,heading,count,marked,epoch,class,hidden,label
24:B2:B9:2D:61:FF,,-94,2,P,2,7c923b53,41.839287,-72.815536,214.000000,1,1,1788977995,0,0,

And the associated diag.csv:

1788977233,1788977320,87,v0.90,0,0,0,13,1,238,0,0,478,0,0,0,0,0,0
1788977329,1788977397,68,v0.90,0,0,0,13,1,132,0,0,114,0,0,0,0,0,0
1788977921,1788978049,128,v0.90,0,0,0,13,1,347,0,0,858,2,1,1,0,0,1
1788980170,1788980681,511,v0.90,0,0,0,13,1,2031,0,0,5275,0,0,0,0,0,1
1788981869,1788981872,3,v0.90,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
1788981882,1788981923,41,v0.90,0,0,0,13,1,75,0,0,325,0,0,0,0,0,1
1788981926,1788981927,1,v0.90,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
1788982075,1788982076,1,v0.90,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1

I forgot to update to v0.93 this time >=\ Annoyed with myself. Might go back out again later if this info is useful, and you come out with another quick update.

[ReconGrunt]

v0.94 is up, that's the one to test that camera with.

Grab the .fap for your firmware. You don't need to reflash the board, nothing has changed on the companion side since v0.90 apart from the version string. Leave your signatures.json where it is, both of those fingerprints still work.

Park where you did last time and check Air Survey on the main menu. 89c3debf should turn up in the hit list this time rather than only in the CSV.

One other thing you'll like: survey.csv no longer gets clobbered when you drive to the next stop. There's a survey_log.csv beside it now that keeps every scan with a timestamp on each row, so a whole drive is one file.

Thanks for the dumps, they made this a lot easier.

UPDATE:

Quick update on 89c3debf before you spend a trip on it. It turned up on my own bench this week, on a random address, with no camera anywhere near it. One weak sighting doesn't kill it outright, but it's now behaving like a common WiFi stack rather than anything Flock specific, so catching it on a second MAC wouldn't prove what I said it would. Don't go out of your way for that one.

Your own data has a better angle in it. 06:FC:CB:3A:F8:9E was the same address on both of your visits. Randomised, but not rotating. That means the address itself identifies that camera, and no fingerprint is needed for it.

v0.95 adds Pin addr in Air Survey for exactly this. Open that row, press Pin addr, restart the app. From then on it comes up as a hit instead of only a survey row.

If you get another chance at it, what's actually worth knowing now is whether that same address is still there in a week.

[wiilover22]

v0.95 adds Pin addr in Air Survey for exactly this.

I'll drive out there this morning, start Air Survey, sit for a minute~ish (don't like being a bother), and then stop for the same camera I can't find.

Then I'll go past a few other cameras and do the same using Air Survey to see what I can find. Hopefully all the log files won't overwrite now, so I can bring back a decent amount of info.

Edit: Oh! Forgot to add...when a camera is identified, with a GPS location - and you click "Report" - the QR code brings you to the main flockmap site...not to the map. They must have changed their URL structure, so your QR code doesn't redirect properly.

[ReconGrunt]

QR Code issue fixed :) Thanks, they did indeed change the name.

[ReconGrunt]

Okay. Thank you for the heads up. By the way, I will be closing this issue as the original error was fixed and converting it to a discussion as it better suits this.

[wiilover22]

So uh...I went on a long drive tonight. Passed the set of flocks that we haven't been sure about...then continued surveying while driving. Passed another 4-6 flocks later on down the road. Then did the same drive back after a bit. Lot of data here...including the 89c3debf a few times...which leads me to believe that's not a camera?

survey_log.csv
diag.csv
hits.csv

[ReconGrunt]

I love me some data! Thanks.
The 89c3debf is genuinely interesting. It could be a camera because 06:FC:CB:3A:F8:9E had 149 probes at -17dBm at the same place two days apart, it's definitely something. I'm working on it right now, those CSVs are going to help a lot.
Which row was the camera you could physically see?

[wiilover22]

That's a really good question...because where I'm parking, I'm now getting 2-3 "hits"...so without literally walking up behind the pole...I'm honestly not sure if 89c3debf is a camera...or something else =\

Wonder if I can strap my flipper to a drone >.>

[ReconGrunt]

War flying sounds like a really good idea lol. Actually going to try that out today! Planning a mission out and having it autonomously hover over a few cameras in the area is easy work, genuinely excited to try this out. I immediately thought of making a custom mount for the Flipper and DJI but might just "raw dog" it with some electrical tape. Let me know if you come up with a less janky method.

Regarding 89c3debf, is it popping up at those two locations only?
Note the 00:50:F2:08 element shows up in 89c3debf (payload 00 25 00), ee6ddf99 (00 12 00) and the Flock signature (00 00 00). Three unrelated device families carrying the same Microsoft-OUI element with a varying middle byte. It reads like a common stack feature with a version or capability field, not a device identifier, which is exactly why it can't discriminate on its own, and why the Flock match needs the MBO element alongside it.

Behaviorally, 06:FC:CB:3A:F8:9E was stationary, very close (-17 dBm), extremely chatty (149 probes), and kept the same randomized address across two visits days apart. Plenty of IoT devices generate a random MAC once at first boot and keep it forever. So: a fixed, mains-powered, Wi-Fi 6 device sitting where you parked. A TV, a hub, a doorbell, a thermostat, maybe even a dash-cam, and the data doesn't narrow it further. Could it be something from your car thats pinging when parked?

[ReconGrunt]

Use the Locator on it, this is the strongest one. Air Survey → that row → Flag MAC → restart the app. It now shows up as a hit, and from the detection you can press Lock ▶ and walk or drive until the signal peaks. That physically locates it which might be the easiest method for you to get a visual confirmation on what it is or isn't.

[wiilover22]

Gotcha - been super busy again...but I'll follow up on all this eventually.

[wiilover22]

Well...I'm kinda at a loss right now. I'm no longer sure if I'm correctly finding cameras or not. Based on testing and moving around...I no longer think either ba9fafa0 or 89c3debf are flock cameras. I tried sitting next to the same few cameras again...and I couldn't get anything to show up on hits, and survey showed too many devices. I also found out even though the MAC of ba9fafa0 changes, it's following me. Perhaps android auto, cell phone, pokemon go dongle?

Am I missing a method/way to exclude devices or signatures? The Air Survey list is just chock full of potentials, which isn't helping me "narrow down" much.

Here's the logs I pulled tonight...but I'll be honest, this will probably be my last contribution...as I'm no longer sure the problem isn't sitting between the flipper and the computer =P

Edit: Also - tried using the "Locator" function...it didn't work very well for me. The signal kept showing strong, then dropping out completely...and I noticed that when swapping from "Locator", back to the normal "Flock/ALPR Detect" mode - I had to reset the WROOM once or twice to get the app to talk to the companion again.

diag.csv
hits.csv
survey_log.csv

[ReconGrunt]

Air Survey picks everything up, that was supposed to be used only for the cameras that were rotating their MAC address issue or when someone wants a wider scan. The Flock/ALPR scan is what actually detects cameras and sorts them by class/vendor. I'm getting accurate hits on my end with Axon, Flock, and Motorola on a daily basis although some cameras just aren't pinging. I'll update the README with instructions later today.

The best thing you can do for yourself is to mark a camera "Confirmed as seen", that'll save its fingerprint to your actual device.

I'm glad you found out it was your phone, would've helped a lot knowing this earlier but at least it confirms that none of this is a severe FDF issue. While the ESP32 you have is okay, adding an SMA connector to it with an antenna would yield you better results.

Thanks for the CSVs, I'll take a look later and see if there's anything worth adding from there. FYI I can't really do much with the data unless you specify which ones were suspected or confirmed to be cameras. Otherwise I'm staring at a bunch of numbers.

[wiilover22]

FYI I can't really do much with the data unless you specify which ones were suspected or confirmed to be cameras.

Yeah...that's how I feel right now as well. I'm getting "hits" when there's obviously no ALPR's around, and then I don't get "hits" when I'm near an ALPR. And perhaps it's a symptom of the small integrated antenna, instead of a dedicated SMA - but if hardware requirements are now showing to be a limitation - after obtaining a specific device (flipper) - then a second specific board (which might not even be correct) - for a "chance" at "guessing" there's a camera nearby...idk.

[wiilover22]

I'm obviously an idiot, so I'll close this discussion for now and stop wasting your time =P

I hope this project works out, because it's getting nearly impossible to spot and remember which shapes are which brands...which ones are just traffic sensors, and which ones aren't...

One last set of ideas...you mentioned perhaps the cameras weren't active, and to grab a camera: is there a way to use the IR receiver on the flipper while scanning for a camera to correlate the two?

Also; the relatively small/slow interface of a flipper is a little limiting...is there any way a flipper can be utilized similarly to an SDR, and act simply as a receiver, while a more powerful laptop does all the decoding and displaying?

Either way, thanks for the fast responses, and good luck!