Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRET//20350112
the “Number of Fast Retries” retry, the Flytrap waits “Slow Retry Pause” before
attempting to again cycle through the PoP List with fast retries.
(S) For a Periodic or Power-Cycle Beacon, the following Mission-configurable
parameters are used in the retry logic (see 9.11.9): Periodic Beacon “Fast Retry Pause”
and “Slow Retry Pause”. The “Number of Fast Retries” is set as the number of PoPs in
the PoP list. The PoP List is composed of any PoPs sent during previous Missions (see
9.11.6 and 9.11.15) that have been stored in NVRAM, and PoPs built into the firmware
image (see 15.3). PoPs in NVRAM from the most recent Mission are given priority, then
other PoPs in NVRAM, and finally PoPs built into the firmware image. A “fast retry” is
attempted “Number of Fast Retries” times, with each retry pausing “Fast Retry Pause”
before cycling to the next entry in the PoP List. After the “Number of Fast Retries” retry,
the Flytrap waits “Slow Retry Pause” before attempting to again cycle through the PoP
List with fast retries.
(S) It should be noted that for both Initial and Periodic Beacons, the “Fast/Slow Retry
Pause” begins directly after the previous Beacon “connect” has failed. For simplicity, the
Flytrap uses a standard C library blocking socket “connect” function when trying to open
a connection to the CherryTree to send a Beacon. In some cases, the “connect” function
can take up to two minutes to fail, depending on the “connect” function’s retry/timeout
algorithm.
(U) Figure 61, Figure 62, and Figure 63 show additional Beacon examples. Note these
figures use “Tumbleweed”, which is the now-deprecated term for PoP.
Figure 61: Beacon Example 1
133
SECRET//20350112