Scanning mode: Wi-Fi
Capturing raw packets in Wi-Fi requires a monitor-mode capable interface and either local capture or a high-bandwidth connection to the remote capture device.
Scanning mode utilizing the normal network detection mode present in essentially all Wi-Fi cards to collect information about nearby networks for Kismet to use, but comes with some significant limitations:
Clients will not be visible.
Scanning mode cannot detect clients, only advertising access points.
Scanning mode transmits packets
Often, scanning for nearby networks generates probe requests from the device which is scanning.
Full beacon information may not be available
Often only the basic content of the beacons is available.
Packet data will not be available
Data packets, retransmissions, and other information will not be available.
Scanning mode data sources
The scan report API is designed to be as simple as possible, and to automate as much of the process as possible.
To assist with automation, scanning mode datasources are created dynamically by Kismet when scan reports are submitted; there is no need to define a specific datasource before sending a scanning mode report.
To create the scanning mode datasource, a scanning report must include:
A datasource UUID. This UUID must be unique within Kismet, and consistent for all reports from this datasource. Scanning software should cache this UUID for consistent reporting between instances.
A human-readable name. This wil be assigned as the name of the datasource, and will be updated automatically if the name changes in subsequent reports.
Cache and burst mode reporting
Scanning mode assumes that the device doing scanning may not be able to maintain a constant connection to the Kismet server.
Reports can be cached in sent in groups using the report endpoint; each report contains a timestamp, GPS location, and signal information. Multiple reports for the same AP reflecting information over time can be sent in a single connection.
Wi-Fi scanning report
Submit a scanning report.
A scanning report consists of a datasource name and UUID, and a list of report objects.
admin
scanreport
/phy/phy80211/scan/scan_report.cmd
POST
PARAMETERS
This endpoint takes additional parameters by using a `POST` request and supplying a
JSON document or json
form variable.
You can find more information about API parameters here.
reports
list
OPTIONALList of report objects
source_name
string
REQUIREDSource name
source_uuid
string
REQUIREDSource UUID
Each report object should contain:
timestamp
number
OPTIONALUnix timestamp with second precision.
If no timestmap is provided, the time the report is received is used.
Due to lack of high-precision packet data in scanning mode, timestamps are second precision only.
ssid
string
OPTIONALNetwork SSID, if known.
bssid
string
REQUIREDAccess point BSSID
capabilities
string
OPTIONALAn Android or Wigle style string of encryption options and other AP
attributes, such as [WPS]
, [WPA-PSK-TKIP+CCMP]
, and so on.
If no capabilities field is provided, the device is assumed to be an AP with no encryption options set.
channel
string
OPTIONALChannel string, such as 6
or 42HT40P
freqkhz
number
OPTIONALFrequency of device, in KHz
signal
number
OPTIONALSignal level, in dBm
lat
number
OPTIONALGPS latitude of detection, in decimal degrees
lon
number
OPTIONALGPS longitude of detection, in decimal degrees
alt
number
OPTIONALGPS altitude of detection, in meters
spd
number
OPTIONALGPS speed of motion of sensor during detection, in kilometers/hour
tags
object
OPTIONALObject/Map of device tags which will be applied to the device created by this scan.
Tagged scans should be used with caution: Tags will be applied to the device and will override any existing tags, so care must be taken with tags that overlap those editable by the user interface.
Submitting a user name or description tag, for instance, may be valuable if the user can enter that data in the scanning app, but the user should be advised that they can’t also edit that user name in the normal Kismet UI.