D-Link and the GPL

Recently my router died and to get netflix flowing again, I went out and got the cheapest router I could find in the vicinity. I ended up with a D-Link DIR-842 on discount for 499 SEK. In the box, I discovered this:

It tells me to go to D-Link’s page for GPL licensed software to get the source code. It also lets me write a request the source code on physical media for a nominal fee for the media and handling. Something I naturally did (being an engineer on vacation).

While waiting for a reply, let’s have a look at the online version. When entering the URL provided you have to click through an agreement that I understand what GPL and LGPL means and that the files distributed comes with no warranties (they spend more words saying this – read it if you want the details). Clicking “I Agree” I get a popup (back to the 90’s) asking me to register my product to enjoy all the benefits of doing so. At the same time the main window continues to a list of all D-Link products containing (L)GPL software – very nice.

The list of products is 24 pages long, so I searched for my model name (DIR-842) and clicked the resulting link. This got me to the following table:

I wonder what separates firmware version 2.0CN (China?) from version 3.0. Having 950MB of translation tables seems odd, so something else must be the case. As I have firmware version 2.02 for hardware revision B1 I decided to download that bundle consisting of 590 MB of open source code as a tarball. At least, that was what I expected. Apparently, I don’t only get the sources, I also get a test report – great!

The test report rar file contained a pdf documenting the tests. On November 16, 2016, test engineer Mason Wu carried out the GPL SC tests consisting of the steps Firmware upgrade, Firmware downgrade, Compile the Open Source Software Licenses code, Check list (Before test Open Source Software Licenses), Open Source Software Digital Signature check, and License file check. All tests passed – time for celebrations!

To be completely honest, this report tells me nothing, as I don’t know what has been tested or what the test cases do. The only thing I learn is that I just put a device with almost two years old software on as my interface towards the Internet…

So what is in the source code tarball? You can see the directory structure of the tarball in the picture below (I guess someone named Lisa created the tarball). First of all, there are some licenses, then the source code.

The source code is split into open source and private, where private is a set of prebuilt binaries, while open source comes with the whole source code. The open source software is licensed under the following licenses according to the LICENSE.txt:

  • GNU General Public License Version 2 (GPLv2.0)
  • GNU Lesser General Public License Version 2.1 (LGPLv2.1)
  • BSD 2-clause license
  • BSD 3-clause license
  • Apache License 2.0
  • zlib/libpng License
  • MIT License v2.0

Looking into the realtek SDK (rtl819x-SDK-v3.4.5.1) I found the base Linux system (under rtl819x-SDK-v3.4.5.1/rtl819x). This is open source software found outside the open source directory.

There does not seem to be a license for the proprietary stuff. Not for the realtek related directories (rtk_wifi_patch and rtl819x-SDK-v3.4.5.1), nor the directory named private. I’m not sure what that means from a licensing perspective. I guess it is complicated. The nice thing with this is that I should be able to rebuild a new firmware image from this.

Continuing down the rabbit hole I’m getting really worried. Remember that this is an internet facing device. There are so many things I want to point out, but I’m on vacation so I can’t dig through the whole source code. Here are some snippets:

  • The Makefiles outputs “It’s builded” when done. Kind of cute.
  • Building is supported on CentOS 5.9 (32-bit version) with GCC 4.1.2 20080704 (Red Hat 4.1.2-54). This is a release from 17 January 2013.
  • Building has to be done as root.
  • For the proprietary stuff, there are .c.dep files showing what source files where used and their dependencies. Also, some headers are included without copyright information.
  • The open source versions are really old. Some highlights:
    • Samba 3.0.24 – from 2003. The CVE list for Samba is scary – this is a piece of software that should be updated.
    • Kernel 2.6.30 – from 9 June 2009. End-of-lifed in October 2009).

However, the most critical issue is that code is not included in the release. Looking at the directory rtl819x-SDK-v3.4.5.1/rtl819x/toolchain there are a number of GCC tools (GPLv3 licensed, so the license list is incomplete) as well as binutils delivered only as binaries. These also include realtek confidental documents (see screenshot below).

I’m stopping my dig here, but I will have to follow up my written request for the source code, unless the optical medium contains more. I thought they had learned…

8 thoughts on “D-Link and the GPL”

  1. I wonder if there is enough there to build a custom firmware with a newer Samba and a newer Linux kernel?
    But then again, I wouldn’t do it right now, if that were my only way to get online, I wouldn’t want to brick it, and then have to spend more money an another new router.

  2. It really should be ported to something more modern such as yocto. However, there are two parties involved in this – D-Link needs to find a way to support their proprietary applications in that environment (or go fully open source) and Realtek need to join in. Both are mentioned on gpl-violations.org, so I would not hold my breath. Still, if they would be willing to change their ways, I’m sure that the community would be willing to help – I know that I would.

  5. Many years ago I looked at the D615 (or such). The netfilter .ko modules (e.g. sip, h323) had MODULE_PARAMS that were not in the source. Is that still the case?

  7. While you may be able to recompile the vendor firmware, you won’t really succeed in updating the security sensitive components without serious work. Although realtek tends to be rather open in terms of GPL compliance (e.g. they do provide the actual driver source), it also depends on a patched hostapd 0.4.x variant with a custom driver ABI – and the SOC itself is probably lexra based (a reduced mips ISA), without any kind of upstream support. Furthermore these lowend lexra devices are usually equipped with minimal amounts of flash and RAM, making this extra hard.

    If you want to keep your sanity, get something slightly better instead, something that has full LEDE/ OpenWrt compatibility – e.g. MediaTek mt7621, Qualcomm-Atheros ipq40xx, Qualcomm-Atheros ipq806x or Marvell mvebu based instead. Those should give you better performance and full opensource support, compatible with an OpenWrt firmware you can actually build from source in ~20 minutes on a semi recent/ popular linux distribution and where you can update/ change source components. Spend a little time on investigating about your preferred device beforehand and match it against your needs (WAN throughput, WLAN performance, additional services (e.g. VPN) you may want to run, etc.).

    Just to give some basic example devices (I’m only listing OpenWrt supported dual-band/ dual-radio devices with 1 GBit/s switches) which should work pretty well and are available new in stores (roughly increasing in price/ performance order, starting with roundabout the same money you spent for the DIR-842 rev B1):

    – Xiaomi Mi router 3g (mt7621), 2*880 MHz mips, 128 MB flash, 128 MB RAM, only three 1 GBit/s switch ports
    – ZBT WE1326 (mt7621), 2*880 MHz mips, 16 MB flash, 512 MB RAM
    – AVM Fritz!Box 4040, (ipq4018), 4*638 MHz ARMv7, 32 MB flash, 256 MB RAM
    – ZyXEL NBG6617 (ipq4018), 4*638 MHz ARMv7, 32 MB flash, 256 MB RAM
    – AFoundry EW1200, (mt7621), 2*880 MHz mips, 16 MB flash, 128 MB RAM
    – ZBT WG3526 (mt7621), 2*880 MHz mips, 16-32 MB flash, 512 MB RAM
    – Linksys WRT1200AC (mvebu), 2*1.33 GHz, 128 MB flash, 512 MB RAM
    – Linksys EA8500 (ipq8064), 2*1.4 GHz, 128 MB flash, 512 MB RAM
    – ZyXEL NBG6817 (ipq8065), 2*1.7 GHz ARMv7, 4 GB eMMC, 512 MB RAM
    – Netgear r7800 (ipq8065), 2*1.7 GHz ARMv7, 128 MB flash, 512 MB RAM
    – Linksys WRT3200ACM/ WT32X, 2*1.8 GHz ARMv7, 256 MB flash, 512 MB RAM

    (only listing the more popular examples of each target SOC, be it because of their prices or features/ performance, obviously there are plenty other vendors or devices.)

    yes, the top end costs about 5 times as much as you paid for the DIR-842 rev B1. GPL compliance of the vendors listed above might not be much better, the good aspect just is that you don’t need the vendor’s source for using them with opensource software like OpenWrt (18.06 will come with kernel >=4.14.52 or at least >= 4.9.110 (e.g. for ar71xx) for some older SOCs); a firmware blob is usually needed for the wlan cards (or xDSL modem).

    ar71xx/ ath79 based devices are also still well supported, just hardware wise significantly slower than the SOCs listed above, while still being just as expensive as its newer alternatives (honorable mention, TP-Link Archer C7).

    lantiq can also be a contender (especially cheap from the used market), with the added bonus of an integrated ADSL/ VDSL modem and (depending on the device) FXS support – performance a bit below ar71xx, many options not coming with well supported wlan though (honorable mention, BT Home Hub 5 Type A</b).

    What to pick depends a bit on your actual use case, your budget, the WAN throughput and which additional services you may want to run.

    https://openwrt.org/supported_devices/432_warning is something to be aware of and do actually investigate the actual support status for the intended device beforehand, https://openwrt.org/supported_devices and https://forum.lede-project.org can help with that.

Comments are closed.