Support for D-Link DIR842 (Rev C3)

I've seen the same behavior on a C1 I just got used off ebay. art partition at 0x5000 is all 0xFF to the end of the partition.

Do you still have the stock firmware and UART connected? I found an image for the C1 I could extract the sqashfs and dug into ath10k driver they use; they select the firmware in qca_ol.ko:ol_get_board_id() but I'm a bit confused by the parameter they are looking at to select the file; can you paste the full dmesg output after wireless is brought up? I'm looking for all the lines that start with ol_

1 Like

Hi there,

I am planning to purchase a DIR 842 (I think would be C3). You recommend it? It works well with OpenWrt? The problems with the ART partition are fixed?

Thanks.

Since flashing via the recovery can be annoying, I've added support for the 'new' image format that can be updated via the normal Web UI.

Actually, for DIR-842 C1, C2 and DIR-859 it is just the same image, encrypted with an AES-256 key that is found in the official GPL sources released by D-Link, xor'ed with SEAMA_SIGNATURE.
For DIR-842 C3, the signature for the new image has EU appended.

Feel free to test the 'new style' factory images, that can be updated directly from the D-Link Web UI, there's no more need for flashing via the emergency recovery :slight_smile:

openwrt-ath79-generic-dlink_dir-842-c1-squashfs-factory-webflash.bin
openwrt-ath79-generic-dlink_dir-842-c2-squashfs-factory-webflash.bin
openwrt-ath79-generic-dlink_dir-842-c3-squashfs-factory-webflash.bin

Before opening a pull request, I would still like to verify:

Has anyone actually encountered a 'non-EU' Revision of C3 out there?
I suppose the C3 is only available as the EU variant, i.e. we probably don't need to add yet another factory-webflash.bin image for the SEAMA_SIGNATURE that does not have the EU suffix appended?

@Cjcr: I've been running OpenWRT on many of these devices without encountering any problems (one of them is running a gluon / Freifunk firmware with an uptime of more than 10 months :slight_smile: ).

I could not reproduce any difficulties regarding the art partition, but I could check my devices again soon to see if there are any differences.

@s_2 Thanks for the excellent work. I have not encountered a Rev C3 which is not EU.

1 Like

Thanks, so I will only include the EU signature for C3.
Even if there were a non-EU C3 version, it could still be flashed via the recovery just like before.

Now I'm just waiting for someone to test DIR-859, since I do not own that device:

Hi, I only learned about OpenWRT a couple of weeks ago so it's been a pretty steep learning curve for me. Sadly I only started to research custom router firmware after I bought my new router, so it was a bit frustrating to find that my new DIR-842 wasn't supported in a stable release. I've been following this thread and the guidance on the device page to get my router happily running openwrt.

I just wanted to post here to say thanks to everyone who's already been working hard to provide support for this router, and to add my specific model to the list of tested devices. I particularly want to thank @s_2 for providing the encrypted stable binaries and to @blabla for the fix to the missing 5GHz radio problem!

I'm looking forward to getting involved with the communty!

S/N: EIR842MEU....C3E
H/W Ver.: C3 F/W Ver.: 3.13EU
S/N: SY6A2JA001XXX

Welcome to the community!

It's interesting to see that many users have issues with the 5 GHz wifi, and it's quite confusing how many threads we have for this device by now...

So I assume this is the fix that worked for you:

Could you check whether the problem might be related to the position of the art calibration data? I recall summarizing the issue before in this post:

So I'm wondering what is the output of hexdump -s 0x5000 /dev/mtd9 for your device, maybe we already found two solutions to the same problem :sweat_smile:

One of my devices says

H/W Ver.: C3 F/W Ver.: 3.10EU
S/N: SY6A2IA00XXX

on the label, and 5 GHz works out of the box with the current snapshots, so it seems they changed something to the mtd layout after that. This should definitely be fixed... (but currently I'm still hoping I could eventually finish rewriting image encryption in C this weekend :innocent:)

Yes, the board-2.bin fix worked for me. My mtd9 dump does indeed just contain ff.

root@OpenWrt:~# hexdump -s 0x5000 /dev/mtd9
0005000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000

I'd be happy to try out the caldata_extract fix as that feels like a more sustainable solution :+1:t2:

Hello,

I got a C1 revision with the same problem. I also used board-2.bin fix. Here's the dump for mtd9:

hexdump -s 0x5000 /dev/mtd9
0005000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000

Another thing, it seems radio0 (2.4GHz) is seen as "Generic 802.11bgn". Any idea why?
Thank you for your work.

1 Like

Interesting, so you seem to have the caldata at 0x15000 in the reserved partition then?

It is probably called mtd10 (or maybe mtd8 if it's located below the art partition on your devices!? also the offset of 0x10000 initially made it seem like there might just be an issue with the mtd partition layout being changed in the oem firmware, so that

hexdump -s 0x15000 /dev/mtd10

would point to the correct new location in the flash, though this might actually still be named art in the oem firmware, just with a different physical location...

Anyways, I had a look at the board id stuff, never knew about this in ath10k, but in the oem bootlog of my (unaffected) C3 3.10 I found:

[   26.280000] ol_target_init() BMI inited.
[   26.280000] ol_target_init() BMI Get Target Info.
[   26.290000] Chip id: 0xc, chip version: 0x1000000
[   26.290000]
[   26.290000]  CE WAR Disabled
[   26.300000] NUM_DEV=1 FWMODE=0x2 FWSUBMODE=0x0 FWBR_BUF 0
[   26.300000] ol_target_init() configure Target .
[   26.310000]
[   26.310000]  Target Version is 1000000
[   26.310000]
[   26.310000]  Flash Download Address  c0000
[   26.320000] ol_transfer_bin_file: flash data file defined
[   26.320000] ol_transfer_bin_file[4706] Get Caldata for wifi1.
[   26.330000] qdf_fs_read[59], Open File /tmp/wifi1.caldata SUCCESS!!file system magic:-2054924042super blocksize:4096inode 4848file size:12064qc98xx_verify_checksum: flash checksum passed: 0xa54e
[   26.350000] ol_transfer_bin_file 4767: Download Flash data len 12064
[   26.360000] Board extended Data download address: 0x0
[   26.390000]
[   26.390000]  Board data initialized
[   26.390000] ol_ath_download_firmware: Download OTP, flash download ADDRESS 0xc0000
[   26.400000]
[   26.400000]  Selecting  OTP binary for CHIP Version 0
[   26.460000] ol_transfer_bin_file 4587: downloading file 0, Download data len 9084
[   26.500000]
[   26.500000]  First OTP send param 8000
[   26.740000] ol_ath_download_firmware :First OTP download and Execute is good address:0x4800 return param 4660
[   26.750000] ol_ath_download_firmware:##Board Id 18 , CHIP Id 0
[   26.760000] ol_ath_download_firmware: BOARDDATA DOWNLOAD TO address 0xc0000
[   26.770000]
[   26.770000]  wifi1: Selecting board data file name boardData_2_0_QCA9888_5G_Y9582.bin
[   26.780000]
[   26.780000] ===find alpha boarddata===
[   26.780000] qdf_fs_read[59], Open File /lib/firmware/QCA9888/alpha_hw.2/boardData_2_0_QCA9888_5G_Y9582.bin SUCCESS!!file system magic:-2054924042super blocksize:4096inode 2294file size:12064qc98xx_verify_checksum error: flash checksum 0xffff, computed 0xffff
[   26.810000] ===road alpha boarddata fail, used orignal QCA boarddata===
[   26.810000] ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=QCA9888/hw.2/boardData_2_0_QCA9888_5G_Y9582.bin
[   26.840000] ol_transfer_bin_file 4587: downloading file 3, Download data len 12064
[   26.840000] QC98XX overwrite boarddate !
[   26.850000] Overwrite 5G ctl power for countrycdoe 250
[   26.850000] Board extended Data download address: 0x0
[   26.880000] ol_ath_download_firmware: Using 0x1234 for the remainder of init

Curiously, the file boardData_2_0_QCA9888_5G_Y9582.bin would not even unpack correctly with ath10k-bdencoder.py, but it seems we might just need a patch for the board-2.bin in OpenWRT, so that all versions of this router would be supported automatically!?

I know too little about this BMI stuff (actually just learned about its existence :innocent: ), but there is also an entry for variant=OM-A62.bin in the unpacked OpenWRT board-2.bin, which was apparently added for the OpenMesh A62:


Particularly, there is this commit that just updated the ath10k-firmware, which introduced many new board-ids:
// Edit: don't be fooled by Discourse to click on the fat blue link, instead use the gray one above that for the actual commit...

So it looks like the problem would be sorted out by just waiting, however the ath10k firmware was changed to candela tech in the meantime, and the latest update was merged in March:


Maybe ct forked it from a previous version that did not inlcude board-id 31?

But again, I know too little about this stuff, I'd rather concentrate on finishing the firmware encryption c program for now :innocent:

1 Like

It seems that someone owning a revision of this device affected by the 5 GHz issue should probably submit a board file for bmi-board-id=31 according to the linux wireless wiki:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles

I wonder how quickly this would be included in the ct firmware though :thinking:

A post was split to a new topic: TP-Link WPA8630P V2.1: Add support for QCA9888

Awesome, I just found there was a recent change in the OpenWRT repo regarding cal-data extraction for these devices:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4d36569b9cab6422d31bda5501718177f2f9c990

I wasn't aware there is an existing function caldata_valid that can be used for these cases.
5Ghz is still working perfectly for the 3.10 hardware, and I'd assume this is the same for 3.13 now, thus bmi-board-id not being part of the issue.

Great to see support for these devices becoming more mature! :slightly_smiling_face:
Now there's just the factory image encryption left, before making a pull request to gluon:

With yesterday snapshot (r15237-fca0eb2d92) I do not have 5GHz issue anymore if I set radio.htmode to HT80 (board-2 edit is not required anymore).
I have issues when HT160 is set so I let it set to HT80.
On the other hand, I can now configure multiple SSID on 5GHz band (at least 2).

I recently acquired this device and was wondering what needs to be done to get it supported in the stable releases. Anything I could support with?

Hi,

this device is already supported in the snapshots, so it will be part of the next release.

However, the Pull Request for the encrypted image (see above) is not yet included, so you would either have to flash the snapshot (which does not come with LuCI, and thus is cumbersome to configure) via the emrgency recovery (which is cumbersome as there's no DHCP and only few browser work flawlessly)... or you could use my image for now :slight_smile: It is flashable from the normal D-Link Web UI and also contains LuCI :slight_smile:

http://sebastianschaper.net/openwrt/openwrt-ath79-generic-dlink_dir-842-c1-squashfs-factory.bin
http://sebastianschaper.net/openwrt/openwrt-ath79-generic-dlink_dir-842-c2-squashfs-factory.bin
http://sebastianschaper.net/openwrt/openwrt-ath79-generic-dlink_dir-842-c3-squashfs-factory.bin

3 Likes

Thx, I already flashed the snapshot. I don't have any issues with working on the console. I was just wondering if there is anything that needs to be done as I saw the support was added in a commit back in 2019 yet it is not part of the 19.07 release. But to be honest I haven't really checked the release schedule in detail :wink:

Device support is usually not backported to older releases, so when a device was merged into master in mid-2019, it may as well take until 2021 until it is contained in the next release... (not taking into consideration the time that passed from opening the Pull Request until merging, which might as well take around half a year)

Flashed latest snapshot.
r15949-ce8b535ed3
DIR-842 C3
Working nicely. I tried the @s_2 firmware but 5ghz wasn't working.

I'm using it as an "DumbAP"+Switch.
It was a bit trial and error, till i got an working/active connection (ping), through the bridge interface.
And also using vim which i don't like, prefer nano. But after getting dns working&ping, "opkg install luci nano".
And works fast, web interface good. And 5ghz works with the expected speeds :smiley:

1 Like