@PowerlineFW Do you happen to have some sort of documentation/description for the PIB format used for the QCA75xx ?

In particular, is there something like a threshold which locks out adapters? Or maybe a watchdog to reset this?

STA 000 18:A6:F7:A2:03:F6 18:A6:F7:A2:03:F4
STA 004 18:A6:F7:A2:03:F6 18:A6:F7:A2:03:F4

Under the assumption that STA 000 and STA 004 are 2 different adapters, they have (''share'') the same MAC address and only one adapter with that 'unique' address can join a network. If you manually unplug STA 004 then STA 000 probably will join the network.

You should change the MAC address of STA 000 or STA 004. Maybe you should manipulate one of the pib files by adding an unique mac.

modpib.exe -M A0F3C15C83E1 PIBFILE.PIB -v (this is the address of my adapter)

The problem that you must upload the pib file to the device but my attempts were never successful. Maybe the device must be in bootloader mode to overwrite a mac address.

plctool.exe -P PIBFILE.PIB 18:A6:F7:A2:03:F6 -v

(PIB file with a modified, unique mac address)

An other solution - which I never tried, and don't recommend - is to brick the device by unplugging the device during a firmware update and recover the device using the PLC Recover.exe for TP Link 7/9 PLC and 4/8 PLC series. This utility updates the firmware (pib + nvm) and changes the MAC address. I found this utility on the TP Community forum but never used it and does not detect working /non bricked adapters (at least that is what I've read).

https://www.dropbox.com/s/5ce432y8t0o1whr/PLC%20Recover%20Tool.rar?dl=0

@turboleak Thanks! Yes I did that... however stalled a year ago, when "they" demanded ath79 platform and not ar71xx ...

@Ariek These are the same two adapters. It's just one symptom of these lockouts, before and after a manual reset.

This particular symptom means: the station was joined to the network before, something/whatever happens, and it does not re-join the network on it's own, nor does a CCO change in the remaining network let the station join the network. 

Also interestingly, usually when there is a split and the other network is not "seen", bespoke station would then start a network of it's own being it's own CCO. This is not the case here.

It just stays as a station with no TEI assigned and the network not joined.

After manually sending a reset to the station, it rejoin happily.

@PowerlineFW @netadair Not sure if you already tried it but reset all adapters, let them join the same unsecure network ("HomePlugAV"; default network management key) and then create a secure network by changing the NMK for all devices using the tpPLC tool. This should force the problematic adapter to stay connected to or rejoin the existing secure PLC network with the same NMK.

@aNimorEs 

I am not sure either. I have tried updating today a 8630 (UK) (non-P) V2.0 from 2.2.2 to either 2.8 or 2.10 and I have not been successful.

The update fails in any of the 3 utilities I tried, either via Ethernet or via WiFi.

@turboleak , considering you have good experience with several 8630 versions, shall I give it a go using the cut-down nvm version 2.10? Or any suggestion to use a certain pib file?

At the moment I have obtained a backup of my own pib file at v2.2.2.

@pstlr78 

the cut down version is the only one I am able to flash on my 8010 v1 and v2 and on the 8630 v1, 8630p v2 and v2.1. If I try to flash the full version it always fails ( I use the latest tplink plc utility.

I would try the stripped 2.10 with the pib you backed up from each device and if that doesn't work then I would try a lower firmware version like 2.2.3 or 2.4 and then go for the 2.10.

@turboleak 

All good now. Thanks for the tip! I sucessfully flashed the 8630 v2 from 2.2 straight to 2.10 using the stripped down nvm version via the old tp-link utility.

As a side note, unfortunatelly my device came with the "forbidden" (to Openwrt) firmware as per below:

Considering you helped an Openwrt developer add support to 8630 (v2 and 2.1), is there any chance that this may be supported in the future by stable Openwrt? At the moment anyway some 8630 devices are only supported by snapshot, so I would be quite reluctant to go down this route. A stable branch though would be a different story (at least in practical terms).

@pstlr78 

Cool that it went smothly :)

Unfortunately I think that it is a quite remote possibility that those hardware versions get supported in the future. They appear to OpenWRT as the same hardware but have different partition layouts dependening on the OEM software version flashed. This means having a different build for the same hardware and different flash layout, something that OpenWRT doesn not support and I don't think it will. There were talks of using a "prep" image that would change the flash layout to be equal to all devices and from them use a single build for all but that would need someone working on it. Not sure if it will happen or even if that would be accepted by the OpenWRT devs.

The safe path right now is to sell your 8630 v2 and buy a supported version.

The V1 has better wireless ( 22dbm tx on the 2.4ghz instead of 18 or 20 ( can't remember ) on the 2.0 and 2.1 ).

The V1 has better flash layout for OpenWRT. More space for installing OpenWRT. On the 2.x it gets really thight.

The V2.X have better PowerLine ( QCA7550 instead of QCA7500 ).

I was able to flash my WPA8630 V2 (US) and PA8010 V2 (US) from 2.2.3 to 2.10.0 with modules stripped (neither would accept the non-stripped NVM) using tpPLC, the NVM here, and PIB that I extracted from each device through OpenWrt w/ plctool.

I was fortunate enough to have a V2 (US) that would upgrade to OpenWrt (see: https://github.com/jwmullally/openwrt_wpa8630pv2_patched_firmware). 

It would be nice if someone would build a luci-app-plc for these devices :)