Wake on LAN on Realtek cards
-
Hi,
I have a computer lab consisting of 17 computers that are equipped with a built-in Realtek card. I have tried to run WoL on it to restore operating systems faster (sometimes Windows, sometimes Ubuntu) and there is no problem with this under Windows, however, there was a problem under Linux. Well, the r8169 driver embedded in the kernel, does not support WoL correctly. And this is not a problem because all I had to do was install the r8168-dkms package. Unfortunately, FOS, which uses the kernel driver, keeps disabling WoL for me so that I can’t easily boot computers over the network.Normally under Windows the system activates WoL itself so I only have to start it once and WoL comes back. Linux does not do this and even with the r8168-dkms package I have to use ethtool to activate WoL because after any operation in FOS, WoL is deactivated by the r8169 driver.
Is there any solution to this problem? As a last resort I could build my own kernel with the r8168 driver, but I would like to avoid this.
-
@piotr86pl This is the first time I heard of linux kernel settings being persistent between boots. Its possible that FOS linux is leaving the network adapter in a strange state to/where the dkms driver is not resetting it upon startup.
FOS Linux should have the ethtool built-in. It would be interesting to know if either through a postinstall script or a postinit script you could execute the ethtool commands to enable WoL before FOG Imaging exists.
Also make sure you are using the 5.15.x branch of the FOS Linux kernel so you get the latest hardware support.
-
@george1421
It is likely that the settings for MagicPacket WoL are stored in some kind of memory on the NIC. The same is true on Windows, where there is a “Wake on Magic Packet” option in the Device Manager and its setting is required for WoL to work - in Linux this is done with the commandethtool -s enp1s0 wol g.Unfortunately, the built-in driver in the kernel - r8169 probably has poorly implemented WoL support, as regardless of the setting with the ethtool tool WoL does not work, and after a reboot the setting returns to Disabled. Browsing through internet resources, I came across information that this is a common bug with some Realtek cards and apparently the ones built into my motherboards suffer from this. The forums recommend installing the r8168 driver from the Realtek website, which does not have this bug. On distributions like Ubuntu this is not a problem - worse with FOS.
So in the end, I replaced the r8169 driver with r8168 in the FOS kernel and created a corresponding patch, which I put in the “patch” directory to make it easier to build my own modified kernels. The problem disappeared.
Additionally, in other computer labs, there are Dell Vostro 3681 PCs which also have a Realtek card and which suffer from an even worse issue - images restore at 3GB/min using Unicast. When I use my modified kernel with the r8168 driver, the speed is 13GB/min. The same situation occurs with the laptops we use - Vostro 3500. Original kernel: 3GB/min, modified kernel: 13GB/min.
I don’t know where the difference comes from, but this driver embedded in the kernel is not very famous anyway - it creates a lot of problems with new models of Realtek cards. I will use the modified kernel for now, until r8169 is fixed.
-
@piotr86pl I’ve had to do what you’ve done in the past with other realtek cards. If I remember correctly the kernel driver is 1.11 or something like that where the realtek drivers are 2.x (understand I’m saying this from memory and didn’t bother to get my facts correct). But the point is the version of the 8168 driver in the native linux kernel is old. That is probably the problem. The FOG Project does very little patching the the “official” linux kernel to keep fog project admin overhead low.
-
@Piotr86PL Thanks for this interesting topic. I know WoL can be tricky at times. Though mostly this was the case years ago when you had to connect the extra Wake on LAN cable on the NIC to make it work:
But yeah, even nowadays some NICs just don’t do a great job regarding WoL.
We usually tend to keep the kernel as clean as possible. On the other hand the speed improvements and WoL functionality sound very promising. We might consider adding the r8168 from Realtek.
Did you disable the official r8169 kernel driver in the config or did you build the kernel with both enabled? Which exact version did you use? r8168-8.050.03?
@testers @moderators Can we get some people together to test r8168-kernels on various Realtek cards?
-
@sebastian-roth
As it turns out, this topic is a bit complicated.The “r8169” driver built into the kernel supports the following Realtek chips:
RTL8169 Gigabit Ethernet
RTL8168 Gigabit Ethernet
RTL8101 Fast Ethernet
RTL8125 2.5GBit EthernetWhereas the “r8168” driver provided by Realtek only supports:
RTL8168
RTL8111And installing r8168 REQUIRES removing r8169 from the kernel. Therefore, in order to maintain functionality, I was forced to integrate into the kernel not only r8168 from Realtek, but also other drivers provided by Realtek. These drivers are:
r8101 - support for RTL8101 and related chipsets
r8125 - support for RTL8125 and related chipsets
r8169 - support for RTL8169 and related chipsets (DO NOT MISS THE KERNEL DRIVER!!! These are not the same drivers)Only by integrating these four drivers can the integrated r8169 driver be replaced while maintaining support for all chips. And removing the integrated r8169 driver is required - as I mentioned.
I can provide a patch file that I use to compile modified kernels (the patch completely swaps the integrated r8169 for these 5 drivers mentioned earlier).
Versions I use:
r8101 - 1.037.01
r8125 - 9.010.01
r8168 - 8.050.03
r8169 - 6.031.00 (recall, this is also the name of the Realtek driver, which currently has nothing to do with the one built into the kernel)There is one more important thing!
The Realtek drivers r8101 and r8168 have a function called “mdio_real_read” in the r8101_n.c and r8168_n.c files. This function is not set as “static” so the linker throws an error if you integrate these two drivers in the kernel. You need to make small modifications and add “static” in both files to these functions (r8125 already has static added). My patch already contains this modification. -
Here is link to the patch: https://mega.nz/file/z5swlQjS#RuS5gGVD2Kc2IpQr3YTgEnw8xg3o8vaABeDBwuDEST0
-
@piotr86pl said in Wake on LAN on Realtek cards:
As it turns out, this topic is a bit complicated.
…Oh well. I had a feeling that there is more to it. Well done! Thank you. The patch looks good on first sight.
Although this is a major patch I can still imagine this to be added to the official FOS kernel. Though not on quick schedule. First, we need to figure out if you or anyone else is keen and available to maintain this patch (make sure FOS kernels compile with the patchset on kernel updates, keep an extra github branch up to date and maybe update the patch from the official source from time to time). Second, we’d add this patch to a github branch and extend the existing buildkite job to compile an extra-kernel along with the default ones, so people can grab this and test. And finally if it all goes well we’d make it the default kernel.
What do you think?
There is one more important thing!
The Realtek drivers r8101 and r8168 have a function called “mdio_real_read” in the r8101_n.c and r8168_n.c files.
…Maybe this is something to be mentioned to the code maintainer at Realtek. Looking at the files you mentioned I think the right contact would be: Realtek NIC software team (nicfae@realtek.com) - it’s worth a try.
-
@Piotr86PL Hmmmmm, I might have just stumbled upon a pain licence issue here. The Realtak drivers are released under GPLv2-only (as stated in the comments in each file). According to this table it can’t be used with GPLv3 that FOG was released under: https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
While this should not prevent you from using it for yourself the FOGproject is not allowed to release official kernels because of this I think.
-
It’s a good idea to release a separate kernel build, with integrated Realtek drivers. At the moment I have to deal with FOG almost every day and I would be able to see to it that the patch remains compatible (but I don’t know what the future will bring). People could test at their place how this custom kernel works and indeed as if there would be no problems, it could be used as default kernel. Of course, if the ‘r8169’ driver built into the kernel gets fixed, then we could go back to generic kernel builds.
Hmmmmm, I might have just stumbled upon a pain licence issue here. The Realtak drivers are released under GPLv2-only
I’m no legal expert, but it seems to me that as long as the kernel is not an integral part of the FOG code (and is only downloaded during installation), it doesn’t matter what license the FOG is under. I just don’t know what it would be like to share pre-built kernels on Github (just sharing a patch would not likely be a problem - the code is public, after all). Nevertheless, it would be better to consult someone knowledgeable about the topic.
-
@piotr86pl
WoL works reliably here with r8169. To enable WoL on boot basically every network manager (systemd-integrated, netctl, etc.) offers a config option.
For systemd see hereThe mentioned 13GB/min would be more than 200MB/s, exceeding the rate of a 1Gbps link. So this number may refer to a compressed image. More relevant would be iperf results for assessing network performance. r8168 and r8169 both can go at full link speed.
To check for issues specific to the Realtek network chip version on your system (r8169 supports ~ 50 chip versions) a full dmesg log would be helpful.
