Some notes on transforming WiFi access point DLink DWL-G700AP to router using Wive firmware.

Intro

In fact the only reason I’ve started with it was my mistake when reading DWL-G700AP description on DLink product page … What I’ve needed was a WiFi router with single Ethernet WAN port, but from the fact that G700AP was able to run DHCP both on WLAN and LAN ports I’ve concluded that it should also be able to do that simultaneously and act as router, effectively treating LAN as WAN and running SNAT on it - which appeared to be not the case.

Fortunately, it appeared that there are some alternative firmwares, Wive being one of the best developed and known among them. Therefore, I’ve set up Wive on G700AP and got the needed functionality. As I required some things missing in standard Wive firmware, I had to recompile it, including into image the needed components.

In the rest of the article I list some things I found to be comparably tricky in this process, as Wive documentation currently is quite scarse, to say the least.

Here should go all that rubbish about “do it at your own risk” and so on, but I assume those who read it are the clever ones and understand that themselves. Still I’d like to give one warning: personally I found the process to be quite more difficult than working with custom OpenWrt firmwares, for instance, so I would not recommend attempting this unless you have at least some experience with embedded systems, or at least with other router firmwares.

Compilation

Currently the latest available version of Wive is 0.6.0, though it seems that version 0.6.1 is going to be released soon. All subsequent text discusses 0.6.0 version only, things may be quite different in other versions as interval between releases is large.

Strictly speaking, Wive “sources” distribution is in fact “semi-SDK”, as it contains some binary-only tools & programs, also it requires using binary-only toolchain, which can be downloaded at the same sourcefoge.net page where the Wive itself is located. I haven’t tried very hard, but I wasn’t able to find sources for toolchain. Binary tools are compiled for x86, for running them on Gentoo amd64 I had to install app-emulation/emul-linux-x86-baselibs.

There are some hard-coded paths to toolchain in SDK: while they can be changed to wherever you want, most likely you will have to modify some invocation options of compiler / linker in build scripts, as when I tried to relocate toolchain to another directory all binaries during firmware building were linked statically - hardly the thing you’d like to have on device with 2 Mb of flash Therefore, I recomend to stick to hard-coded paths by creating appropriate symlink to actual toolchain localtion.

As I had no ramdisk support compiled into kernel on host PC I also had troubles with the step of mkimg that prepares ramdisk; the solution there was just to mount directly the temporary image on file using -o loop rather than on /dev/ram, I wonder why it isn’t done like that in original script, as anyway it’s later re-mounted exactly in the same way.

You’ll also need to adjust packages names in APP/Makefile as they seem to be out of sync with the rest of distribution.

Due to small size of the flash you’re severely limited on space & and number/size of packages you can include: as far as I understood total size of image should be less than smth like 2Mb - 128Kb (used to store changes to FS), most likely also minus bootloader size. The image size is not controlled during build, but you will notice that you’ve hit the limit after flashing if after storing changes to filesystem you cannot boot anymore and bootloader complains in serial console on checksums mismatches.

Last but not least, it looks like default memory kernel configuration options are not OK for G700AP: after compiling with default options the kernel assumed to have 16Mb of RAM, which is not the case for G700AP. I didn’t bother to investigate what config and what options are faulty, but switching CONFIG_NINO_16MB to CONFIG_NINO_8MB in all source tree, as well as switching off CONFIG_NINO_EDIMAXMEM did the trick.

Then here are some notes on compilation of specific packages:

iptables

I’ve tried using versions 1.3.5 through 1.3.8, but there were two problems:

1. All of them do not compile from the scratch: some patching has to be done for compilation to succeed, such as commenting out some of uncompileable targets.
2. The resulting binaries do not work properly: binaries built with NO_SHARED_LIBS, i.e. everything compiled into iptables binary, segfaulted. When compiled with shared extensions, the binary seems to run OK, but resulting rules in the kernel are wrong, looks like all parameters passed to rules are discarded at some stage.

Therefore I had to stick with 1.2.8 iptables provided in the distribution and it worked OK.

dropbear

As dropbear key is pre-packaged on file system, it looks like dropbearkey executable may be omitted from firmware, this will save you some space.

tc

AFAIR by default tc utility is included into filesystem stub image, but if you do not need it you can remove it to have more space.

dnsmasq

dnsmasq is not included by default, however adding it to firmware was extremely easy, just unpack to APP directory, include the appropriate package name in APP/Makefile and modify mkimg.

Flashing

The procedure is explained multiple times on forums referenced from rtl8186.sourceforge.net: it’s usual TFTP procedure, nothing complicated, the IP is 192.168.1.6 WARNING: do not attempt to flash firmware from DLink native web interface, I haven’t tried that but others claim it will brick the router!

You should use “rev_a” or “rev_b” image depending on version of your hardware specified at the bottom or router case.

In the case of troubles with firmware you may find heplful to debug it via COM interface: for exact settings see, for example, this post, there it’s explained for Ovis 5460, but works for DLink DWL-G700AP also, though on my hardware the respective connector is marked as J2. To determine the correct connector layout find GND pin first: it is easily recognized by the special form of hole. As usual, DO NOT connect to PC’s COM interface as it will damage the router!

Configuration

The /etc part of file system is stored on ramdisk, so to make your changes survive reboot you should store them using fs save command.

In fact, configuration is more or less easy except WPA part: it is not explained anywhere and requires some non-standard steps.

First of all you will need the following two binaries: auth and iwcontrol. One possible source for them is official DLink sourcecode tarball for G700AP, for example found here, or search for them in INet or on forums listed at rtl8186.sourceforge.net. Also binaries from compatible firmwares (such as firmwares for some models of Edimax) are reported to work.

Put these binaries into firmware image and make sure they are started before wlan0 interface goes up; quick-and-dirty way of doing this is including their invocation into /etc/network/wifi/wep file, such as

...
iwpriv wlan0 set_mib encmode=2

killall auth
killall iwcontrol

auth wlan0 eth0 auth /etc/network/wifi/auth.conf
iwcontrol wlan0
...

Please note you will have to change in this file also encmode to 2 for WPA to work.

The auth.conf file content should be similar to the one listed in this topic.

My file for WPA-PSK is as follows:

encryption = 2
ssid = "Wive"
enable1x = 0
enableMacAuth = 0
supportNonWpaClient = 0
wepKey = 1
wepGroupKey = ""
authentication = 2
unicastCipher = 1
wpa2UnicastCipher = 2
enablePreAuth = 0
usePassphrase = 1
psk = "your-passphrase"
groupRekeyTime = 86400
rsPort = 1812
rsIP = 192.168.1.51
rsPassword = ""
rsMaxReq = 3
rsAWhile = 5
accountRsEnabled = 0
accountRsPort = 1813
accountRsIP = 0.0.0.0
accountRsPassword = ""
accountRsUpdateEnabled = 0
accountRsUpdateTime = 60
accountRsMaxReq = 3
accountRsAWhile = 5

In original DLink firmware this file is auto-generated from web interface, so you may get some additional info by studying DLink firmware sources.

Conclusion

So far everything seems to work OK, the only problem is that maximum 802.11g connection speed I saw so far was 24MBit/s, but I do not know yet whether this is the problem of firmware or in local environment as I have also another production WiFi router working in the same room.

Update: in another environment the tests have shown the speed of 54MBit/s with one WiFi card and 24MBit/s with the other one, so now I tend to think this may depend on client WiFi card type also.

In the end I wouldn’t recommend choosing DWL-G700AP as router for anything more than simple routing in the network with a couple of PCs: the hardware seems to run almost “on the edge” of its capabilities as CPU is not that fast and RAM/flash are severely limited: you’re unlikely to successfully setup and run there anything really “advanced”.