Environment
Kismet server: Kismet 2025.09.0-b5d5a2d04 on Ubuntu 24.04
Remote capture: kismet_cap_linux_wifi 2026.07.0 (libwebsockets 4.3.5), two remotes over wss (nginx TLS → :2501)
Adapters: node1 MediaTek MT7921AU (mt7921u), node2 Atheros (ath9k); ~20 ft apart
Versions matched? yes, all latest
Expected: A device (e.g. an AP) heard by both datasources has two entries in kismet.device.base.seenby, each with its own uuid, signal, last_time, num_packets — enabling per-source signal/location.
Actual: Each device is associated with a single datasource; a second source that also hears it is not appended to seenby. With two remotes locked to the same channel (channel_hop=false, channel=6), both running=1, no device is ever listed under both UUIDs (analyzed the full device list: BOTH=0, has_node1 and has_node2 fully disjoint). Additionally, kismet.common.seenby.last_time appears to track the device's last_time rather than the source's — a stopped datasource (running=0, frozen num_packets) still shows seenby.last_time = the device's current last_time.
Reproduction
One Kismet server; connect two remote kismet_cap_linux_wifi sources (distinct UUIDs), placed to hear a common set of APs.
Pin both to one channel (channel=6,channel_hop=false); confirm both running=1, hopping=0, and that each independently hears a specific strong AP.
Fetch that AP via REST (/devices/by-mac//devices.json) and inspect kismet.device.base.seenby.
Result: only one seenby entry, though both sources are capturing that AP's channel.
Impact: Downstream consumers can't get per-datasource signal/location for a device, which breaks multi-sensor RSSI positioning/triangulation.
Notes / caveats to pre-empt: confirmed both datasources running=1 on the same channel with hopping=0; confirmed each adapter independently receives the target AP.
Environment
Kismet server: Kismet 2025.09.0-b5d5a2d04 on Ubuntu 24.04
Remote capture: kismet_cap_linux_wifi 2026.07.0 (libwebsockets 4.3.5), two remotes over wss (nginx TLS → :2501)
Adapters: node1 MediaTek MT7921AU (mt7921u), node2 Atheros (ath9k); ~20 ft apart
Versions matched? yes, all latest
Expected: A device (e.g. an AP) heard by both datasources has two entries in
kismet.device.base.seenby, each with its own uuid, signal, last_time, num_packets — enabling per-source signal/location.Actual: Each device is associated with a single datasource; a second source that also hears it is not appended to seenby. With two remotes locked to the same channel (channel_hop=false, channel=6), both running=1, no device is ever listed under both UUIDs (analyzed the full device list: BOTH=0, has_node1 and has_node2 fully disjoint). Additionally,
kismet.common.seenby.last_timeappears to track the device's last_time rather than the source's — a stopped datasource (running=0, frozen num_packets) still showsseenby.last_time= the device's current last_time.Reproduction
One Kismet server; connect two remote kismet_cap_linux_wifi sources (distinct UUIDs), placed to hear a common set of APs.
Pin both to one channel (channel=6,channel_hop=false); confirm both running=1, hopping=0, and that each independently hears a specific strong AP.
Fetch that AP via REST (/devices/by-mac//devices.json) and inspect kismet.device.base.seenby.
Result: only one seenby entry, though both sources are capturing that AP's channel.
Impact: Downstream consumers can't get per-datasource signal/location for a device, which breaks multi-sensor RSSI positioning/triangulation.
Notes / caveats to pre-empt: confirmed both datasources running=1 on the same channel with hopping=0; confirmed each adapter independently receives the target AP.