Since NEFilterFlow.identifier
is documented as The unique identifier of the flow.
, I thought I could use it to store the flow by its identifier in a dictionary in order to retrieve it later. I do this when the system extension pauses a flow because it needs to ask the user whether the flow should eventually be allowed or dropped.
But then I noticed that sometimes when allowing a previously paused flow, identified by its identifier
, my system extension doesn't find that flow anymore. After some debugging it turned out that this happens because I stored at least one other flow with the same id which, when confirmed, is removed again from the dictionary, so there is no more flow with that identifier waiting in the dictionary.
Is it expected that the identifiers are recycled for different flows, or does it mean that the same flow is effectively being passed to handleNewFlow(_:)
multiple times, such as if the extension waited "too long" between pausing a flow and allowing or dropping it? handle(_:)
can be called multiple times for the same flow, but why .handleNewFlow(_:)
?
All flows with duplicate ids seem to be UDP
, and the local host and port and remote host and port are the same for all flows with the same id. Most of the duplicate flows have a process path of /usr/sbin/mDNSResponder
(resolved with the sourceAppAuditToken
).