Deco P9 switch config

He is still figuring out the Powerline part. (You can of course always help and try to get it to work on your own. If so then you can base your own firmware on the latest M4R firmware I have linked below.)

If you don't need the Powerline feature then you can always just install the Deco M4R version. The flash layout for all M4R V1 and V2 and P9 V1 and V2 is the same and the hardware is the same apart from the Powerline chip so that is going to work. You just lose the Powerline capabilities with that firmware.

A "how to flash" can be found here: OpenWrt support for TP-Link Deco M4R - #51 by KinteLiX

The telnet enabled stock firmware for the P9 can be found here:

and the most recent M4R firmware can be found here: OpenWrt support for TP-Link Deco M4R - #57 by KinteLiX

1 Like

Well I could live without my Deco P9 supporting powerline, it would just make my setup slightly more involved.
At the moment I have 2/4 TL-PA8010's used to bridge the PPPoE connection from my router to my modem, so I "could" use powerline indirectly.

First, am I correct that VLANs are working?
Second, is there any configuration or something I should take a note of, (before flashing) that may be of use later?
Third, can you point to suggested sources regarding PLC? I won't have time to tinker with it till next week but, I would be interested to at least learn.

VLAN's are working,
Note the MAC addresses of the original config, only the base Mac from the flash is being read, TP Link increment that MAC during boot.
flashing using MTD is straight forward, follow @KinteLiX instructions to split the sys upgrade firmware.

The PLC is on a switch port and is up and running, but I have found no way to configure it, I've tried and open-plc-tools, but neither find it.

I disabled all wireless and could still reach the other deco at around 20mbps, the tpPLC utility says the connection was around 200mbps at the physical level, so that seems about right.

In the end I've not got the time to work through the issues I had though.

  1. WIFI throughput significantly lower than stock. Stock reaches 200mps on my MacBook, Openwrt default config barely reached 60mbps on 5ghz in exactly the same location.

  2. 802.11s mesh routing worked enabled ok at 5ghz ( apart from speed )

  3. Batman-add routing worked, and I was able to bond 2.4 and 5 wifi radios into a bat0 interface, however no increase in speed was found. I am not expert enough to workout why

  4. batctl tp bat0 to the remote showed good throughput in theory but it did not translate to the client, I must be missing something in the config.

  5. I had lots of Mac collision warnings in the log messages, and also lots of MTU size warnings for Batman packets being fragmented, could be the cause of the speed issues.

  6. I could not see the remote devices using batman-adv over Powerline. Could not debug.

  7. add the other ports to the config file 02_network incrementally, I simply added all of them and saw that the plc port is always up at 1000mbps duplex, you can find the m4r config and add them all sequentially. Ports 2, 3, and 5 are in use in the stock firmware. in the M4R config They are currently set as

                ucidef_add_switch "switch0" \
                        "0@eth0" "3:lan:1" "5:lan:2"

I changed this to which showed two additional connected ports, one is the PLC and the other is a half duplex port with VID 591

                ucidef_add_switch "switch0" \
                        "0@eth0" "3:lan:1" "5:lan:2" "1:lan:3" "2:lan:4" "4:lan:5" "5:lan:6" 

In short, I'd love to run this instead of TP-Link's firmware, but I'm not able to get the performance level where it needs to be to replace the OEM firmware.

The main problem here is always going to be the wireless driver. TP-Link is of course definitely using a closed source driver directly from the manufacturer of the chips they're using while we have to rely on ath10k-firmware-qca9888-ct for the 5GHz radio and whatever ath9k driver the device is using for the 2.4GHz radio.

You might want to try the non-ct version and see if that gives better performance.

I also don't know how TP-Link is doing the wifi backhaul between the individual devices but in OpenWrt the driver has to constantly switch between Access Point mode and Mesh Network mode so the usual route for that is to use one radio for the backhaul and one for the Access Point, but not both on the same radio to prevent the constant switching. If you still do it then you will have bad performance (because of the constant switching).

But in the end this isn't a Deco-specific problem but one that all devices running OpenWrt with that radio driver face.

Note the MAC addresses of the original config, only the base Mac from the flash is being read, TP Link increment that MAC during boot.

I'm unsure what you mean. eth0 and the 2.4GHz radio's first SSID are going to use the label MAC on the label on the bottom of the device. Additional SSIDs will count up the first byte of the MAC and the first 5GHz SSID will count the last byte done by one.
In the end this isn't THAT important because iPhones for instance generate a random MAC (periodically) anyway. But it's a good thing to do to prevent collisions between different Decos with the same firmware.

WIFI throughput significantly lower than stock.

I just did a speedtest on with my 4 years old 250€ phone and got 245Mbps down and 163Mbps up on the 5GHz radio. The uplink of that Deco M4R is of course a wired gigabit connection. So I can only guess that the 60Mbps are a result of you using batman meshing?

TP-Link is using Qualcomm's hyfi sdk for it from what I can see, it has created hidden SSID's for the backhaul that are statically configured and pass info through some hyfi proprietary solution.

I had this setup without using the CT driver and firmware due to warnings about it not liking 802.11s, so the performance numbers I saw reflect that, others may wish to try the latest CT driver and check.

The MAC address issues, yes the 2.4 and ETH0 use the label MAC's but the firmware after boot gave everything else the same MAC address as those. The problem with the MAC was only what I saw with Batman warnings. TP-Link's default firmware created a huge! number of virtual ports each of which was some increment on the labelled Mac address.

Hard to say if the performance was or was not the mesh, I had one node hard wired to the modem, and even on that I maxed out at 100mbps, couldn't get near to the WAN link speed of 350. I suspect just poor configuration on my side, but as said don't have enough time to spend debugging.

I'm guessing you mean the interfaces under Network->Interfaces? Since there is only eth0, every interface there is of course going to be derived from that and will thus have the same MAC. But that too is a OpenWrt "problem" and not specific to your device.

If that doesn't work for you then you can of course always override the MAC address per interface. In the end the only devices seeing those MACs are within your private network so you just have to make sure that you don't give every device the same MACs and you should be fine even when using something like 12:34:56:78:90:12.

yes, the devices listed in the interfaces page, and what I manually did was give every conflicting device a unique MAC and changed MTU, but since I have, and most others who bought the P9 will, have a 3 pack of Deco's, some boot scripts need to be written to set MAC address and MTU on everything correctly, based on the stored Mac in the non volatile partition

Maybe flow offloading isn't on, without enabling that my speed maxes out at around 180mbps, with it on matching my internet speed.

Didn't even think about using any of the Decos as actual routers. My bad.

My devices are all setup as dumb APs with wireless and wired connections bridged. I mainly use them for multiple SSIDs that lead to multiple VLANs. I don't even have a WAN interface anymore and am not using the firewall.

So yes, definitely activate Software flow offloading in Network->Firewall if you don't need SQM. That should give you speeds comparable to simply bridging the networks.

No clue if Hardware flow offloading works though. This suggests it doesn't: Hardware flow offloading/Hardware NAT? - #6 by slh

I was replying to dietcoke73, he said he hard wired a node to the modem so I was assuming he was using it as a router.

In the process of creating a clean PR for the changes here,

At the moment I'm not convinced of the changes to the tplink-safeupdater file, how do I check for the board config's?

1 Like

Do you mean the tp-link-safeloader.c?

Open the most recent stock firmware for your device with a text editor. That's where those special ids, the version and the partitions come from. Some are right at the beginning of the first partition and some you have to search for.

Also since the P9 is a copy of the M4R with an addon, I would suggest creating a .dtsi with the common infos and then include that in the .dts of the P9 and the .dts of the M4R.

Because if you're going to create a PR then you might as well add the M4R too while you're at it anyway. :slight_smile:

The OpenWrt device page for both should be the same too. No sense in creating two separate pages.

Hi All,

I've pushed the config for PLC as an update to the GitHub project above. At this moment I am likely to abandon this work, and leave it up on GitHub for others to continue. It seems that without hardware NAT support and DSA being enabled I cannot get the required performance for my WAN speed.

Using ethernet, the board is maxed out at 281mbps with CPU saturation due to high IRQ load. And with WIFI although the Atheros reached 866mbps at the physical layer, the throughput from WIFI to LAN using IPERF3 maxed at 70mbps between a wired laptop, and a wireless laptop client.

I don't think the SoC is powerful enough without the full HW acceleration turned on. If I get some spare time, I'll take a look at DSA and enabling it, which seems on other boards to provide about 50% improvement. Unless I can get this to run 350mbps like the stock, then its a non starter for me.



Have pushed a port of the QCA FastPath solution onto GitHub. credit to @quarky for a clean port to 5.4

The modules are loading, but not seeing any great change in throughput. Also think there is a bug somewhere, as the routers where crashing with it.

There performance, may be a config error. I did see entries in the debug sysfs, but most of them suggested not working.

Ok, so some debugging tonight

Without Software offload in the NAT settings on the firewall, throughput of wifi to wan is capped at 100mbps

enable kernel software offload, and saw wifi to wan throughput of 180 to 200mbps on Ath10k 5G

Disabled software offload in the Firewall tab, and use QCA fast path, now see 260mbps on Ath10k

So performance of wifi to wan is much improved.

Yeah, that's my experience as well. I found that QCA FastPath is more performant compared to the stock Linux software flow-offload.

I'm also using FastPath on my Linksys E8450, of course with my custom build.

For ath10k, there's a patch that also perform tx encap offload to the firmware, tho. I'm using it for my R7800 QCA9984 chipset. This should further improve your WiFi client download performance and reduce CPU load a little on the AP side. Not sure if it is the same for all ath10k chipset tho.

Have tried to move the P9 to the latest snapshot OpenWrt/master branch today. Seems the kernel is now 1.9MB and no longer fits the TP-link partitions. Without serial console access I cannot progress this, and I don't have the soldering skills/hardware to make it happen.

Anybody got any suggestions about how to shrink the 5.10 kernel down?

I'm guessing you got openwrt on the device by first flashing the beta firmware with activated telnet and then using the mtd command to flash your openwrt firmware that you had split with dd?

Because that should still work.

There are no physical partitions and they're defined by the .dts file. So just create a new firmware where the kernel partition is bigger. Or if you're already using a "firmware" partition instead of "kernel" and "rootfs" then that's already good to go and you shouldn't have to change anything.

Doesn't matter that you're not splitting where the partitions in the file switch from one to the other.

@bobthebuilder - thanks for the tip, in the end I decided that without serial access I could not risk bricking them, and flogged them on ebay. I'm Fortunate in my house that he walls are stud and plaster, which means the extra PLC of the deco isn't needed, and a pair of RT3200's with a hardwire MOCA 2.5 coax between them gives me gigabit ready speeds all through the house.

Cannot praise the RT3200 enough, rock solid in my config, and got tons of CPU to host things too.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.