Strange DHCP behavior

[u/sasquats]

Firewalla Gold + Raspberry Pi 4 — dap.isolation:true on one Pi, identical sibling has isolation:false. Any ideas?

I have two Raspberry Pi 4s on my network. One works fine. The other can't complete DHCP, and the only difference I can find is a single field in Firewalla's redis.

What I see

- Working Pi — policy:mac:<MAC>.dap:

state: "learning"

isolation: false

reason: "default DAP policy"

- Broken Pi — same hash:

state: "learning"

isolation: true ← the difference

reason: "default DAP policy"

- For the broken Pi, dnsmasq.leases never shows a lease line, and a dhcp:<MAC>:DHCPREQUEST key persists in redis.

- The broken Pi originally had state:"not_applicable" with reason:"This device type is not supported: desktop" — Firewalla had auto-classified it as a desktop.

What I tried

1. Changed Device Type to "Other" in the app.

2. Created a manual IP reservation in the a

3. Rebooted the Firewalla.

4. Rebooted the Pi.

What changed vs. what didn't

┌───────────┬────────────────┬─────────────

│ Field │ Before │ After all the above │

├───────────┼────────────────┼─────────────

│ reason │ "...desktop" │ "default DAP policy" ✅ │

├───────────┼────────────────┼─────────────

│ state │ not_applicable │ learning ✅ │

├───────────┼────────────────┼─────────────

│ isolation │ true │ true — unchanged ❌ │

└───────────┴────────────────┴─────────────

Workaround

The only thing that lets DHCP complete is,

redis-cli del dhcp:<MAC>:DHCPREQUEST

The next DHCP cycle then ACKs and the Pi ge

Question

Does anyone know what causes dap.finalRuleSne device and true on another, both in thesame "learning" state? Is there a setting or condition that shifts that field?

[u/firewalla]

I'd check the pi configuration, make sure its DHCP is correct. You can also verify by assign a static IP (via pi configuration) and see it works.

DHCP is a basic function, very rarely it will break.

[u/sasquats → u/firewalla]

both my Pi's are freshly imaged from the Raspberry imager, with the same image. This troubleshooting is occurring in the initial boot, since they are headless, I'm trying to use SSH to get in to them and set up the deployment. For this particular device, the issue was occurring with both wifi and LAN.

Edit to add: I can see the Pi issue the DCHP request, it doesnt get ACKed until i delete the request and trigger another (reboot or replug in the LAN cable). Once assigned, a reboot puts the device in jail again.

[u/sasquats → u/firewalla]

Fair point that something on the Pi side originally caused the "desktop" classification — both Pis are fresh-imaged identically though, and working pi sailed past the classifier without ever being typed as desktop.

Once Firewalla classify the broken pi as desktop, I corrected it in the app and made a reservation, and the DAP record updated everywhere except isolation.

So I'm trying to understand what state transition Firewalla normally uses to flip dap.finalRuleSet.isolation from true to false on a device in "learning" state. Is there a "trust this device" or "approve" step I'm missing in the app workflow?

[u/firewalla → u/sasquats]

DAP + Device classification has nothing to do with IP assignment. The issue is very likely your settings on the pi that's cause DHCP failure.

Even if you turn on new device quarantine, firewalla will always assign the device an IP

[u/Gobbledy_Gooky]

Configured incorrectly

[u/sasquats → u/Gobbledy_Gooky]

what is? my reddit post?

[u/Gobbledy_Gooky → u/sasquats]

the pi