NetworkDriverKit sample app problem

App & System Services Drivers
ohmycode OP
Created 5d
Replies 1
Boosts 0
Views 89
Participants 2

Hi, I'm trying to test "https://developer.apple.com/documentation/networkingdriverkit/connecting_a_network_driver" on MacBook Pro M3 with 14.5 Sonoma, XCode 15.4, SIP is disabled. Build steps are succesful, after running App, "Install Dext" is succesful, there is no error in XCode; "systemextensionctl list" show a record for "com.apple.system_extension.driver_extension" with [ activated enabled ] tag. But, "ioreg" doesn't show any service for the dext; and no new interface with name "enXX" appears in System Settings in contrast to what the document describes. In addition, seldomly my device experiences crash when the dext remains installed where crash report points "IOReg" function.

I tried also Driver Kit Sample ( https://developer.apple.com/documentation/driverkit/driverkit_sample_code ) and a github project based on this sample having last commits 9 months ago. However, Dext installation reveals similar behavior and "Communicate with Dext" step is unsuccessful with the message "Driver is not connected".

Is there an updated version of Networking Driver Kit documentation to reach a running sample app for Sonoma 14.5?

Thanks.

Answered by DTS Engineer in 795197022

Hi, I'm trying to test "https://developer.apple.com/documentation/networkingdriverkit/connecting_a_network_driver" on MacBook Pro M3 with 14.5 Sonoma, XCode 15.4, SIP is disabled. Build steps are succesful, after running App, "Install Dext" is succesful, there is no error in XCode; "systemextensionctl list" show a record for "com.apple.system_extension.driver_extension" with [ activated enabled ] tag.

Unfortunately, it's hard for me to give a specific "fix this answer" to this. My experience has always been that just getting a driver matching and loading is always painful, particularly the very first one. There are lots of details that have to be right and you won't know what you've missed until you figure out how to fix it.

Here are a few suggestion that might help:

-The system log is going to be your primary development tool. Take a look at "Your Friend the System Log" and take advantage of everything it suggests. In many case, the system is telling (or at least hinting) you what the problem is but it's VERY easy to miss things if you're scrolling Console.log.

-Make sure you can get "rid" of your DEXT before you try and test things. It's very easy to end up in a state where your old driver isn't unloading cleanly without your knowledge, then waste a bunch of time trying to figure out why nothing you try ever works. You can't test what you can't load.

But, "ioreg" doesn't show any service for the dext;

-What were you looking for and are you sure you didn't miss something? The provider for that sample is "IOUserResource", which means it will "always" match. I don't have that sample live at the moment, but I believe it should create an instance of "IOUserNetworkEthernet" off of "IOUserResource".

-If you're not familiar with it, I would recommend downloading and using IORegistryExplorer. You'll find inside "Additional Tools for Xcode" from our "More Downloads" section. IORegistryExplorer is basically the GUI equivalent of ioreg and, in my experience, it makes it FAR easier to visualize and understand exactly how the IORegistry actually works. Two quick notes on it:

  1. The Additional Tools download is generated as part of our build process (this is why it's versioned), but most of the tools inside it don't actually change all that often, particularly a fundamental tool like IORegistryExplorer. You don't really need to worry about keeping it "up to date".

  2. IORegistryExplorer maintains a "live" view of the current registry state, using "green" for new objects and "red" for old/dead objects. This can be really handy, but it can also slow things down and/or cause the interface to reset while you're trying to use this. If that's getting in the way of your work, you can use "Save" to generate a "snapshot" of the current state then open that file to view the static state. That avoids the performance issues (just close the "live" window) and also means you can share that file with other people or save it for later review. If you write to DTS with driver issue, the first thing I will as for is a IORegistryExplorer snapshot and, no, I won't take an ioreg text dump instead.

-Walk before you crawl. From painful experience, it's better to get an intentionally nonfunctional driver loading THEN get it working, instead of trying to get everything working "at once". There are LOT of failure points and every time I've tried to "rush" things, I've ended up wasting a bunch of time "investigating" what I THOUGHT the problem instead of what the problem ACTUALLY was.

-Related to that point, you may want to start by getting "Communicating between a DriverKit extension and a client app" working first. That's the simplest possible DEXT, as it doesn't depend on ANY "concrete" driver type.

-The "right" way to sign DEXT has changed over time and is not well documented. There are issues in Xcode 15 that make Distribution signing difficult, but the good news here is that development signing actually works pretty well. Just set "everything" to Automatic and Xcode should do the right thing for development builds. Note that this also means you do not have to disable SIP.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Replies  1
Boosts  0
Views  89
Participants  2
DTS Engineer OP
Apple
4d
Recommended

Hi, I'm trying to test "https://developer.apple.com/documentation/networkingdriverkit/connecting_a_network_driver" on MacBook Pro M3 with 14.5 Sonoma, XCode 15.4, SIP is disabled. Build steps are succesful, after running App, "Install Dext" is succesful, there is no error in XCode; "systemextensionctl list" show a record for "com.apple.system_extension.driver_extension" with [ activated enabled ] tag.

Unfortunately, it's hard for me to give a specific "fix this answer" to this. My experience has always been that just getting a driver matching and loading is always painful, particularly the very first one. There are lots of details that have to be right and you won't know what you've missed until you figure out how to fix it.

Here are a few suggestion that might help:

-The system log is going to be your primary development tool. Take a look at "Your Friend the System Log" and take advantage of everything it suggests. In many case, the system is telling (or at least hinting) you what the problem is but it's VERY easy to miss things if you're scrolling Console.log.

-Make sure you can get "rid" of your DEXT before you try and test things. It's very easy to end up in a state where your old driver isn't unloading cleanly without your knowledge, then waste a bunch of time trying to figure out why nothing you try ever works. You can't test what you can't load.

But, "ioreg" doesn't show any service for the dext;

-What were you looking for and are you sure you didn't miss something? The provider for that sample is "IOUserResource", which means it will "always" match. I don't have that sample live at the moment, but I believe it should create an instance of "IOUserNetworkEthernet" off of "IOUserResource".

-If you're not familiar with it, I would recommend downloading and using IORegistryExplorer. You'll find inside "Additional Tools for Xcode" from our "More Downloads" section. IORegistryExplorer is basically the GUI equivalent of ioreg and, in my experience, it makes it FAR easier to visualize and understand exactly how the IORegistry actually works. Two quick notes on it:

  1. The Additional Tools download is generated as part of our build process (this is why it's versioned), but most of the tools inside it don't actually change all that often, particularly a fundamental tool like IORegistryExplorer. You don't really need to worry about keeping it "up to date".

  2. IORegistryExplorer maintains a "live" view of the current registry state, using "green" for new objects and "red" for old/dead objects. This can be really handy, but it can also slow things down and/or cause the interface to reset while you're trying to use this. If that's getting in the way of your work, you can use "Save" to generate a "snapshot" of the current state then open that file to view the static state. That avoids the performance issues (just close the "live" window) and also means you can share that file with other people or save it for later review. If you write to DTS with driver issue, the first thing I will as for is a IORegistryExplorer snapshot and, no, I won't take an ioreg text dump instead.

-Walk before you crawl. From painful experience, it's better to get an intentionally nonfunctional driver loading THEN get it working, instead of trying to get everything working "at once". There are LOT of failure points and every time I've tried to "rush" things, I've ended up wasting a bunch of time "investigating" what I THOUGHT the problem instead of what the problem ACTUALLY was.

-Related to that point, you may want to start by getting "Communicating between a DriverKit extension and a client app" working first. That's the simplest possible DEXT, as it doesn't depend on ANY "concrete" driver type.

-The "right" way to sign DEXT has changed over time and is not well documented. There are issues in Xcode 15 that make Distribution signing difficult, but the good news here is that development signing actually works pretty well. Just set "everything" to Automatic and Xcode should do the right thing for development builds. Note that this also means you do not have to disable SIP.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0
NetworkDriverKit sample app problem
First post date Last post date
 
 
Q