Released v22.03.3. PLC not tested but it is supposed to work as on v22.03.2-plcfix.
"OEM Web UI" works only with stock firmware and requires dlink-sge-image that does not exist on upstream firmware-utils. Also at least some users had OpenWRT version 18.06 installed previously. "OEM Recovery UI" was mentioned on s-2's covr-p2500_plctest branch but I did not get it to work. Other methods can be used for recovery but these can also be used as alternative installation method.
MAC-7500-v2.2.2-03-X-CS.nvm from stock firmware is reported to be unstable. Questation marks means that complete url is missing.
plctool command is not working when eth0.3 is added to br-lan bridge interface. PLC service uses workaround to bridge ports only after PLC connection is established. Note is there because command in setup example works only when selection to question "Automatically add to br-lan bridge" is 0.
With current Linux, I cannot get it to work anymore either. It only works for me in Windows with old IE11, after several attempts, and rebooting into recovery again after loading the upload page in the browser
I created dlink_recovery_upload.py script for Linux that allows upgrading firmware with the Recover UI. The script waits ACK after every TCP packet by checking that tcpi_unacked of tcp_info struct is zero. The recovery UI also seems to work with Internet Explorer 6 on Windows XP without any problems.
I had always wanted to build something in Python to allow flashing again, last thing I remember was that I couldn't use the requests library or even the raw urllib2 that it is based on, since the old HTTP 0.9 (I'm not sure if it was this device or older D-Links) was not supported at the low level; e.g. you would receive <html>... instead of 200 OK on the first response line, which urllib tried to throw into some integer parsing function...
So it was obvious this needed to use raw TCP sockets and implement all the http form uploading stuff with multipart boundary, so my idea was to get acquainted with Python asyncio and implement some throttling, like having a callback function after each TCP packet, and waiting longer on the first few hundred packets but then increasing speed, so the server could finish any tasks that are only required initially.
Didn't know about the TCP_INFO, and that you could use such low level TCP in Linux
Great to always learn something new!
dlink_recovery_upload.py now also supports Windows (Windows 10, version 1703 or later) using WSAIoctl and TCP_INFO_v0. The script can also be used to restore unencrypted original firmware binary.
Still can‘t get PLC to work properly with release v22.03 and QCA75XX-2.10.0.0032_modules_5-6_stripped.nvm Sometimes a network has been established between two devices, but no ip traffic flows over plc. Most of the time the two devices won‘t pair. I have no clue what is the cause, log is unobtrusive. I didn’t bridge eth0.3 to lan, so what am i missing?
I tried a lot of configurations and in the end I made a VLAN between the PLC and WAN Port. I had to do an external bridge between Port 3 (WAN) and 2 and then the WIFI works great with the PLC.
Surely there is also a way to make it work without this external bridge, but I didn't figure it out how.
No connection issues so far if only two devices share the same "NetworkPasswd" for the PLC. Otherwise they try to reconnect all the time.
So just adding plc to the br-lan bridge did not make it work? Probably needs DHCP to be disabled on the remaining devices before providing the PLC Network Password, though I hadn't tested this scenario.
I had used these devices successfully for meshing with gluon (i.e. batman-adv), which required manually declaring the proto to be used with that interface, but I also had not tried more than two devices.
PLC should allow for 16 devices within a network (i.e. a single central coordinator), what happens when you add more than two, is there any output from the plc adapter in the console, besides the LED flashing pattern?
Could you post the output of /etc/init.d/plc restart (or whatever the name of the plc init script is) ?
Maybe the script needs to be adapted to bind plchost to br-lan rather than the hardcoded name of the plc interface, to serve the plc firmware to the chip. But it still would not explain why it is being restarted n the first place, unless you rebooted after plying network settings.
This looks as it should, the only error being on interface shutdown (can't read eth0.3: Network is down) which is expected. Running out of ideas on what else to try here
I found out another important fact that everybody should be aware of. If somebody uses the same solution as me keep in mind it works only if the PLC uses the VLAN ID 3 (three). Otherwise the PLC drops the connection instantly.
The flashed devices are compatible with the TP-Link "PowerLineUtility", so it should be possible to add every brand to the network which shares the same "HomePlug AV2" standard. I'll do some more tests during the next days.
That's amazing! Since these are technically two devices, does flashing via the OEM Web Interface update/install OpenWRT on both devices or is the process required for each device?
@jokujossai
Looking through my devices backlog, I would still like to add support for COVR-C1200.
I remember there was this branch in your repo:
Can I use this for creating a PR, or would you like to? I could happily test on various revision, although I remember everything worked back then (was just waiting to get P2500 merged, which has meanwhile happened). I just have to check what has changed in OpenWrt in the meantime, in terms of conventions and things to be considered while rebasing .
Filed the remaining PR for adding C1200, was quite a hassle to rebase, conflicts due to changes in LED declaration etc. (making sure the .dtsi would not alter P2500 in current master), hope everything looks good now (yet again).
I could happily test on various revision, although I remember everything worked back then (was just waiting to get P2500 merged, which has meanwhile happened). I just have to check what has changed in OpenWrt in the meantime, in terms of conventions and things to be considered while rebasing 
.