NEFilterDataProvider.handleNewFlow(_:) gets called with same flow ids multiple times

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).

Replies

Are only seeing this with mDNSResponder flows? Because it’s does stuff that can exacerbate this issue (r. 115822797).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Are only seeing this with mDNSResponder flows?

The majority is /usr/sbin/mDNSResponder, but I also get others, such as /usr/sbin/netbiosd.

(r. 115822797)

Can I look this somewhere up, or is it just for your own reference?

Do you think this behaviour is a bug, or does it mean that the earlier flow is invalid once the double one comes in, or what does it mean?

The majority is /usr/sbin/mDNSResponder, but I also get others, such as /usr/sbin/netbiosd.

Thanks for confirming. The thing these have in common is the extensive use of multicast, which seems to be part of this issue.

Can I look this somewhere up … ?

No.

is it just for your own reference?

Strictly speaking it’s not that either (-: I talk about this more in Bug Reporting: How and Why?.

Do you think this behaviour is a bug … ?

I’m not entirely sure.

I’m in two minds about this:

  • On the one hand, I’d like you to open a DTS tech support incident so that I can dig into this properly and come up with a complete answer.

  • On the other hand, I’m loathe to suggest that because the result is likely to be:

    • You have to live with the current behaviour.

    • You should file a bug to request clarification from Apple about this issue, either by fixing the OS or by updating the docs.

So it’s kinda up to you here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

On the one hand, I’d like you to open a DTS tech support incident so that I can dig into this

OK, I opened Case-ID: 5366675.

You should file a bug to request clarification from Apple

I already filed FB13397779 some weeks ago, but didn't get a response.

OK, I opened Case-ID: 5366675.

That landed in my queue last night. I’ll respond there later today.

I already filed FB13397779 some weeks ago

Thanks for that context.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"