I recently bought a new router (TP-Link Archer C6) and according to several members of this forum, the open source wireless driver is not as good as the proprietary closed source driver which comes with the OEM firmware.
So I was thinking about building my own firmware image with the optimized driver extracted from the OEM firmware, is this possible?
If yes, can someone give me tips as how to extract the driver an integrate it with the build system? I am not really familiar with building the linux kernel, but I have experienced with writing C and using basic Make scripts.
No, it is not possible to extract the drivers from a compiled firmware and just patch them into OpenWrt. You need to obtain the original source code. In some very specific cases you can extract the firmware for the wireless chipset.
I know that it wasn't going to be as easy as opening up the firmware like a zip file and pasting the drivers into OpenWrt
TP-Link says that their "firmware" is open-source, there was even a GPL v3 license leaflet in the box. So I assume we at-least get access to the header files for the driver binary, in theory that should suffice I think.
Has this been done before? I'd appreciate any links, resources etc.
Absolutely, I just downloaded the GPL code from their site and look what I found:
TheDcoder@arch /t/t/C6V2_EU_GPL> ls
build/ ibase/ iplatform/ openwrt/ readme.txt scripts/ toolchain/
TheDcoder@arch /t/t/C6V2_EU_GPL> cat readme.txt
TP-LINK GPL code for Archer C6 v2.0
1. cd ./build
2. make bootstrap
3. make build
4. You will find all openwrt binary images in directory 'openwrt/bin/ar71xx/'.
1. When you are tring to build GPL code, the make program will automatic download
some other source code packages that it needs from Internet, please make sure
your Linux PC have good Internet connection.
2. If you are of the opinion that TP-LINK should offer further source code subject
to the GPL, please contact us under 'firstname.lastname@example.org'.
Looks like they are fans of OpenWrt as well
I am going to search for the driver's header files, but I have a feeling they might give us access to the driver binary as well
Couldn't find any driver files yet, but I wanted to try building the code so I ran all the
make commands, but the final
make build -j1 V=s is failing with this error:
freadahead.c: In function 'freadahead':
freadahead.c:83:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
83 | #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
Is this because I am trying to build on Arch Linux? It also uses glibc (GNU) so I don't see the issue. Appreciate any pointers
If you try to compile something that might not actually be that recent (and OEM tend to use old code) you gonna need some older Linux distro (easiest solution but not always possible) or alternative you need to patch the code to make it compile (you can always look for the error you get when you try to compile the code on google and in some cases you might find a patch or a hint about how to patch it to compile).
Try to compile it with Debian 9 and see if it complains about something.
From my personal experience compiling old stuff in Manjaro (not much differences from Arch Linux) I can tell you that old code won't really compile.
Linksys WRT3200ACM routers have open-sourced drivers for the wifi chipsets, and a blob that can be updated from firmware.
@thedukesd Thanks, that makes sense.
@eduperez Very interesting, but isn't that different from what we are trying to accomplish? Ideally we want to just lift the blob from OEM firmware and re-link it with our own firmware.
I have been trying to find anything related to the wireless driver but I haven't found anything yet, so it is all one big shot in the dark for me.
So for now I am going to lay back unless someone more experienced comes up to guide me.
P.S The GPL source can be downloaded from here, and the package for my specific model can be found here.
That blob runs is a firmware which is running on the wifi chip itself though, not something running next to OpenWrt on the main CPU (hence not facing any of the problems you would face when trying to interface a binary driver to modern kernels as used in OpenWrt)
That GPL code appears to be for an extremely old version of openwrt as it's using a kernel 3.3
Attitude Adjustment days...
Experience has taught me to never say "that is impossible", but that is, well, next to impossible. You really want to use the source code, not the compiled binaries.
In this case OP has said that the GPL source code, although ancient, is available for building OEM image. Does that not mean that both WiFi driver source code and WiFi firmware binary are somewhere in that source code, for a complete OEM image to be build from source?
I guess the more generic question is that when OEM release GPL source code e.g. Netgear, Linksys, TP-Link, is it the complete source code (even if ancient) to build a complete image with all drivers for full function of router, or do they have missing pieces (e.g. WiFi firmware binaries) which prevent a complete OEM image from being built?
@eduperez I was hoping someone would have already done something like this. If the binaries are not encrypted, it should be pretty easy to get hold of the binary blob... and then somehow link it with our firmware, just need to know all the know-how
@nolseek Yes, I was wondering the same... maybe I should try compiling it on an old version of Debian as suggested by @thedukesd.
@ TheDcoder if the code is complete and it's based on something like OpenWRT AA you will not really be able to compile it without patching it even in Debian 9.
OpenWRT BB needs 2 patches to actually compile in Debian 9. BB is as back as I tried to compile recently. AA is older so there might be other things that need to be patched.
For example to compile BB in Debian 9 you need to look at CC and take/adapt 2 patches from CC code:
and it will compile successfully and it will work after being flashed.
In AA case if you try to compile it with Debian 9 I expect to need to adapt the above 2 patches from CC and might still not be enough.
Finding older distro that you can use might not be that easy because you need the repos to download the stuff needed to actually be able to compile... ( https://wiki.debian.org/LTS/Extended as a suggestion).
You basically have some challenges:
A) is the code complete or not
B) if the code is not complete will you get an error during compile process or will you get an image that lacks some parts (and that image might just break the router in a way or another, you might just get a router without web interface and with telnet/ssh disabled so you can't configure it...)
C) will it compile
Let's assume you overcome the above challenges (code is complete and it compiles).
Having the driver code that is used with an old kernel doesn't guarantee that the driver code will work with a recent kernel. To be honest I expect a lot of patching to be needed to get it working with recent kernels. (it's not really like in windows case where web cam drivers from XP era happy work with Win 10...)
Without a spi flasher and a dump of the entire router flash I wouldn't try.
Older code, includes older versions and some of those older versions have known security vulnerabilities that are exploited in the wild.
There are some particular aspects of Linux that are not that friendly...
I have closed source driver from atheros, let me know if you need it.
@thedukesd Thanks again for outlining the situation, I didn't expect the firmware to be so old... maybe it is a deliberate tactic to prevent "front-porting" the closed source drivers to newer firmware (thus, open source firmware too)
Unfortunately I don't have an SPI Flasher and I am not particularly keen on voiding the warranty on my router
Well, it looks like I am going to stick with the FOSS drivers for now 🤷 (or OEM firmware, if I need more speed in the future)
If you need an old version of Debian you can create a chroot from the Debian archive  with debootstrap , I do use to compile and maintain legacy software used on my workplace, as is faster than make VM's to compile, debootstrap is available on several distros and make life easier as you can create a Debian chroot to compile and keep your current setup untouched.
Very nice tip! Thanks for sharing.
FYI, you don't need an SPI flasher. You can flash through U-boot, one you get serial access or console access, which is generally possible. You don't need to give up, based on this issue.