I'm a bit confused by the documentation and parameter names for some NetworkExtension and System Extension APIs:
Case 1:
identifier is said to be "The bundle identifier of the target extension."
Problem:
This is pretty confusing since the API will report that it can not find the system extension in the apps bundle if you provide the bundle identifier.
Because the reality is that it's not the bundle identifier that you must provide but the name of the .systemextension bundle (without the extension). It just happens that the name of the system extension is required to be the bundle identifier (which is a mystery in itself).
So if you have a system extension with a name that differs from its bundle identifier, you will use this API and be told that it can not find the system extension whereas you are scrupulously respecting the documentation. And it may take you some time to figure out the origin of the issue.
Case 2:
This is a block that is used to "make a filtering decision about a network packet."
and
is supposed to be "The packet bytes."
Problem:
I haven't found any information in the header (or documentation) about the nature of these "packets".
It required to finally have a working Packet Filter prototype and try to match the raw data with a etherheader struct or ip struct to find out that these packets are actually Ethernet frames. And that a NEFilterPacketProvider content filter is actually the replacement for the interfacefiltert API.
Suggestions:_
Unless it already exists somewhere, wouldn't' it be nice to have a documentation that lists the equivalence between Network Extensions and Network Kernel Extensions?
As far as I understand:
socket filter -> filter data provider
ip filter -> MIA
interface filter > filter packet provider
Wouldn't it be nice to clearly indicate in the header and API documentation that the packets are Ethernet frames and not IP packets? This would avoid some possible confusions.
Case 1:
Code Block + (instancetype)activationRequestForExtension:(NSString *)identifier queue:(dispatch_queue_t)queue;
identifier is said to be "The bundle identifier of the target extension."
Problem:
This is pretty confusing since the API will report that it can not find the system extension in the apps bundle if you provide the bundle identifier.
Because the reality is that it's not the bundle identifier that you must provide but the name of the .systemextension bundle (without the extension). It just happens that the name of the system extension is required to be the bundle identifier (which is a mystery in itself).
So if you have a system extension with a name that differs from its bundle identifier, you will use this API and be told that it can not find the system extension whereas you are scrupulously respecting the documentation. And it may take you some time to figure out the origin of the issue.
Case 2:
Code Block typedef NEFilterPacketProviderVerdict (^NEFilterPacketHandler)(NEFilterPacketContext *context, _Nonnull nw_interface_t interface, NETrafficDirection direction, const void *packetBytes, const size_t packetLength)
This is a block that is used to "make a filtering decision about a network packet."
and
Code Block packetBytes
is supposed to be "The packet bytes."
Problem:
I haven't found any information in the header (or documentation) about the nature of these "packets".
It required to finally have a working Packet Filter prototype and try to match the raw data with a etherheader struct or ip struct to find out that these packets are actually Ethernet frames. And that a NEFilterPacketProvider content filter is actually the replacement for the interfacefiltert API.
Suggestions:_
Unless it already exists somewhere, wouldn't' it be nice to have a documentation that lists the equivalence between Network Extensions and Network Kernel Extensions?
As far as I understand:
socket filter -> filter data provider
ip filter -> MIA
interface filter > filter packet provider
Wouldn't it be nice to clearly indicate in the header and API documentation that the packets are Ethernet frames and not IP packets? This would avoid some possible confusions.