Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| toh:d-link:d-link_dap_series_of_business_access_points [2021/01/13 20:30] – add serial console s_2 | toh:d-link:d-link_dap_series_of_business_access_points [2022/07/17 17:58] – [Model Overview] Add further devices by Alpha Networks s_2 | ||
|---|---|---|---|
| Line 6: | Line 6: | ||
| ==== Model Overview ==== | ==== Model Overview ==== | ||
| - | ^ Model ^ Wireless | + | ^ Model |
| - | | DAP-2230 | + | | [[toh: |
| - | | DAP-2660 | AC1200 | + | | [[toh: |
| - | | DAP-2680 | + | | [[toh: |
| - | | DAP-2695 | AC1750 | + | | [[toh: |
| - | | DAP-3320 | + | | [[toh: |
| - | | DAP-3662 | + | | DAP-2682* | AC2300 Wave 2 |
| + | | [[toh: | ||
| + | | [[toh: | ||
| + | | [[toh: | ||
| + | | DAP-X2810* | ||
| + | | DAP-X2850* | ||
| + | *not yet supported | ||
| + | |||
| + | [[toh: | ||
| + | |||
| + | DAP-2590 is based on the Cavium Octeon platform, there is [[https:// | ||
| + | |||
| + | 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. | ||
| + | ==== Power Supply ==== | ||
| + | |||
| + | All devices can be supplied via 802.3af PoE (.3at for DAP-2680 and DAP-2695). | ||
| + | |||
| + | Alternatively, | ||
| + | |||
| + | 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. | ||
| ==== Serial Console ==== | ==== Serial Console ==== | ||
| Line 36: | Line 55: | ||
| Alternatively, | Alternatively, | ||
| + | |||
| + | ==== Flashing ==== | ||
| + | |||
| + | The default IP address for these devices is http:// | ||
| + | |||
| + | Login as ' | ||
| + | |||
| + | Factory image can be flashed via the regular update procedure from the ' | ||
| + | |||
| + | 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. | ||
| + | |||
| + | ==== Factory Images ==== | ||
| + | |||
| + | 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, | ||
| + | === Image header format === | ||
| + | < | ||
| + | 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, [[https:// | ||