Recently I picked up a used DIR810L as a cheap testbed to hack around on until I find
a model that meets a complicated list of low-budget requirements.
These are notes of my experience so far with it.
This turned out to be a rev A1. First I tried upgrading the D-LINK firmware to the latest.
Quite opposite to the experiences of other people posted on the web, I found the regular
UI would do this just fine, but the web-based failure mode would not upgrade the image
(it would tell the browser to display a countdown and an "Upgrade Successfully" message,
but then just sit there and never reboot.)
The same was true when I installed a git build of LEDE. So I'm kinda stuck on this version
or whatever I can "recover" to unless I break down and wire up the UART... no way to flash
an entirely new firmware. Note I did have to add the custom signature. I also deciphered
that trailer so it would be possible to build a utility other than the sourceless 32-bit binary in the
so-called D-LINK "OSS" tree. This is the format:
Append 5 TLVs with one byte tag, then one byte length, and then a string as follows:
Tag string for rev A1 ...or... String for rev B1
0 DIR-810L DIR-810L
1 A1 B1
2 WW WW
3 1.0 1.0
5 1.03b01 2.03b02
Then if the image end is not aligned on a 4-boundary, pad with a single 0x20 byte, if needed pad with a 0x00 byte, and if needed pad with a 0x61 byte. That might be different on the B1. It's a mistake in the code... so it is possible the intention was to pad with all 0x20s and the values may or may not matter at all.
Next, append a final TLV of type 4 length 4 with the length of the entire file including everything you just added, and add 4 to account for this TLV itself, MSB first.
Then append a four byte "CRC" with is not a CRC, just an XOR sum of all 4-byte words in the file, including everything we just added.
OK... so I compiled the MT7620/DIR810L target and did manage to get it loaded. Some packages were missing due to me not knowing what exactly to include and how, so went to the lede emergency mode and scp'd stuff in until it was accessible after a normal boot.
Got locked out trying to config the switch a few times and had to go back to emergency mode (really the switch config LUCI page needs to be able to revert after N seconds if not confirmed). Easiest thing for the switch here is to add dir-810l|\ above whr-300hp2|\ in /etc/board.d/02_network (it has the same mapping as that model) and add a dummy switch an switch_vlan statements /etc/config/network to get LUCI to offer the page and reboot. Add them right under loopback. Note if you try to set up a bunch of switch_vlan statements and interfaces LUCI can do strange things to the config when it reorders them... don't mess with them once under LUCI's control.
Played a bit with the wext-based softap which is your only current hope of getting 5G working on a mt7610E... look for Archer C2 threads for links to a modernized build tree for this. Decided this was not worth my time since I'll be getting a model with a supported chipset eventually, and don't want to pull more factorycode-based daemons in just for WPA-Enterprise.
Then tried the 2GHz driver, found it won't do MFP, and the output power is cripplingly low (a near touching device gets -80db.) SO low I popped the case to look whether the previous owner had stolen the antenna cables, but they looked fine. Note to self for next time... config an SSID on the original firmware and test power levels so you don't have to wonder about crap like that after installing LEDE.
Compared the values in /dev/mtd2 eeprom with what is in the eeprom in the D-LINK "OSS" tree for this model. Quite some differences, and differences that plausibly explain the uber-low gain. Though, every linux utility seems to think the gain is successfully set to whatever I set it to up to +30dBm.
Now exploring whether there's a "proper" way to override the EEPROM until I get sick of it and just move on to
testing someone's DHCP-snooping ebtables thing from github and just getting firewall rules preconfigured so
when I buy a real device I have them ready. Going to throw some more printks in some .ko's to doublecheck the mt76 driver is using the eeprom gain values as well.
Note that I never went through D-LINK's web product registration, curious to know if EEPROM from another user who has done this is different (or seeing other folks's /dev/mtd2 contents for either A1 or B1 models.)
(here's mine, the 7620 is section is the soc and the 2.4GHz wifi, and all the txpower registers
that are set to 0x14 and 0x15 are set to like 0x2s and 0x3s in the mediatek "OSS" file MT7620_AP_2T2R-4L_V15.BIN)
0000000 7620 0105 1100 0022 c501 ffff ffff ffff
0000010 ffff ffff ffff ffff ffff ffff ffff ffff
0000020 ffff ffff ffff ffff a0c0 e3bb 1cb1 1100
0000030 0022 c701 0c22 c004 ffff 015a 7755 aaa8
0000040 888c ffff 000a 0000 0000 0000 0000 ffff
0000050 ff82 1414 1414 1414 1414 1615 1817 1919
0000060 1a1a 1a1a 1a1a 1b1b 1b1b 1b1b 1c1c ff80
0000070 ffff ff80 ffff 0000 ffff ffff ffff ffff
0000080 ffff ffff ffff ffff ffff ffff ffff ffff
*
00000d0 ff28 ffff ffff ffff ffff ffff ffff 0808
00000e0 0606 0002 0606 0002 0606 0002 0606 0002
00000f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0008000 7610 0100 1100 0022 c801 7610 14c3 0000
0008010 0000 7610 14c3 0000 0000 0c00 4643 0100
0008020 ffff 9fff ffef 3e30 9b3c ffff ffff ffff
0008030 ffff ffff fd11 1008 ffff 015a ffff 9999
0008040 888c 07ff 0a00 0000 0a00 0000 0a00 ff00
0008050 80ff 0000 0000 0000 0000 0000 0000 0000
0008060 0000 0000 0000 0000 0000 0000 0000 ffff
0008070 ffff ffff ffff ffff 1313 1112 0f10 0e0e
0008080 0c0d 0b0c 0d0d 0f0e 100f 1111 1212 1313
0008090 1414 1415 1414 1414 1414 ff15 ffff ffff
00080a0 ffff ffff ffff ffff ffff ffff ffff ffff
*
00080d0 ffff ff20 7440 ff95 ffff ffff 9b64 0000
00080e0 3d3d 3c00 3d3d 3c00 3d3d 3c00 3d3d 3c00
00080f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0008120 0808 0006 0808 0006 0606 0004 3a3a ffff
0008130 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000
If you try one of these, good luck to you.