A frame is said to be unique when it appears on the air once and only once for the whole duration of a trace. WiPal's unique frame extraction process is an important stage of its trace synchronization process. WiPal programs' default policy is to consider all beacon frames and all non-retransmitted probe responses as unique frames.
One may use the wipal-extract-unique-frames command to get
a list of the unique frames that compose a trace. Run
wipal-extract-unique-frames -h
to get its invocation syntax.
In practice, WiPal does not extract and load full unique frames into memory. This would slow the process down and require an excessive amount of memory. The default is to work on MD5 frame hashes when WiPal was compiled using OpenSSL. When compiled without OpenSSL, WiPal only extracts a subset of frame fields. We call the pieces of information WiPal extracts to identify unique frames “frame attributes”, or sometimes “frame identifiers”.
You may specify frame attributes to use with the -a option. In practice, the difference in speed and memory consumption between attributes is negligible. There is an important difference between attributes, though. With some attributes, different unique frames may yield identical attributes (collisions). This is of course an undesirable behavior.
One may check that a given trace's unique frames are really unique w.r.t. unique frame attributes using the wipal-test-uniqueness command. This command finds collisions inside its input traces. You might specify different frame attributes using the -a option.
e.g.:
wipal-test-uniqueness -P -a tmp foo.pcap.1:foo.pcap.2 wipal-extract-unique-frames -P foo.pcap.1:foo.pcap.2 > foo-unique.txt
WiPal's “standard” behavior only considers non-retransmitted IEEE 802.11 probe responses and beacons to compute unique frames. Two “special” attributes however change this behavior:
hsh_en2
EN10MB
PCAP
link type (Ethernet II). On the opposite, “standard” attributes do
not work with this link type. Using theses attributes tell WiPal to
decapsulate Ethernet frames and use the following frames as unique
frames:
Beware: if you use traces that last long, OLSR packets' sequence
numbers might wrap. This might result in the assumption of OLSR packets
being unique not holding anymore. In such cases, you cannot use
WiPal to merge your traces.
hsh_80211_x
hsh_80211
but consider more
frames as unique frames. Non-retransmitted IEEE 802.11 probe
responses and beacons are still considered unique frames. In addition,
WiPal programs decapsulate IEEE 802.11 data frames and consider
the same frames as hsh_en2
(previously described).
Note that these attributes are disabled by default (because it slows the
compilation down and for long traces they are less robust than
hsh_80211
). To enable them, use the --enable-attributes
option of WiPal's configure script before compiling
WiPal.