Recent Linux on the D-Link DNS-313
(Last boot 2024-05-15 on kernel v6.6.30 with OpenWRT as rootfs)

D-Link DNS-313

D-Link DNS-313

Pre-cooked harddisk images

There are daily snapshots from OpenWRT available, but these do not have ksmbd or LuCI included.

This image is compiled to include: ksmbd, LuCI (web admin tool) and hdparm (used to spin down the drive). Also I have disabled odhcpd, dnsmasq and firewall by default so you do not have to do this manually. However you still need to partition /dev/sda1, format it with ext4 and change user and group on /mnt/sda1 to get a shareable partition (see the OpenWrt page for details).

Install this image like this:

  wget http://www.df.lth.se/~triad/krad/dlink-dns-313/openwrt-gemini-dlink_dns-313-ext4-factory.bin.gz
  gunzip openwrt-gemini-dlink_dns-313-ext4-factory.bin.gz
  dd if=openwrt-gemini-dlink_dns-313-ext4-factory.bin of=/dev/sdN
  sync

The image is configured such that the DNS-313 will grab an IP number from DHCP so just connect it to your LAN. After finding out what IP number it got (by visiting your router, for example) you can browse the NAS on http://192.168.1.N (default user/password root/root) or connect using SSH to configure and mount partitions. You need to follow the set-up guidelines from the OpenWrt page once you can find it on your network.

Continue with the set-up of the device on the OpenWrt DNS-313 device page after the spot where the device image is installed and booted for the first time, i.e. start by creating the /dev/sda1 partition and mkswap /dev/sda2/ etc.

I highly recommend using the OpenWRT images on this page over any legacy firmware for security reasons and AFAIK the performance is also better in all ways. As it is using OpenWRT, it is very hackable.

Device Info

Some reference bootlogs:

Rebuilding OpenWrt from source

Follow the generic OpenWrt clone and build procedure:

Compiling the kernel

To compile the kernel you first need a ARMv4 toolchain to build it with, then you need to configure and compile the kernel, and possibly also attach an initramfs.

I use a special gemini.mak makefile that I put in the root of the kernel directory, edit the makefile to select the right DTB then I type: 

  make -f gemini.mak config && make -f gemini.mak build
And this will build the whole kernel, attaching an initramfs and a DTB file, and put the resulting zImage in $HOME as well as in /var/lib/tftpboot if it is writeable. You will need the rootfs-gemini.cpio rootfs for this to succeed.

Analyzing the vendor code

Some information could be obtained by plowing through the (messy) vendor code. In drivers/char/g751.c we find:

#define GPIO_SET             2
#define SMBCLK_PIN           16
#define SMBDATA_PIN          15

So it is clear that the G751 temperature sensor is sitting on an emulated SMB (I2C) bus on GPIO lines 15 and 16. But this mocky chardev is actually used for all LED and fan control as well:

#define FAN_SPEED_LOW_PIN    11
#define FAN_SPEED_HIGH_PIN   12
#define FAN_SPEED_STATUS_PIN 13

So GPIO lines 11, 12, 13 are used for controlling the fan.

The boot loader code gives other hints. This can be found at dns-313_gpl_v2.01/source/Image/src/sl-boot-64M/src/sys/sys_main.c in the source release:

  #ifdef USB_DEV_MO
  vbus = REG32(SL2312_GPIO_BASE + 0x04)&BIT(17)  ; //read GPIO0[17]->data in 0x04
  if(vbus!=0)
  {
  vbus = REG32(SL2312_GPIO_BASE + 0x04)&BIT(18)  ; //read GPIO0[17]->data in 0x04
  }       //printf("vbus : %x\n",vbus);
  else
  vbus = 1;
  #endif

This is a hint that GPIO 17 and 18 is used for VBUS detection.

Further digging in the emac driver gives that GPIO lines 22 and 21 are used for MDIO to the PHY, and the PHY is on address 1 on the MDIO bus. This seems to be the case with almost all SL3512-based NAS things so no big surprise there.

In the initrd.tgz provided with the sources I found a file named /sbin/fan.script which provides the info that the fan should turn on at low speed at 43 degrees celsius and high speed at 47 degrees celsius.

Analyzing the flash contents

This device does not use the flash for the operating system or the root filesystem: it is just 512KiB and way too small to even fit a Linux kernel. Instead, there is a partition with a RedBoot-derived boot loader, and two partitions just named "MTD1" and "MTD2", each containing a (very small) file system.

The RedBoot image contains the MAC address used, at offset 0x1D2F4 thru 0x1D2F9. To be sure we found the right thing, we can check for the string "dns-313" at offset 0x1D204. I came up with this little script for setting the ethernet MAC from the ROM:

#!/bin/sh

if [ -b /dev/mtdblock0 ] ; then
    DEVID=`dd if=/dev/mtdblock0 bs=1 skip=119508 count=7 2>/dev/null`
    MACADDR=`dd if=/dev/mtdblock0 bs=1 skip=119540 count=6 2>/dev/null | hexdump -n6 -e '/1 ":%02X"' | sed s/^://g`
    if [ "x$DEVID" = "xdns-313" ] ; then
         echo "$DEVID ethernet address: $MACADDR"
         ifconfig eth0 hw ether $MACADDR 2>/dev/null
    else
         echo "Unknown firmware revision - can't extract MAC address"
    fi
else
    echo "No MTD device"
fi

The MTD1 and MTD2 partitions turn out to be two copies of the same file system of minix type with the following content:

  # ls -al
  totalt 44
  drwxr-xr-x. 2 root root 1184  2 jan  2000 .
  drwxr-xr-x. 1 root root   28 16 jan 14.16 ..
  -rwxr--r--. 1 root root 1525  4 dec  2008 cacert.pem
  -rwxr--r--. 1 root root 1751  4 dec  2008 cakey.pem
  -rwxr-xr-x. 1 root root   36  4 dec  2008 Certs.info
  -rwxr-xr-x. 1 root root  126  1 jan  1970 ddns.conf
  -rwxr-xr-x. 1 root root  136  1 jan  1970 email.conf
  -rwxr-xr-x. 1 root root   47  1 jan  1970 group
  -rwxr-xr-x. 1 root root   72  3 sep  2007 hosts
  -rwxr-xr-x. 1 root root   15  1 jan  1970 language.conf
  -rwxr-xr-x. 1 root root   25  1 jan  1970 log.conf
  -rwxr-xr-x. 1 root root  242 20 mar  2009 mt-daapd.conf
  -rwxr-xr-x. 1 root root  249  1 jan  1970 mt-daapd.playlist
  -rwxr-xr-x. 1 root root   15  1 jan  1970 mtdversion
  -rw-r--r--. 1 root root    0  1 jan  1970 newftp
  -rwxr-xr-x. 1 root root  146  1 jan  1970 passwd
  -rwxr-xr-x. 1 root root  172  3 sep  2007 pf_param.conf
  -rwxr-xr-x. 1 root root  185 30 sep  2007 pure-ftpd.conf
  -rwxr-xr-x. 1 root root   26  1 jan  1970 quota
  -rwxr-xr-x. 1 root root  302  9 aug  2007 rc.init.sh
  -rwxr-xr-x. 1 root root   12  1 jan  1970 resolv.conf
  -rwxr-xr-x. 1 root root    2  1 jan  1970 rtc.conf
  -rwxr--r--. 1 root root 3204  4 dec  2008 server.pem
  -rwxrwxrwx. 1 root root  109 26 jul  2007 shadow
  -rwxr-xr-x. 1 root root 1148  6 jul  2008 sib2.conf
  -rwxr-xr-x. 1 root root  760  1 jan  1970 sib_ap.conf
  -rwxr-xr-x. 1 root root 1148 12 jan  2009 sib.conf
  -rw-------. 1 root root  464 27 maj  2009 smb.default
  -rwxr-xr-x. 1 root root    1  1 jan  1970 smbpasswd
  -rwxr-xr-x. 1 root root   89  1 jan  1970 tr069.conf
  -rwxr-xr-x. 1 root root 1320  1 jan  1970 udhcpd.conf
  -rwxr-xr-x. 1 root root 1296  1 jan  1970 udhcpd.conf.def
  -rwxrwxrwx. 1 root root   23 10 feb  2009 upnpav.conf
  -rwxr-xr-x. 1 root root  143 11 mar  2009 upnpscript
  -rwxr-xr-x. 1 root root    0  1 jan  1970 v2.8
  -rw-r--r--. 1 root root    8 30 jul  2009 version2.txt
  -rw-r--r--. 1 root root   37 30 jul  2009 version.txt

Apparently there are just copies of random configuration files in the flash. Other D-Link NAS products seem to have more or less identical configuration files. None of them have very much relevance for running your own OpenWRT instance on the system, it might be that the OpenWRT /etc/config directory should simply be mounted here, so the configuration persists over a reinstall.

As sideband information we see that the product was configured 2007-2008 and someone made the last changes to the configuration in may 2009, which fits nicely with the device being released in 2010.

OLD (more manual) installation procedure:

Kernel TODO

Links