Wake on network access using an onboard Intel i219-V NIC

[Henties]

@jpz4085 As recommended by you I have now opened a new thread where we can discuss possible solutions to get "Wake for network access" working with an Intel i219-V NIC on a GA-Z170X-UD3 mobo.

 

The EFI folder used for that mobo, controlling macOS Monterey as well as Ventura has been attached.

 

Presently I am using a D-Link DGE-560T PCIe add on NIC with which WOL is functioning well on both macOS operating systems.

 

Detailed and supplementary system information can be found at the beginning section of the config.plist file, located as usual, within the EFI folder. 

 

Note that the IntelMausi.kext has been enabled, with the network port being set "inactive" in "System preferences", this simplifies testing and troubleshooting somewhat.

 

Hoping a properly working solution can finally be arrived at.

 

Greetings Henties

 

EFI.zip

Edited August 14, 2022 by Henties
Added attachment

[jpz4085]

8 hours ago, Henties said:

The EFI folder used for that mobo, controlling macOS Monterey as well as Ventura has been attached.

Looks good for the most part but why is the model name specified in the DeviceProperties for the NIC? Does it not display properly without that?

8 hours ago, Henties said:

Note that the IntelMausi.kext has been enabled, with the network port being set "inactive" in "System preferences", this simplifies testing and troubleshooting somewhat.

My next question is related to the one above. Why does the inactive connection have the name "Intel I225-V"? Is that how it appears in System Information? That would be a completely different model from the i219-V you actually have and it's not supported by IntelMausi at all.

Edited August 14, 2022 by jpz4085

[Henties]

@jpz4085 Apologies, I erroneously attached a screenshot off one of my Comet Lake hacks, the correct one has now been submitted. For all my machines the onboard NICs have been set inactive because I am using DGE-560T's everywhere. The Intel i225-V has been a disaster from the word go. When it was released Intel applied a wrong "inter frame gap" in the NIC's hardware implementation, they have tried to fix it with only a measure of success.

The i225-V actually works well now and also sleeps sort of the way it should, however when the hack goes to sleep it repeatedly wakes again exactly 5 minutes later, which is no good in my environment, the DGE-560T does not do that.

 

As far as the name is concerned one can actually use any name because it's "selection/control" is slot dependent and not name dependent.

 

The model name was specified in device properties merely as a test and also to pave the way so that a WOL activating string of any value can be applied, all in accordance with a description on Github relating to the modified fisher code for this kext.

 

Greeting Henties 

[jpz4085]

11 hours ago, Henties said:

Apologies, I erroneously attached a screenshot off one of my Comet Lake hacks, the correct one has now been submitted.

OK, I see.

11 hours ago, Henties said:

As far as the name is concerned one can actually use any name because it's "selection/control" is slot dependent and not name dependent.

Understood.

11 hours ago, Henties said:

...and also to pave the way so that a WOL activating string of any value can be applied...

Give me an example of exactly what you mean by this.

[Henties]

@jpz4085 I have conducted some more tests whilst observing the 2 led status lights on the onboard RJ45 LAN Port for the built-in i219-V ethernet controller.

 

When the hack is awake, with traffic on the ethernet backbone:

1.  the "Connection/Speed LED" is on and the colour is orange, which is consistent with a 1 Gbps. data rate. (which is correct)

2. the "Activity LED is blinking orange, whenever traffic is present on the ethernet backbone.                          (which is correct)

 

When the hack is sleeping:

1. the "Connection/Speed LED" is off which is consistent with a 10 Mbps. data rate.                                           (which is correct)

2. the "Activity LED is blinking orange, whenever traffic is present on the ethernet backbone.                           (which is correct)

 

As a power saving measure WOL implementations generally toggle the link speed of a sleeping NIC to the lowest speed the NIC can handle.

 

The forgoing observations mean that during sleep, the "Physical Layer" as well as the  "Data Link Layer" of the OSI stack for the i219-V should indeed be aware as to what is happening on the network, and duly respond to a properly configured "Magic WOL Packet".

Improper Bios and power settings (ERP) are therefore not considered to be the problem with WOL and the i219-V NIC.

 

1. WOL troubleshooting should therefore be directed at the "Network Layer" and possibly higher up the OSI stack. (kext/software)

2. Or it should be ascertained what type of "Magic Packet" the i219-V is actually looking for.

    a. A "Mac Address" with individual words of the address delimited with colons or not.

    b. Which port is the i219-V configured for proper WOL operation? 9/11 ???

    c. Which broadcast address will the i219-V respond to? On a flat network there are indeed some options available.

        The DGE-560T has no problems as far as the broadcast address is concerned, it always responds reliably with

        whatever one "throws" at it. (255.255.255.255 or "network address.255" or "network address.254" ie. 192.168.0.254)

    d. In what specific sequence, if any, need the required parameters be placed onto the network by the client machine?

 

Unless the parameters that apply to the i219-V are known, one would be fishing in the dark for a long time, with little chance of ever reaching success. 

 

Incidentally, the behaviour of the status lights for the i219-V NIC is consistent with the behaviour of the status lights for the DGE-560T NIC, with the only difference being that WOL with the DGE-560T is working properly whereas with the i219-V it is not.

 

Looks like I will have to dig into the source code of the IntelMausi.kext to find out what is actually required for WOL to function, hoping however that you can provide some of the answers, seeing that you already spent some time in adding your "brand" of WOL code to the basic IntelMausi.kext

 

Interesting times ahead indeed.

 

Greetings Henties

 

 

 

Edited August 15, 2022 by Henties

[Henties]

57 minutes ago, jpz4085 said:

OK, I see.

Understood.

Give me an example of exactly what you mean by this.

Quote from Github:

"Wake on LAN functionality should work out of the box. On misconfigured hardware one may try to force-enable it by injecting (mausi-force-wol) device property (with any value, recommended)"

End Quote

 

The attached "Example Screenshot" should make it clearer.

 

Greetings Henties

Edited August 15, 2022 by Henties

[jpz4085]

5 hours ago, Henties said:

The forgoing observations mean that during sleep, the "Physical Layer" as well as the  "Data Link Layer" of the OSI stack for the i219-V should indeed be aware as to what is happening on the network, and duly respond to a properly configured "Magic WOL Packet".

Agreed. That would have been my next concern.

 

5 hours ago, Henties said:

Improper Bios and power settings (ERP) are therefore not considered to be the problem with WOL and the i219-V NIC.

There should also be a Magic Packet setting in the BIOS power management or NIC settings. Make sure that's enabled.

 

6 hours ago, Henties said:

Or it should be ascertained what type of "Magic Packet" the i219-V is actually looking for.

As far as I can tell the format of the magic packet is not defined in the driver. Only the register configuration required to enable WOL in S3 which is under setPowerStateSleepAction in IntelMausiHardware.cpp.

 

6 hours ago, Henties said:

Which port is the i219-V configured for proper WOL operation?

WOL is typically port 7 or 9. I can't say if your particular card is using something different but that seems unlikely.

 

6 hours ago, Henties said:

Which broadcast address will the i219-V respond to?

Any that can reach it I would assume.

 

6 hours ago, Henties said:

Incidentally, the behaviour of the status lights for the i219-V NIC is consistent with the behaviour of the status lights for the DGE-560T NIC, with the only difference being that WOL with the DGE-560T is working properly whereas with the i219-V it is not.

Seems as if WOL is enabled but the proper wake filter is not configured. At this point I can't say more.

 

6 hours ago, Henties said:

hoping however that you can provide some of the answers, seeing that you already spent some time in adding your "brand" of WOL code to the basic IntelMausi.kext

All IntelMausi variants use the original WOL code by Meize the only difference is how wake from S5 is implemented. I tied it to the macOS wake setting. That's all.

[Henties]

@jpz4085 Thanks for your latest response, based on that I seem to be making some real progress, it's a bit early yet to provide some meaningful feedback. Will definitely come back to you with my findings, or alternatively a request for additional assistance.

 

There is a lot of testing and subsequent evaluation involved before I can provide any meaningful feedback for your consideration.

 

Greetings Henties

 

[Henties]

@jpz4085I finally have collected some very interesting results, obtained after extensive and fruitful testing on my end. 

 

When in macOS, with the DGE-560T installed BUT toggled INACTIVE, in the System Preferences -->Network section, with the I219-V toggled ACTIVE, I can wake the problem hack with a WOL port number of 7 and the ethernet Mac address of the i219-V onboard NIC.

 

When the machine goes to sleep the correct LEDs light up on the LAN port for the i219-V as well as the LAN port for the DGE-560T.

 

Obviously I thought at that stage that using WOL port 7 was indeed the remedy, because I had never before tested with that port number, and now all of a sudden with port number 7 everything seemed golden.

 

I subsequently removed the DGE-560T believing that from now on WOL using port number 7 would be trouble free. In the end that however proved wishful thinking.

 

I waited for the hack to enter sleep again, but without the DGE-560T installed, and discovered that all of a sudden the essential LED on the i219-V port was not lit. WOL was consequently not possible under those conditions.

 

Therefore back to square one.

 

I reinserted the DGE-560T, continued testing and voila, WOL was working with the DGE-560T present and visible on the network, but again 

set "Inactive" in  "System Preferences-->Network"

 

Now with the hack sleeping and the DGE-560T reinserted, the proper LED was lit again on the i219-V  as well as the DGE NICs, and WOL, via the relevant i219-V parameters succeeded again.- You figure.

 

Now to Windows, without the DGE-560T installed.

 

When Windows sleeps the proper LED is lit on the i219-V LAN port, and WOL works.

 

Now disabling WOL in the i219-V driver, also disables WOL from functioning in the Windows environment.

 

Conclusion:

 

In a Windows environment WOL can be enabled or disabled with the Windows driver for the i219-V NIC,  provided  WOL is also enabled in Bios.

 

Now whatever can be accomplished, from a driver level perspective in Windows, is just not possible with any of the many versions of the IntelMausi.kext available for macOS.

 

It surely seems evident now that only an IntelMausi.kext software update will be able to solve the WOL problem experienced  with a Gigabyte Z170X-UD3 mobo and it's onboard i219-V NIC, because in Windows WOL functioning can be software controlled, whereas in macOS it can not be kext controlled.

 

Hoping the foregoing will help you to assist me further in a finding a solution to this long standing nagging problem. 

 

Greetings Henties   

 

 

Edited August 16, 2022 by Henties

[jpz4085]

Hi @Henties,

 

So it seems WOL works with the i219-V on port 7 only if the DGE-560T is installed but inactive, otherwise the Intel card is apparently powered off. Fascinating.

 

5 hours ago, Henties said:

Now whatever can be accomplished, from a driver level perspective in Windows, is just not possible with any of the many versions of the IntelMausi.kext available for macOS.

 

It surely seems evident now that only an IntelMausi.kext software update will be able to solve the WOL problem experienced  with a Gigabyte Z170X-UD3 mobo and it's onboard i219-V NIC, because in Windows WOL functioning can be software controlled, whereas in macOS it can not be kext controlled.

The fact that the i219-V was able to wake means that the IntelMausi.kext successfully programed the card. The RealtekRTL8111.kext can't be responsible for that and Windows is irrelevant in this case. Something else is going on here.

 

5 hours ago, Henties said:

Hoping the foregoing will help you to assist me further in a finding a solution to this long standing nagging problem.

After some research it looks like WOL used to work on your GA-Z170X-UD3 and GA-Z97X-UD3H hacks and then stopped back in 2018 and you were able to resolve it by generating a new Network "Location" and deleting the old one in System/Preferences/Network. As you posted on t_macx86:

 

Go to /Library/Preferences/SystemConfiguration and delete NetworkInterfaces.plist. Restart and then reconfigure your network interface in System Preferences -> Network.

 

Have you given that solution a try?

[Henties]

@jpz4085Alias "Herlock Sholmes" 🤪

 

I finally decided to throw in the towel and let the onboard i219-V NiC be what it is, in the macOS environment of my Gigabyte GA-Z170X-UD3 hack.

 

This mobo suffered from serious analog audio distortion fairly early from when I commissioned it. As a cure I used a MAYA44e PCIe add on card for audio, which worked very well over many years. 

 

Today I removed the MAY44e thereby freeing it's PCIe slot, which thus became available for repurposing. Audio is now picked up via the S/PDIF port found on the "Audio IO Cluster" on the backplate of this mobo. This digital stereo audio is now fed straight into a JBL soundbar, outputting sound in a terrific and pleasing sound quality.

 

The DGE-560T has been moved to the freed PCIe slot, configured as "en0" with WOL working as expected.

 

The i219-V has been enabled in bios but set "inactive" in the "System Preferences-->Network" configuration section. It is used in Windows and Ubuntu as the primary network device.

 

I can now wake this hack using either the macaddress of the DGE-560T and port 9 or alternatively the i219-V macaddress and port 7, strange things happen in strange places. However I now believe the 2 NICs share the same OSI "Physical and Network" layers, which means that the i219-V NIC macaddress and port combination, when present on the "ethernet backbone" will kick the machine to life as well, which is quite understandable to me at least.🤪 The i219-V onboard NIC, with it's kext (driver) is just not capable to keep the OSI "Physical as well as Network layer" alive when it is the only network device activated, it needs to piggy back on the DGE-560T to function, in conjunction with a GA-Z170X-UD3 mobo, the way it was originally  intended.

 

Magic WOL packets are not "interpreted" in layers above the OSI "network layer",  the wake action only takes place in the OSI "network layer"  

 

The AMD RX580 DGPU is therefore once again working in a fully 16 lane compliant environment and performing quite well.

 

I will keep this thread open for a while should others wish to comment and offer their opinions on this topic, such as for instance retired coder @Mieze

 

For you I want to express my extreme appreciation and gratitude for your research and valued inputs on the subject matter.

 

Greetings Henties