Use FOSS (blob-free) driver for rtl8188eu wireless network adapter
Hello, I have been advised that Bugzilla is not the right place for suggesting a new driver to be used and that the factory mailing list could be the proper place for this. So, I subscribe to this list and I share with you my findings and suggestion for replacing the current rtl8188eu driver which requires a proprietary blob for firmware with a FOSS one. Here are the details: https://bugzilla.suse.com/show_bug.cgi?id=1198655
On 4/21/22 10:35, Suse User wrote:
Hello,
I have been advised that Bugzilla is not the right place for suggesting a new driver to be used and that the factory mailing list could be the proper place for this. So, I subscribe to this list and I share with you my findings and suggestion for replacing the current rtl8188eu driver which requires a proprietary blob for firmware with a FOSS one.
Here are the details:
I added am update to that bug describing that the firmware in your driver is most likely embedded in the source code, and that you were actually using proprietary code. Larry
On Thu, 21 Apr 2022 11:02:10 -0500 Larry Finger wrote:
I added am update to that bug describing that the firmware in your driver is most likely embedded in the source code, and that you were actually using proprietary code.
Thank you for doing that. I will reply here to your Bugzilla comment to avoid using Bugzilla for discussions.
In the driver that comes from Realtek, either directly or indirectly, the firmware is stored in the code as a big table., thus your test was likely using such a driver, and you were in fact using a binary blob that is published under a GPL v2 license, but it is not available as source code for the imbedded CPU in the NIC.
I understand what you mean. However, this contradicts the essence of software being free. On one hand we have the FOSS license which grants the 4 freedoms. OTOH you say it is not even open source. So we have the freedom to study, modify, and redistribute code. This means we also have the freedom to reverse engineer it as it is a form of studying and modification, and we are allowed to redistribute the modified (unobfuscated) version.
To get that firmware file, I merely copied that huge table into a separate program that wrote the contents into a binary file. The WHENCE file in the linux-firmware repo is as follows: Driver: rtl8188eu - Realtek 802.11n WLAN driver for RTL8188EU
Info: Taken from Realtek version RTL8188EUS_linux_v4.1.4_6773.20130222 File: rtlwifi/rtl8188eufw.bin
From your explanation I understand that you are using version 4.1.4 from 2013. Is that correct and (regardless of the outcome of this discussion) is it possible to upgrade to the newer one which I found? Disclaimer: I don't know who manages the Github repo I used but during my research I could not find any source code directly from Realtek. All sources seem to refer to the one I used.
Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
The most pertinent part of the LICENCE file noted above is * No reverse engineering, decompilation, or disassembly of this software is permitted.
I performed recursive grep for each of those keywords and there is no such text in the source code I used.
Yes, the driver files are FOSS, but information about the firmware is never really open source, nor would disassembly be legal.
As it seems, not for the source code I found. I understand that theoretically it is possible someone (including the Github repo's owner) to have removed/modified the license headers but since we have no proof of that (or of the opposite) it is legally correct to exercise the 4 freedoms which a license of a program found on Github grants. FWIW I also see your name in the comments. I suppose you are far more involved in that and an expert in that matter. Regarding the table you mention, I see a long series of hex codes in: rtl8188eus/hal/rtl8188e/hal8188e_s_fw.c rtl8188eus/hal/rtl8188e/hal8188e_t_fw.c rtl8188eus/rtw_security.c I don't know what role those tables play and it seems you are right that it is a form of blob. Without license restrictions though, anyone should be free to reverse engineer it (as long as one knows how). I would very much like to know what you think. Personally I would hate to know there might be a "FOSS" backdoor or malware in the wireless adapter I use. P.S. The other day I posted this reply to the Packaging ML by mistake. Sorry about that.
So, a month since the latest message in this thread, the summary is: 1. There is a binary blob in the form of "table" which Larry somehow separated in a binary file and there is no way around this obfuscated code/data. 2. The upstream version of the driver is quite old and there is something which can be improved. I hope someone (Larry?) can have a look at the newer version and consider to update the driver upstream (if it is better), because building it manually on each system update is a time consuming process: https://github.com/drygdryg/rtl8188eus
On 22.05.22 19:26, Suse User wrote:
So, a month since the latest message in this thread, the summary is:
1. There is a binary blob in the form of "table" which Larry somehow separated in a binary file and there is no way around this obfuscated code/data.
2. The upstream version of the driver is quite old and there is something which can be improved.
Well, it is not like the driver is unmaintained upstream. It has not yet made it from staging into the "good" drivers section, but it is worked on in regular intervals. Just look at the git changes. The version number does not mean anything as I tried to explain to you several times. It was just never updated after the driver was incorporated in the upstream kernel in 2013.
I hope someone (Larry?) can have a look at the newer version and consider to update the driver upstream (if it is better), because building it manually on each system update is a time consuming process:
If you want this to happen, it would probably be useful to state what works with the "newer" driver that does not work with the in-kernel driver. Just the updated version number does not provide anything useful. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 5/22/22 12:26, Suse User wrote:
So, a month since the latest message in this thread, the summary is:
1. There is a binary blob in the form of "table" which Larry somehow separated in a binary file and there is no way around this obfuscated code/data.
2. The upstream version of the driver is quite old and there is something which can be improved.
I hope someone (Larry?) can have a look at the newer version and consider to update the driver upstream (if it is better), because building it manually on each system update is a time consuming process:
As I stated in the previous thread, no manufacturer releases the details of their firmware, nor that of their on-board CPU. If you wish to see an example of the firmware for a relatively simple 802.11g device, see http://netweb.ing.unibs.it/~openfwwf/index.php. It is too bad that running 'make && sudo make install' when the kernel changes is so laborious. Perhaps, you should check implementation of dkms. Although I am retired, and can devote nearly full-time effort to Linux, I am busy with other things, thus I am not planning on updating the rtl8188eu code in staging. In fact, there are a number of people currently converting that code so that it can be moved to the regular wireless trees. Larry
On Sun, 22 May 2022 20:09:54 +0200 Stefan Seyfried wrote:
If you want this to happen, it would probably be useful to state what works with the "newer" driver that does not work with the in-kernel driver. Just the updated version number does not provide anything useful.
It is not "newer" (with quotes, implying that it is not), it is newer (without quotes). I have not compared the code line by line and I am not a full time programmer but perhaps for some years something may have been improved. Looking at the commits can provide the useful info you talk about. What I do know for sure is that trying to build an older driver version (downloaded source code from TP-Link's website) did not work for me (result: errors). What did work was the version I shared here. On Sun, 22 May 2022 13:15:55 -0500 Larry Finger wrote:
It is too bad that running 'make && sudo make install' when the kernel changes is so laborious.
It depends what computer you are running it on. Consider an old 32-bit laptop (which otherwise does excellent work for what it is used for) with limited resources and on a fairly slow Internet connection. Each system update requiring driver update takes additional traffic (for the additional dev packages), disk space and time to build - sensibly more than simply running 'zypper up'. On Sun, 22 May 2022 13:15:55 -0500 Larry Finger wrote:
Although I am retired, and can devote nearly full-time effort to Linux, I am busy with other things, thus I am not planning on updating the rtl8188eu code in staging. In fact, there are a number of people currently converting that code so that it can be moved to the regular wireless trees.
I am not sure I understand (the term "code in staging" is unknown to me). Are you suggesting that someone else is already working on updating the driver version upstream?
On 5/23/22 15:01, Suse User wrote:
On Sun, 22 May 2022 20:09:54 +0200 Stefan Seyfried wrote:
If you want this to happen, it would probably be useful to state what works with the "newer" driver that does not work with the in-kernel driver. Just the updated version number does not provide anything useful.
It is not "newer" (with quotes, implying that it is not), it is newer (without quotes). I have not compared the code line by line and I am not a full time programmer but perhaps for some years something may have been improved. Looking at the commits can provide the useful info you talk about. What I do know for sure is that trying to build an older driver version (downloaded source code from TP-Link's website) did not work for me (result: errors). What did work was the version I shared here.
On Sun, 22 May 2022 13:15:55 -0500 Larry Finger wrote:
It is too bad that running 'make && sudo make install' when the kernel changes is so laborious.
It depends what computer you are running it on. Consider an old 32-bit laptop (which otherwise does excellent work for what it is used for) with limited resources and on a fairly slow Internet connection. Each system update requiring driver update takes additional traffic (for the additional dev packages), disk space and time to build - sensibly more than simply running 'zypper up'.
Using an out-of-kernel driver always involves extra work and packages. That is the choice you make.
On Sun, 22 May 2022 13:15:55 -0500 Larry Finger wrote:
Although I am retired, and can devote nearly full-time effort to Linux, I am busy with other things, thus I am not planning on updating the rtl8188eu code in staging. In fact, there are a number of people currently converting that code so that it can be moved to the regular wireless trees.
I am not sure I understand (the term "code in staging" is unknown to me). Are you suggesting that someone else is already working on updating the driver version upstream?
Code in "staging" means that it is in the drivers/staging tree of the kernel source. Each kernel version update gets many patches that are aimed at fixing the ugly code of the original Realtek driver in the hopes of moving from drivers/staging to the regular drivers/net/wireless/realtek tree of the kernel source. The code quality must be much higher in the latter tree than it is in the drivers/staging tree. The base driver version in drivers/staging/r8188eu is v4.1.4_6773.20130222. If you are happy with that, all you need to do is run a kernel 5.15 or newer. I do not know what version was used to create the driver in drivers/staging/rtl8188eu. Larry
Hi Larry, Hi Suse On 23.05.22 22:37, Larry Finger wrote:
The base driver version in drivers/staging/r8188eu is v4.1.4_6773.20130222. If you are happy with that, all you need to do is run a kernel 5.15 or newer. I do not know what version was used to create the driver in drivers/staging/rtl8188eu.
as far as I could deduct from digging in the git history, this is the version number of the originally imported source code. It (the version number) has never been updated since. But these version numbers for drivers are IMHO totally meaningless, because, as I tried to explain to Mr or Ms User, fixes to the (in the mean time improved) code in staging are almost never done by importing a new load of crap from the vendor, but by selectively applying fixes to the already shined-up code in staging. If the "new" driver would be imported, all the work of getting the driver out of the staging area (this is the area of the kernel where not-yet ready-for-primetime code lives and waits for a kind soul to clean up the mess to make it ready for playing with the "good guys" driver department) would be lost. So what the kernel maintainers do is react to problem reports, and if they get one, they fix it. If someone can tell them "feature ABC does work with the ugly realtek driver, but does not work with the in-kernel driver", it is even likely that someone might look at what the realtek code is doing differently and applying the same fix to the in-kernel driver. But Mr or Ms User did not yet come up with a single thing that the realtek driver does better (apart from the higher version number). So maybe the best thing would be to remove the version number completely from this driver and just have it tell the kernel version number ;-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Larry, Stefan, Thank you for explaining all that. I understand that the driver version number in kernel code does not correspond to the actual code version which may have (and probably has) been updated in time. This is an important clarification. It would be better if this metadata is up to date too, so people don't get confused and suggest updates as a result of confusion. As for whether I am happy with the driver which comes with the kernel - I don't know, I never tried it. When I purchased the TP-Link TL-WN722N-V3, I was hoping that I would get the visually similar https://ryf.fsf.org/products/TET-N150HGA (as my goal was to have a RYF device). Unfortunately, the later turned out to be V1, not the V3 which I purchased. Still, I checked what driver I could use with it and found the code we discussed here. I was happy I might have found a FOSS alternative but I learned there may be blobs ("tables") in FOSS code too. My options now (apart from looking for another RYF device) are: - use the "newer" driver with the extra burden of re-building it - use the driver which comes with the official kernel, trusting it is of higher quality, disregarding its unknown version number Question: how do I check whether I am happy with the later? What should I look for in order to compare with the first option?
On 24.05.22 21:08, Suse User wrote:
Question: how do I check whether I am happy with the later? What should I look for in order to compare with the first option?
Just check if everything you want to do with the device works with the default (in-kernel) driver. If something does not work with it, try if it works with the out-of-tree driver you found. If it works there, create a bug report with the linux-wireless developers. You could also try to compare the performance of both drivers (better network throughput for example) and report on that. Best regards, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue, 24 May 2022 21:37:29 +0200 Stefan Seyfried wrote:
You could also try to compare the performance of both drivers (better network throughput for example) and report on that.
Have you any idea how to do that? I am using the device only to connect to the WiFi hotspot of an Android phone in order to get Internet access. I have no other WiFi devices (e.g. router) with which to test throughput.
On 25.05.22 21:19, Suse User wrote:
On Tue, 24 May 2022 21:37:29 +0200 Stefan Seyfried wrote:
You could also try to compare the performance of both drivers (better network throughput for example) and report on that.
Have you any idea how to do that? I am using the device only to connect to the WiFi hotspot of an Android phone in order to get Internet access. I have no other WiFi devices (e.g. router) with which to test throughput.
If that's the only WiFi you got, then I have no idea how you could test anything regarding driver features, sorry. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Here is a private message I received recently. I invited the sender, who obviously follows the list, to post here more details. I hope he will. On Sun, 29 May 2022 06:16:51 +0200 XXXXXXX XXXXXX wrote:
Stick to the driver from GitHub. The in-kernel driver is unreliable.
I haven't said anything yet as I have moved to Fedora, but I've got two TP-WN725N wireless adapters. The in-kernel driver loses the connection constantly. The driver from https://github.com/aircrack-ng/rtl8188eus is rock-solid. I use version 5.15 of the Linux kernel.
participants (3)
-
Larry Finger -
Stefan Seyfried -
Suse User