How to use Network System Extensions to manipulate the data before forwarding it

If you mean forwarding a packet that has been altered from the NEFilterPacketHandler then I would recommend against this. This could have negative impacts on the packet's routing and the likelihood of the packet to reach it's destination. Also, you will want to be careful here as performing any computation can have a performance impact on your network speeds.

| is it possible to perform some computation and forward the manipulated data before allowing it??

Take a look at the 2019 WWDC Session, Network Extensions for the Modern Mac that explains the usage of Network System Extensions. Also take a look at the Filtering Network Traffic sample project found here. This example provides an example of using the NEFilterDataProvider class, but be used for reference on how to think about using the NEFilterPacketProvider class as well.

Also I couldn't find any example for NEFilterPacketProvider which can help me in speeding up the process. If someone could point me to any references it will be really helpful.

| Also I couldn't find any example for NEFilterPacketProvider which can help me in speeding up the process. If someone could point me to

| any references it will be really helpful.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

| If you mean forwarding a packet that has been altered from the NEFilterPacketHandler then I would recommend against this.

| This could have negative impacts on the packet's routing and the likelihood of the packet to reach it's destination.

When I say altering the data, I meant actual data and not headers and other routing info. Also even if we change the header it will be intentional.

We already have a software which does this using kexts. In that we get the entire mbuf and work on that. It is a filter driver software.

What I want to understand is how can I implement the same functionality using system extensions.

| Also, you will want to be careful here as performing any computation can have a performance impact on your network speeds.

Yes understood. Thanks for pointing it out. We are ok with any impacts on network speed due to this.

The NEFilterPacketHandler provides the packetBytes in the form of const void so even though it would be possible to cast const away it would not be recommended in this case. Plus there are other expectations here such as packetLength that rely on these bytes staying intact.

typedef NEFilterPacketProviderVerdict (^NEFilterPacketHandler)
(NEFilterPacketContext *context, 
 nw_interface_t interface,
 NETrafficDirection direction, 
 const void *packetBytes, 
 const size_t packetLength);

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Hi!

"Thanks for the answer..., padhikari reported "As kexts will no longer be supported starting macOS 10.16..." how is that? For what I understood at WWDC 2019, only the type of kexts with corresponding support using System Extensions will be deprecated/unsupported, but those without it don't. There are al lot of kexts performing other tasks different than drivers and Network extensions that hasn't been supported yet.

In example, those with low level access to commonly used features like MSR registers, used by Intel Power Gadget to read CPU stats, or even write configuration values to MSR registers..., so these type of kexts will be still supported as long as they don't still have support using System Extensions, isn't it?

How to use in the future the kernel functions, like the included in proc_reg (rdmsr64) and so on? They can't be used right now using System Extensions... 😟 and there are a lot of software out there that need them in order to properly work.

https://developer.apple.com/documentation/kernel/kernel_functions?language=objc

Thanks!

No problem at all.

The kext deprecation story is complex. Are kext going to be deprecated? Yes they are. Will all kext be deprecated at once, no. Because not everything has a user space equivalent. This year we introduced a lot of new user space networking features so the network kernel extensions will be deprecated. The same pattern will be followed for other kernel extension functionality that moves to user space in the future.

Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thanks!!

That's what I though, but it's great you can confirm that, since some days ago read also some posts from people commenting the opposite and I was sure I heard what you mention at WWDC sessions.