Devolo Dlan 1200 Wifi AC device (non-pro version)

[SteveAyre]

I've successfully built openwrt 18.06.01 for the dlan-pro-1200-ac with dlan-openwrt and the MT2675 PIB & NVM driver from firmware.QCA9882-v2.2.0_2018-07-26.dv and installed this on the white non-pro version.

While it boots fine and LAN and Wireless both work I am having trouble getting PLC to work. All commands appear to give an immediate 'read timeout or network error'.

For example:

root@OpenWrt:~# /usr/bin/plctool -i "$PLC" -B"1" "$MAC"
br-lan 30:D3:2D:C3:FD:D6 Join Network
plctool: PushButton: Read timeout or network error
root@OpenWrt:~# 
root@OpenWrt:~# /usr/bin/plctool -i "$PLC" -B"join" "$MAC"
br-lan 30:D3:2D:C3:FD:D6 Join Network
plctool: PushButton: Read timeout or network error
root@OpenWrt:~# /usr/bin/plctool -i "$PLC" -B"status" "$MAC"
br-lan 30:D3:2D:C3:FD:D6 Fetch Network Status
plctool: PushButton: Read timeout or network error

Is it possible for this device to be supported?
Would it require further changes to OpenWRT or should the pro target be suitable?

Any idea what would cause the Read timeout error?

[dvlemplgk]

Hi Steve

The plctools don't work properly on bridge interfaces, you'll have to provide the underlying eth interface where the PLC chip is connected to. In this case it's eth0. And there are stray 'br-lan' and 'Join' arguments in your commandline above. Positional parameters must be MAC addresses.

e.g.
/usr/bin/plctool -i eth0 -B 1 "$MAC"
/usr/bin/plctool -i eth0 -B join "$MAC"

where MAC = the mac address of the PLC chip, which is configured in the pib during boot up.
You can get it with
plctool -i eth0 -a

[dvlemplgk]

If you build the packages, the firmware and pib you extracted from firmware.QCA9882-v2.2.0_2018-07-26.dvl must be copied to the directory qca/dlan-pro-1200-ac. Firmware must have extension .nvm pib must end with -mt2675.pib (in your case for MT2675) so the package can be properly built. These names are expected by the Makefile.

The generated fwconfig file should the look similar to this:
PLCFW_PATH=/lib/firmware/plc
PLCFW_NVM='dlan-pro-1200-ac/MAC-7500-v2.6.0-01-NW6__-X-CS.nvm'
PLCFW_PIB='dlan-pro-1200-ac/qca7500-pib15-devolo-mt2675.pib'
PLCFW_PIB_2675='dlan-pro-1200-ac/qca7500-pib15-devolo-mt2675.pib'
PLCFW_HOST=/usr/bin/plchost
PLCFW_SCHEMES=$PLCFW_PATH/dlan-pro-1200-ac

[SteveAyre]

Updated codeblock formatting to separate commands and output better - they weren't stray br-lan/Join arguments but it did appear that way on a single line.

Thanks for the clarification on the br-lan vs eth0 interface.

The MAC also appears to have been the issue as plc.init detects and updates the PIB with 30:D3:2D:xx:xx:xx but plctool reports a 10:0D:7F:xx:xx:xx address.

The commands you gave work so I will now look at how to get plc-pushbtn to use the correct one.

[OXINARF]

@SteveAyre Nice to see someone else attempting this. I now have PLC working with latest OpenWrt stable version (18.06.1). But I haven't found how to save the security-id when using the push button - after a reboot I have to join it to the network again. @dvlemplgk any tips?

@dvlemplgk As far as I can tell, the delos firmware is no longer in development. If that is correct, would @devolo consider open sourcing parts of it? I understand that some parts are proprietary and wouldn't/couldn't be open, but other parts would be nice to have (even if they don't work/build).

[dvlemplgk]

@OXINARF After successful pairing the key (NMK, which is not the security-id) is saved in the PIB file (/lib/firmware/user.pib resp. user.pib.tmp) by plchost. Those files should be persistent and be used after reboot. Only after firmware reset you would have to pair them again.
Please check with
modpib /lib/firmware/plc/user.pib.tmp -v
which NMK is set after pairing,

[OXINARF]

@dvlemplgk Thanks for clarifying! It didn't work (multiple times) before, but first time I connected it today, it indeed connected to the network without having to re-pair.

I still have to properly test Wifi, but I guess the only thing that is broken is the dLan led trigger, it gives an error request_irq failed with error -22. The led works by manually turning it on, but when setting the gpio (for gpio triggering) it gives that error and led stays off.

[dvlemplgk]

Then your Linux kernel gpio driver seems to not support interrupts for ath79 gpios. They were introduced in linux 4.6.
And there's a hardware bug which makes edge triggered interrupts unreliable, you have to add this patch to the kernel >=4.6:

`
-------------------------- drivers/gpio/gpio-ath79.c --------------------------
index c31f3be289f1..2c69bc7021aa 100644
@@ -131,12 +131,12 @@ static int ath79_gpio_irq_set_type(struct irq_data *data,unsigned int flow_type)
case IRQ_TYPE_EDGE_RISING:
polarity |= mask;
case IRQ_TYPE_EDGE_FALLING:

• case IRQ_TYPE_EDGE_BOTH:
  break;

  case IRQ_TYPE_LEVEL_HIGH:
  polarity |= mask;
  case IRQ_TYPE_LEVEL_LOW:

• case IRQ_TYPE_EDGE_BOTH: /* emulate it with level! gpio hw has trouble to recognize the right edges */
  type |= mask;
  break;

`

[OXINARF]

Thanks, I'll have to try that later. I'm using OpenWrt 18.06.1, which has kernel 4.9 so it should have support.

Is there any reason why that couldn't be a patch on OpenWrt (or even submitted to kernel)?




(correctly formatted diff below)

-------------------------- drivers/gpio/gpio-ath79.c --------------------------
index c31f3be289f1..2c69bc7021aa 100644
@@ -131,12 +131,12 @@ static int ath79_gpio_irq_set_type(struct irq_data *data,unsigned int flow_type)
 	case IRQ_TYPE_EDGE_RISING:
 		polarity |= mask;
 	case IRQ_TYPE_EDGE_FALLING:
-	case IRQ_TYPE_EDGE_BOTH:
 		break;
 
 	case IRQ_TYPE_LEVEL_HIGH:
 		polarity |= mask;
 	case IRQ_TYPE_LEVEL_LOW:
+	case IRQ_TYPE_EDGE_BOTH: /* emulate it with level! gpio hw has trouble to recognize the right edges */
 		type |= mask;
 		break;

[dvlemplgk]

Maybe noone is using led gpio interrupt trigger so it went unnoticed? We didn't upstream this patch yet.
Sorry for mangled format. How do you format code properly here (I used 'insert code' button)?

[OXINARF]

Best way is to paste it, then select it and click the insert code button. When it's multiple line you need to use three (or more) backticks and it correctly inserts it if you select multiple lines.

It usually detects the parser correctly but for the above it didn't, so here is what I did there:

```diff

diff patch here

` ``   (space there because I couldn't find how to escape it)

[OXINARF]

@dvlemplgk Any idea what can lead to the following error starting the PLC interface?

daemon.err setsid[1614]: eth0 00:B0:52:00:00:01 Write /lib/firmware/plc/dlan-pro-1200-ac/int6x00.nvm (1) (00000040:32064)
daemon.err setsid[1614]: eth0 00:B0:52:00:00:01 Start /lib/firmware/plc/dlan-pro-1200-ac/int6x00.nvm (1) (000000C0)
daemon.err setsid[1614]: eth0 00:B0:52:00:00:01 Write /lib/firmware/plc/user.pib (1) (00400000:22344)
daemon.err setsid[1614]: eth0 00:B0:52:00:00:01 Write /lib/firmware/plc/dlan-pro-1200-ac/int6x00.nvm (4) (00574464:495516)
daemon.err setsid[1614]: plchost: WriteExecuteFirmware2: Read timeout or network error~

I have a MT2913 working perfectly but now with two new MT2910 I always have this error.

EDIT: Nevermind, it was the firmware itself that wasn't working. For some reason, OpenWrt 18.06.2 works well, but 18.06.1 doesn't on MT2910.

[SteveAyre]

Note the trigger requires kmod-ledtrig-gpio (I didn't have it installed at first).

I'm also seeing 'request_irq failed with error -22' even after applying the patch above?

[SteveAyre]

firmware.QCA9882-v2.2.0_2018-07-26.dvl no longer seems to be available on http://devolo.de/

Is there a download for that firmware or a more recent version anywhere on the devolo website?

[SteveAyre]

I have found devolo-firmware-dlan1200-wifiac_5.2.1-2_i386.deb on http://update.devolo.com which contains delos_dlan-1200-ac_5.2.1_2019-02-19.bin.dvl which appears to have the required nvm and pib files. Is this the correct current version?

[Molkenbur]

Yes, you are right. This is the latest firmware for dLAN 1200+ WiFi ac. We deploy it via the Cockpit tool to our customers. Same is valid for dLAN 550 WiFi.