D-Link DAP Series of Business Access Points

*not yet supported

DAP-2553 and DAP-2360 are currently unsupported due to issues with GMAC configuration on AR72xx when using an external Gigabit PHY (they only work when 100BASE-T is forced by the link partner).

DAP-2590 is based on the Cavium Octeon platform, there is experimental support here, which also includes support for setting an additional flag during wrgg03 image header generation, which is also required by DAP-2553 and DAP-2360.

DAP-1353 Rev. B1 seems to use the same design as DAP-2553 (without dual-band, PoE and Gigabit) and might be trivial to support, while Rev. A1 is based on an unsupported SoC.

All devices can be supplied via 802.3af PoE (.3at for DAP-2680 and DAP-2695).

Alternatively, DAP-2230, DAP-2610, DAP-2660 and DAP-2680 can be powered from a 12V supply, using a 3.5 x 1.35mm plug.

DAP-2695 can be powered from a 48V supply, using a special plug with center pin, the same as the PSU that comes with the DPE-101GI injector.

The Serial Console port is usually easy to spot, it is the same connector with a space between the first and second pin. Connection parameters are 115200 8N1.

As with many D-Link devices, these APs come with an HTTP-based recovery system that is activated by holding reset button down during power-on. However, most devices will perform a reset after detecting a rising edge of the reset line upon releasing the button (this behavior is most probably not intentional, but a bug in the bootloader). Thus, you need to keep the reset button pressed during all of the time from opening your browser at http://192.168.0.50, selecting the image and finally clicking the Upgrade button. The reset button can be released after uploading has started.

Please give the bootloader at least 10-20 seconds more time for upgrading even after the countdown has reached zero, before power-cycling the device!

Alternatively, you can connect a serial cable and press 'q' during boot. This will enter the http recovery just like the reset button. You can press 'q' again to enter uboot shell.

The default IP address for these devices is http://192.168.0.50. There is no DHCP, thus set your network interface to be in the same range.

Login as 'admin' and leave the password field blank.

Factory image can be flashed via the regular update procedure from the 'maintenance' menu.

After initially flashing the device to OpenWrt, flash a sysupgrade image again. This is not required, but allows you to use more space from the flash. See the next section for more technical details.

The factory image is created using the mkwrggimg tool, which generates the wrgg03 header and checksum.

To be flashable via the regular OEM Web UI, the size of the uploaded wrgg image needs to be at least 6 MiB (this might be just to prevent users from bricking their devices by accidentally flashing a language pack, which uses the same format).

However, since the whole image will be written to flash and the bootloader verifies the wrgg checksum on every boot, we can not have rootfs within the wrgg partition, since it will be expanded with jffs2 on first boot and cause a checksum mismatch whenever data is changed. Thus, the factory image contains the kernel padded to 6 MiB + squashfs, so that jffs2 will always be outside of the memory region covered by the wrgg checksum.

As soon as the device is running OpenWrt already, there is no more minimum size of 6 MiB, so we can put just the kernel in the wrgg partition, which will not cause the problem of a changing checksum.

So, when more flash space is required, a sysupgrade image can be flashed right after factory, to allow for using of all the available flash memory.

The recovery also does not have the minimum size requirement, however we shall prefer not to have three separate images (factory padded for web-flashing, factory unpadded for recovery, sysupgrade) when the padded factory image is also accepted by the recovery (but requires double flashing to use all of the available flash space).

struct wrgg03_header {
	char		signature[32];
	uint32_t	magic1;
	uint32_t	magic2;
	char		version[16];
	char		model[16];
	uint32_t	flag[2];
	uint32_t	reserve[2];
	char		buildno[16];
	uint32_t	size;
	uint32_t	offset;
	char		devname[32];
	char		digest[16];
}

In the wrgg03 image header, there is a 32 bit field called flags at 0x48, which is currently not set (i.e. remains zero) by mkwrggimg. For most devices, this is zero, however few older devices (DAP-2360, DAP-2553, DAP-2590) have the value set to 1. This field can be used by the manufacturer to release firmware updates that would introduce changes which do not allow for downgrading back to previous versions: While checking the header, the web-based updater will verify the value of this field to be the same or higher than the firmware that is currently installed. If any of the forementioned devices shall be supported, the option to set this flag to 1 needs to be introduced to mkwrggimg, e.g. as implemented in this commit.

All devices except DAP-3315 use the Edimax ELX header format, encapsulated within the legacy Alpha Networks wrgg03 header (for compatibility with the nuclias central management platform).

DAP-3315 only uses the ELX header.

Support for ELX header in OpenWrt is currently very simple; it seems additional fields need to be set in order to support these devices.

A hardware watchdog (SOT-23 reset IC) is used on most of these devices, requiring the kernel to continiuosly toggle the corresponding GPIO line, e.g. for DAP-2662:

watchdog {
	compatible = "linux,wdt-gpio";
	gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
	hw_algo = "toggle";
	hw_margin_ms = <1600>;
	always-running;
};