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
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)?
(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.
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.
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.
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.
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.
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
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.