You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clarification on "Deleted clients stay deleted" from #1278 and prior issues #1292
just wanted to clarify this issue closing note as it relates to #1278 and prior issues.
Deleted clients stay deleted: the delete now writes a tombstone. Any source that still reports the MAC online (a cached station entry on an AP, a collector's history) can no longer re-admit it, and it also disappears from the offline "ghost" list. If you ever want the MAC back, adding it through the allowlist clears the tombstone. This is the one that should fix your two iPhone entries - delete them once and they stay gone.
the 2 iphone MAC addresses i noted do not appear anywhere in the network - confirmed by painstakingly looking at FDB and neighbor tables on all devices.
i don't think going to the tombstone resolution is necessary.
when i try to delete the clients from the PWA UI, after clicking on the confirmation dialog's "Delete client" button, the dialog goes away but nothing happens to the client in the list. it never, ever, appears to go away. it is just in the list.
so i think there is an issue in the "delete client" pipeline, not that it is getting "readmitted", a cached station entry on an AP, or in a collector's history.
if it was getting readmitted somewhere in netpulse it should also be gaining first_seen and last_seen timestamps. these entries have neither.
You are right, and your read of the evidence was better than mine. The tombstone alone did not fix it: those two entries had NO device_seen row (no first_seen, no last_seen - exactly as you noted), which means they were never "re-admitted" through the registry - they were being re-emitted fresh on every cycle by a live source, most likely a stale wireless station entry on ap1 that survives past the client's departure.
#1295 fixes that side: the tombstone now also filters the final device lists (both the overview and the per-router view), so a deleted MAC stays out of the list no matter which source keeps emitting it. Your delete once-and-it-stays-gone should hold now.
Two things worth saying:
Your detail about the missing timestamps was the key - it proved the entries never touched the registry and pointed straight at the emission side. Thank you for that.
The deeper source - why ap1's wireless list still carries stations long gone - is AP-side driver behavior I can't fix from NetPulse, but the filter makes it moot for the client list.
In main, shipping with the next release. Reopen if the little rascals survive this one.
Activity
fix(clients): tombstones filter the final device list, not just the r…
gnacho commentedon Oct 6, 2026
You are right, and your read of the evidence was better than mine. The tombstone alone did not fix it: those two entries had NO device_seen row (no first_seen, no last_seen - exactly as you noted), which means they were never "re-admitted" through the registry - they were being re-emitted fresh on every cycle by a live source, most likely a stale wireless station entry on ap1 that survives past the client's departure.
#1295 fixes that side: the tombstone now also filters the final device lists (both the overview and the per-router view), so a deleted MAC stays out of the list no matter which source keeps emitting it. Your delete once-and-it-stays-gone should hold now.
Two things worth saying:
In main, shipping with the next release. Reopen if the little rascals survive this one.
fix(devices): purge and filter fleet radio BSSIDs from the client list (