Hi, I tried QCA75XX-2.8.0.0030.nvm FW for PLC and is faster than 2.7.
I took it here : https://community.tp-link.com/us/home/forum/topic/204234
Are you US based ?
I'm in EU, that's why I picked the EU FW.
I think there was a newer version available in the Dropbox, but since it wasn't flagged as EU, I skipped it.
No, I'm EU based. It seems to work fine but I add a watchdog to restart plchost if ping is not ok.
If there are actually different firmware blobs (rather than country configurations) for e.g. US and EU, this might still be an issue as these devices use band plans to avoid ham and professional radio frequencies.
Do you happen to have an rtl-sdr DVB-T dongle or similar to verify both firmwares have the same spectrum of emissions? Would be curious to compare these, maybe higher speed was only reached by less notch filtering 
Hi,
After few months, many errors like this "deauthenticated due to local deauth request" are present in System log.
I'm trying this [Solved] LEDE 17.01.5 deauthenticated due to local deauth request every 10 minutes an adding this in /etc/config/wireless :
option disassoc_low_ack '0'
option wpa_strict_rekey '1'
option wpa_strict_rekey '86400'Since LEDE 17.01 and the ar71xx target are outdated, this device really should be ported to ath79 master.
I would appreciate if @netadair could share some information on how to create a signed factory-flashable image, however the current kernel also grew too big for the current oem mtd layout, so the dts needs to be changed to use okli loader, i.e. move the kernel image to the rootfs partition, and put a kernel loader image to the kernel partition.
I've done this for COVR-C1200 already and it's probably the same here. Maybe I'll find some time after the holidays to continue working on this device.
1 Like
Regarding the TP-Link PLC firmware mentioned earlier, I just found that the German Federal Network Agency actually banned the older series of TP-Link WPA-8630 devices, due to emissions exceeding the allowed levels.
Unfortunately, they did not specify whether it was about PLC or Wifi, but maybe this could be related to the PLC firmware not correctly notching out certain bands (e.g. the range from 28-30 MHz), thus reaching higher throughput than e.g. the D-Link firmware !?
But then again, this stuff should be in the .pib files, not in the .nvm.
Publication in German, page 3:
https://www.bnetza-amtsblatt.de/download/54
Besides, I'm making some progress with this device and ath79 
@netadair helped me out with the code for signing the factory firmware 
but the code is not ready for publication yet...
3 Likes
too bad about the ban, nice to see you made progress with the FW!
Hi, ready for testing 
The current state is, that there's a pull request for the COVR-C1200, which is basically identical in terms of hardware and factory image, except for the PLC - I started with that one to make the PR less complex, so that COVR-P2500 could be added later based on that:
Currently, I'm trying to refactor the factory image generation tool to fit both COVR and EXO (ramips) devices, i.e. produce images that are accepted by the OEM Web Updater. Overall, this may take a few more weeks / months / ... for the PR to be merged, but I will probably start releasing v21 images for both devices before that happens
2 Likes
Thank you for the update, much appreciated.
Hi, I'm starting trying QCA7500-2.11.0043_modules_5-6_stripped_for_usual_hardware.nvm for PLC from https://community.tp-link.com/us/home/forum/topic/204234. I tell you in few days if it's better 
1 Like
Many issues on 2.11.
QCA75XX-2.10.0.0032_modules_5-6_stripped.nvm is the most stable.
1 Like
Hi, any updates ? Always ready for testing 
Since further devices were introduced in the meantime, that are also built by SGE and use different RSA keys, the tool should be refactored to allow a more flexible choice of keys. Besides, I'm still not sure whether this would have any chance of being merged at all, considering DIR-842 crypto has been open for almost two years.
Meanwhile, the firmware-utils package was removed from the OpenWrt repository into a separate project, so this needs some refactoring and sending a patch to the mailing list, then updating the OpenWrt counterpart to match the incremented release version of firmware-utils.
Considering how quickly new devices are showing up on the market, that use similar but yet slightly different ways of generating factory images, I will not continue to maintain this as a C program (I only did initially since there is not pycrypto / pycryptodome available on the buildbots), when using Python would not only cut the development efforts to a fraction of those compared with C, but also provide way better code readability / maintainability.
I guess I will have to look into using the Image Generator, to provide a collection of images using the same kernel as the official ones, as to allow installation of modules.
Is anyone aware of using a static kernel with the toolchain, to avoid merging all patches into Image Generator?
1 Like
Thanks for updates 
I can't help you in development but I think i've resolved "deauthenticated due to local deauth request" on 5Ghz band.
I replaced "ath10k-firmware-qca9888" package with "ath10k-firmware-qca9888-ct" via web interface and no more disconnections. It works flawlessly.
I don't know if it can help but it works
OpenWrt switched to the Candelatech firmware for ath10k long ago, which is considered way more stable, especially for these Wave 2 chips.
Usually, this firmware would be complemented with the corresponding kmod-ath10k-ct driver, but I'm not sure whether you can install that via opkg on older snapshot builds.
Great to see that it also works stable with just the firmware 
Thanks for information
kmod-ath10k-ct is available, i try !
After few days, it works but powersave is too strong. Notifications are delayed.
That happens when I ping my phone :
C:\Users\Me>ping 192.168.0.14 -t
Envoi d’une requête 'Ping' 192.168.0.14 avec 32 octets de données :
Réponse de 192.168.0.14 : octets=32 temps=2922 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=1 ms TTL=64
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 192.168.0.14 : octets=32 temps=2261 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=1 ms TTL=64
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 192.168.0.14 : octets=32 temps=758 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=158 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=2516 ms TTL=64
Réponse de 192.168.0.14 : octets=32 temps=1 ms TTL=64
Statistiques Ping pour 192.168.0.14:
Paquets : envoyés = 13, reçus = 9, perdus = 4 (perte 30%),
Durée approximative des boucles en millisecondes :
Minimum = 1ms, Maximum = 2922ms, Moyenne = 957ms