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
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 )
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 ), 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
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:
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!
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).
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 It is flashable from the normal D-Link Web UI and also contains LuCI
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
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
I tried that today on my DIR842 C3, feedback/comments:
the C3 factory bin from @s_2 could not be loaded at all from the recovery mode web page
I followed the steps in the video instruction then install page, luci could not be installed, inconsistent package from the snapshot, tried "--force-depends" which seemed to work, then ended with errors when I tried editing the wireless config in the UI
The recovery will accept only the unencrypted image, i.e. the ones already available from OpenWRT snapshots; LuCI can be installed on these but only on the same day, since at night everything will be rebuilt and the new packages won't match your kernel version anymore...
My pull request for creating factory images that can be flashed via the normal Web interface has been open for almost a year now, thus it did not make it into the branch for the v21 release.
So, waiting for the next stable release will at least allow you to install additional packages later, but flashing will still work via the recovery only...
@ s_2 My C3 with firmware 3.14EU would enter emergency recovery and flash about once a second but I could not access the recovery page. My pcs interface was set in the same range and I even used nmap to check for any open port with no success. I was ready to give up and found your .bin file and that worked. So thank you!
Flashing via the bootloader is often cumbersome, even after a single failed attempt (e.g. wrong browser / image format / timing / TCP receive window / whatever...) the embedded webserver may reach an undefined state and flashing is no longer possible. So it's generally a good idea to power-cycle the router (with reset button pressed) after every failed attempt of flashing via the bootloader...
Maybe that's why you couldn't reach it, usually it should respond at 192.168.0.1, regardless of the browser that is used.
Some browsers like Firefox unfortunately change the URL bar to https immediately whenever there was no network route to the host, this can be very annoying.
Also for devices with single Gigabit PHYs (this should not affect DIR-842 though, since it has a Gigabit switch), the Ethernet cable must be connected before powering the router and entering recovery (the PHY will be initialized only once, for the link speed detected at that time).
Please update to the latest snapshot though (or v21 when it comes out), the images above were mostly provided to help with initial flashing
I spent quite a long time trying to access the recovery page, and could not even see an open port while it was in recovery mode. I power cycled it multiple times and tried with the ethernet cable connected/disconnected while powering on and holding reset and in multiple different ports. I tried varying the amount of time I held the reset button when it started flashing all to no discernible effect. My pc was not connected to any other network while attempting this so it was not due to an IP conflict with an existing router. Not sure why it did not work but I'll attribute it to a fluke. I'll know if I decide to flash another one as my workplace scrapped a number of them and I saved them. I'll be sure to upgrade to the newest snapshot and thanks again for your assistance.
If this persists with other devices, could you attach a USB TTL adapter and capture what happens when pressing the reset button? Does pressing the reset button shortly work to reboot the device? (just to make sure it's not a hardware issue).
Maybe they changed something to the bootloader to prevent entering recovery
Which country are you located in? Actually, for many markets D-Link will only offer the encrypted firmware for download, so that users could not even recover their bricked devices, and even D-Link folks themselves don't know about this... very hilarious forum thread actually:
...
So maybe they now removed the recovery altogether, to avoid further confusing their customers
Hello. What is the current status with OpenWRT firmware stable releases for the DIR-842 C3?
My device info:
Model Name: DIR-842 Hardware Version: C3 Firmware Version: 3.14EU
Should I use the reset button to access the recovery UI and flash the factory.bin (and then sysupgrade.bin). Or the stable release can be flashed directly through the router's firmware update page?
)
), but there is also an entry for 
It is flashable from the normal D-Link Web UI and also contains LuCI 
