Repository navigation
Client list management issues continue #1278
Description
currently running v2.36.0
related to #1145, #1206, and definitely helped by #1207, here is a redacted but annotated client list export from my network right now:
name,hostname,mac,ip,type,group,manufacturer,router,band,online,signalDbm,port,portLabel,firstSeenMs,lastSeenMs,dhcpLease,adguard,traffic24hRx,traffic24hTx
,cliente,ap2-phy1-mac-addr,,desconocido,otros,,,—,offline,,,,1790821006185,1791224993492,Expired,yes,—,—
,cliente,ap1-phy1-mac-addr,,desconocido,otros,,,—,offline,,,,1790816086185,1791212843514,Expired,yes,—,—
,cliente,ap1-eth0-mac-addr,,desconocido,otros,,,—,offline,,,,1790802256043,1790806006189,Expired,yes,—,—
,cliente,ap2-eth0-mac-addr,,desconocido,otros,,,—,offline,,,,1790802256043,1790806006189,Expired,yes,—,—
,cliente,sw2-mgmt-mac-addr,,switch,otros,,,—,offline,,,,1790802256043,1790956725305,Expired,yes,—,—
,cliente,gateway-eth1-mac-addr,,desconocido,otros,,,—,offline,,,,1790802256043,1790806006189,Expired,yes,—,—
,cliente,sw1-mgmt-mac-addr,,switch,otros,,,—,offline,,,,1790802256043,1790956725305,Expired,yes,—,—
12:77:BC:5A:5A:FA,12-77-bc-5a-5a-fa,12:77:BC:5A:5A:FA,,desconocido,otros,,ap1,2.4 GHz,offline,-47,,,,,Expired,yes,—,—
62:6A:4A:EA:4A:9A,62-6a-4a-ea-4a-9a,62:6A:4A:EA:4A:9A,,desconocido,otros,,ap1,5 GHz,offline,-55,,,,,Expired,yes,—,—
- the top 7 are definitely associated with all of the Fleet units: gateway, sw1, sw2, ap1, ap2
i haven't tried to delete those from the client list. it might be good for netpulse to do a "check and purge" in the client list for the infra/fleet/protected mac-addresses on startup or something similar so it isn't an ongoing stale data issue.
- the bottom 2 i believe are old iphone mac addresses no longer on the network, have not been seen since the first/last_seen data were added after Client data missing for "first seen" and add "last seen" timestamp; more suggestions #954 and Client "First seen" and "Last seen" timestamp data not appearing #1095, no state entries in openwrt bridge or neighbor tables, and no entries in the dhcp.leases files.
those i have tried to delete from the client list but so far have not succeeded. the buttons push but the data is frustratingly persistent.
also, those last two have the dash format of MAC addresses in the "ip" field. you mentioned those only appeared with GL.inet devices (if i understood the comment correctly). since those are in the "ip" field your comment may not apply but i do not have any GL.inet devices anywhere so there might be another place where that format gets set/used.
Activity
fix(clients): deleted clients stay deleted; fleet MACs purged; sane I…
gnacho commentedon Oct 6, 2026
Three fixes shipped (#1290), one per symptom:
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.
Fleet units' own MACs purged: the base MAC of every fleet unit (from the routers table) plus each agent's bridge MAC is purged from the client registry on every cycle, so the gateway/switch management addresses stop lingering as offline ghosts. For the per-interface MACs already in your list (eth0/phy1/mgmt), delete them once - the tombstone keeps them from coming back.
Dash-formatted MAC in the ip field: some sources report the dashed-MAC hostname in the ip slot; any ip value that doesn't parse as an IP is now dropped at ingestion and on display.
All server-side, no agent update needed. It's in main, shipping with the next release - after updating, a single pass deleting the stale rows should leave your list clean for good.
fix(devices): purge and filter fleet radio BSSIDs from the client list (
feat(alerts): alert when a new client is seen for the first time (#1323…
fix(httpapi): lift the deleted-client tombstone on successful known-m…