Viewing Powerline status from TP-Link WPA8630P v2

[natevw]

I have a TP-Link WPA8630P v2 (QCA956X) that's running OpenWrt 21.02.0-rc1 currently. It's specifically a US model but uses the tplink_tl-wpa8630p-v2-int sysupgrade images.

Anyway, I am trying to troubleshoot why the "house" light on the box sometimes turns orange instead of its usual green. I suspect it might be some sort of Powerline signal degradation and would like to get details about that connection like the original OEM firmware used to show.

To that end I installed (part of) the open-plc-utils package to query the status but it doesn't work:

opkg install open-plc-utils-plcstat
plcstat -i eth0 -t
  # …no error, no output, just returns to shell

Based on the examples I found at
https://fitzcarraldoblog.wordpress.com/2021/04/23/using-open-plc-utils-in-linux-with-powerline-homeplug-adapters/ I expected the plcstat command to dump out a bunch of lines listing all the active PLC transceivers and their TX/RX rates. Instead it just outputs nothing.

Similar when I install the plctool instead; most commands when given the -i eth0 adapter just silently yield no errors but no useful information either. With the default eth1 adapter the commands do complain e.g.

# plcstat -t
plcstat: eth1: No such device

Shouldn't I be able to query PLC status from the OpenWrt shell on this device? Does it depend on any particular network setup e.g. would the fact that I have VLANs active on its Ethernet switch interfere with however it polls the underlying Powerline adapter(s)?

[jwmullally]

See this section on the wiki for some example plctool and plcrate commands.

I see the same orange light on my WPA8630P v2.0 (EU) every once in a while, (maybe once every hour?), but the connection seems stable.

The different open-plc-utils tools target different QCA PLC chips. You can see which in their man pages, e.g. plctool supports QCA7000 (which it seems covers the QCA7550 in these devices).

# plctool -i br-lan -m 98:da:c4:12:34:56
source address = 98:DA:C4:12:34:56

	network->NID = 21:A2:03:81:8F:33:01
	network->SNID = 2
	network->TEI = 4
	network->ROLE = 0x00 (STA)
	network->CCO_DA = 34:E8:94:12:34:56
	network->CCO_TEI = 2
	network->STATIONS = 1

		station->MAC = 34:E8:94:12:34:56
		station->TEI = 2
		station->BDA = 44:FB:5A:12:34:56
		station->AvgPHYDR_TX = 586 mbps Alternate
		station->AvgPHYDR_RX = 546 mbps Alternate

# plcrate -i br-lan
br-lan 98:DA:C4:12:34:56 34:E8:94:12:34:56 TX 399 mbps Alternate
br-lan 98:DA:C4:12:34:56 34:E8:94:12:34:56 RX 390 mbps Alternate

Note if you change the VLAN your PLC interface is attached to, you'll need to change the -i argument of those commands to the CPU's VLAN ethernet interface, E.g. plcrate -i eth0.2

[natevw]

@jwmullally

Note if you change the VLAN your PLC interface is attached to, you'll need to change the -i argument of those commands to the CPU's VLAN ethernet interface, E.g. plcrate -i eth0.2

Thanks, this is helpful as at least I had completely forgotten that what LuCI shows as "LAN 4" under the switch settings is the Powerline adapter.

However in this case it's unclear how I should proceed since the Powerline is a trunk back to my main router and so it's "tagged" on all VLANs:

(Sorry for the greyed-out screenshot, as you can see I hastily set it the Powerline to "untagged" to see if that would help the PLC utilities work via eth0.1 but doing that made me lose access to the router, and the automatic rollback doesn't seem to have happened, and so now I have a little side quest to work through before I can test anything else out )

But if both the CPU and the PLC interface are tagged on all VLANs, which interface would I use then? That's why I stuck with the generic eth0 in most of my testing, although I did occasionally try br-lan/eth0.1 which didn't help at the time.

[natevw]

Progress! With "LAN 4" left set to "untagged" (and procuring access by temporarily reconfiguring an upstream switch to add the VLAN1 tag…) the plcID tool I currently have installed does give results.

Curiously it gives results for -i br-lan (which is still configured as "bridge" but currently only over eth0.1 alone) but not -i eth0.1 or -i eth0. In all three cases what I take to be its outgoing packet displayed by -v is exactly the same, but only on br-lan does it get a response.

Update: if I turn off bridging on br-lan via LuCI then the PLC tool does work with -i eth0.1…

Update 2: leaving eth0.1 unbridged, but turning VLAN1 back to "tagged" on "LAN 4" makes plcID -i eth0.1 -v -n go back to not working. So the VLAN configuration is definitely relevant afaict.

[jwmullally]

Yes, for the PLC control Ethernet packets to reach from OpenWRT on the CPU to the PLC, you need the specific VLAN ID to be "CPU = tagged", "LAN 4 = untagged". From a networking point of view, the PLC is just an Ethernet device connected to one of the switch ports.

This page on the OpenWRT wiki has some helpful info on VLANs.

Re: bridging, I found that too. If the ethernet interface for that VLAN ID is part of a bridge, the PLC utils must be given the bridge interface, not the enslaved interfaces, which I guess is a function of the Linux kernel ethernet L2 routing.

[natevw]

@jwmullally

Yes, for the PLC control Ethernet packets to reach from OpenWRT on the CPU to the PLC, you need the specific VLAN ID to be "CPU = tagged", "LAN 4 = untagged".

Confirmed, this is the secret sauce! And to be clear which ID is used as "the specific VLAN ID" doesn't appear to matter, which leads to something of a decent workaround:

I set my VLAN1 back to "tagged" on both CPU and PLC switch ports but added a new VLAN1234 which, as described above, needs to be set as "tagged" for the CPU and "untagged" for the PLC (/LAN 4) switch port.

Since I had to explicitly add an interface anyway (i.e. eth0.1234 didn't magically become available just because I configured it on the switch) I named it "plc" and then set it to bridge over the switch eth0.1234 device.

Et voilà!

Now [after I switch which package is installed…] I am able to run plcstat -i br-plc -t and get back info about all PLC transceivers!

Now if only this router had enough overlayfs space that I could install more than one of the open-plc-utils-* packages at once

[natevw]

Figured while it's fresh I'd add a few additional notes here in case it's helpful to someone else (/future me)…

The only current mention of VLAN stuff in the open-plc-utils issue tracker is an aside on a different thread including this brief comment posted by an account in the qca organization:

I don't think interfaces with VLAN tagging enabled are fully supported yet.

Looking at the packets logged when adding -v to the args for most any of the tools I see they start with:

00 B0 52 00 00 01 42 42 42 42 42 42 88 E1 00 00

The first six bytes are the destination MAC, the next six are the sender MAC [which I've redacted but matches the MAC of all the eth0.x interfaces on this router]. According to some HomePlug AV2 specs I've been able to chase down, the next two bytes are then "optionally" the VLAN ID, followed by two bytes 88 E1 which iiuc is a magic number assigned for the HomePlug protocol.

But in these tools it's just 6 bytes destination + 6 bytes source followed immediately by that 88 E1 tag instead of something like 81 00 nn nn 88 E1 for the VLAN info.

So I'm not sure exactly whether it breaks down when sending v.s receiving the responses back [I suspect the latter], but regardless, since the tools are generating untagged raw packets it must somehow help for the switch port itself to be expecting untagged packets too.