TP-Link WPA8631P multi unit Mesh with AV1300 backhaul

I have RCDs on every circuit in the house, so this would explain why my PowerLine networking is sooo sloooow. No AFDD Breakers though.

It is circumstantial evidence, not a definite and it might depend on the manufacturer of the rcd as well as other factors.
Premises with zones on a single rcd (eg upstairs on one rcd and downstairs on a second) seem to be better than installations with an rcd on every circuit.

On the other hand, a lot of rural areas in the UK consider themselves lucky to have 30Mb/s vdsl, so 50Mb/s on a powerline is just fine. For now anyway. (I know this as that is what I have to put up with..... Starlink looks very attractive.....)

an unfortunately very valid point. My current ADSL connection gives us 24Mbps, which is why I hadn't noticed the PowerLine issues before. Lots of stuff to fix, troubleshoot and/or upgrade.

I am trying the same, I have two WPA8631P devices (not the kit). Batman over the wifi and over the plc0 device gives these warnings in the log:

Sun Oct 30 11:23:54 2022 kern.warn kernel: [ 2785.885179] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:05 2022 kern.warn kernel: [ 2796.125369] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:15 2022 kern.warn kernel: [ 2806.365039] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:25 2022 kern.warn kernel: [ 2816.605241] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:35 2022 kern.warn kernel: [ 2826.844957] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:46 2022 kern.warn kernel: [ 2837.085172] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:24:56 2022 kern.warn kernel: [ 2847.324923] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)
Sun Oct 30 11:25:06 2022 kern.warn kernel: [ 2857.565100] br-lan: received packet on bat0 with own address as source address (addr:10:27:f5:31:c4:45, vlan:0)

Going back to an 802.11s mesh, on 2.4GHz HT40 will connect at 300Mb/s between meshnodes, and achieving 180-200Mb/s or better is common under load, depending of course on signal to noise ratio. (HT40 is fine if you do not have any close neighbours.)

@bluewavenet this sounds promising...

Assuming that OpenWRT can stabilise the WiFi on my three TP-Link WPA8631P units, an 802.11s mesh should automatically find the most efficient route to transfer data in between the meshnodes and to/from the wired LAN & WAN. This could/should then use HT40 between meshnodes in preference to the AV1300 PowerLine 'wired' option, because it is 5 to 10 times quicker (I assume)?

From the look of I'll have to have a good play around with the HT40 mode settings & see which one works nicely with my house & my various clients.

I presume that I can still use 802.11r Fast Transition by just ticking the checkbox in the wireless config on all three units?

I'm going to have to test everything again... According to the web interface on my WPA8632P units, I am getting awesome speeds, whilst my iperf speeds are terrible. This needs more investigation I think...


These will be the connection bit rates, not the mean achieved bandwidth.

It it unstable?

Yes, the 802.11s mesh does this, by dynamically constructing a layer 2, mac-routed network.

This is a function if the layer 3 ip network and has nothing to do with the mesh.

Unfortunately no as it will all look like a big bridge with multiple paths so you will need to enable stp, but even then there is no guarantee you will be using the fastest path.

HT mode settings are trivial and only determine the actual frequency spread used.
HT40 actually uses two HT20 channels allowing double the bandwidth. This will be excellent between meshnodes.
However if you use the same physical radio for both mesh and ap, the ap will also be HT40, and many devices do not support it and will fall back to HT20. This is fine and compatible with the mesh, but although the meshnodes will be capable of communicating at say 300Mb/s, devices may end up only communicating with the ap at 150Mb/s.

It is better to use say 2.4GHz HT40 for the mesh, and use 5GHz for the APs.

For the Powerline devices, it would be necessary to disable the Powerline interface if you were using the device as a meshnode.

802.11r requires APs to use different channels than their neighbours, compared with 802.11s that requires all meshnodes to be on the same channel.

So using 2.4GHz for 802.11s and 5GHz for APs will allow you to use 802.11r.

Yes, but I think that it might be a routing issue rather than a wifi issue - & specifically derived from the Archer VR600 stock TP-Link Firmware.

I had problems reaching the internal servers on my wired LAN via wifi, & TP-Link actually created some custom firmware for my TP-link Archer VR600 ADSL Router specifically to fix that issue for me (on my wired Gigabit LAN I could ping anything happily, but through the wifi I could only ping IP Addresses out on the internet). This patch later got rolled into one of their production firmware upgrades. Since then, it's been much better, but still sporadically flakey. That is what originally led me to look into OpenWRT as a way of fixing my problems.

OK. News update... I have just finished flashing OpenWRT on all three of my TL-WPA8631P units, I have disabled the WiFi on my main ADSL gateway router (the TP-Link Archer VR600), and the OpenWRT powered TL-WPA8631P units are now providing all the WiFi coverage for the whole house.

It would appear that I have gone full circle...

To return to your original point, with everything that I have learned in the past 12 days, unfortunately Yes - I believe that you were entirely correct. I was confusing "Mesh" with "Roaming"...! In my defence, my info at that time had come entirely from the marketing used to sell me my kit.

My use case scenario was that my family & I needed to be able to move around the house without the WiFi signal disconnecting from one AP, jumping onto 4G, then reconnecting to a different WiFi AP. What I needed was a solution - what I got was something sold as a Mesh that alleged it would do what I needed, but didn't.

I now have three Dumb APs with 802.11r enabled. This works beautifully, we can roam around the house at will & the family has stopped complaining about the WiFi. I didn't bother with 802.11s & everythign else is pretty much on its default settings.


@jonnyheggheim Apologies for the delay in the response to your post. Just re-reading the whole thread again & suddenly struck by the question of why are you using batman? Surely it is much more than you need & just massively complicates things. I accomplished exactly what I needed with a Dumb AP setup with the 802.11r checkbox ticked. The only difference between my configs is the WiFi channels, so they don't overlap. On mine, the IP Routing just looks after itself on its defaults, so why batman?

I looked at batman and OLSR as I was trying to work out what to do, but decided that they were probably overkill.

I am testing out how I can expand my local neighborhood network. We are currently 11 apartments sharing my fiber. At the moment I only have two WPA8631P in a small test network with other different models. Once I get a hang of it, then I would likely buy more devices and deploy them.

Advantages of batman is the support for VLAN, today each apartment is on a different VLAN, most of the AP today is wired+nanostation pairs between houses, but I assume the expanded network will mostly have wireless (or powerline) uplinks.

Are you sure that SpanningTree is needed in addition to 802.11s? I always thought 802.11s would create a l2-bridged Network, find the fastest paths and avoid loops.
Reading your post, it looks like it creates the l2-bridge only.

Too bad that openwrt supports stp and lacks the faster rstp as well as pvst (per vlan SpanningTree).

Only if you have cabled connections present between mesh nodes.

It does, but non-mesh links need stp to stop multi-path propagation of packets.

1 Like

It looks like batman have loop avoidance that spans over to cables too:

1 Like

Here are some explanations (but interference, breakers etc could also be lowering rates):

Let’s assume the Powerline speed between the TL-WPA8630 and TL-PA8010 is 1000Mbps in an ideal environment with few interferes, normally it will make an actual throughput of 300Mbps-350Mbps. This rule basically applies to all Home Plug AV products.

MoCA 2.5 Ethernet adapters are an alternative if you have Cable that you are permitted to use.

1 Like

OK. Once again, apologies for the delay in continuing this thread, but I have had to do loads of research & reading to get myself up to speed on quite a few other areas of the OpenWRT ecosystem before I could actually find out more about 802.11s mesh networks. Firstly, I had to find out about Attended Sysupgrade as there isn’t enough free space on the TP-Link WPA8631P to install what we need for 802.11s networks.

The stock 22.03 image for the TP-Link WPA8631P contains wpad-basic-wolfssl, along with dnsmasq, odhcpd & ppp. wpad-basic-wolfssl only has 802.11r and 802.11w support – but we need 802.11s for a mesh. However, there isn’t enough space to install the packages that we need on the stock image. To resolve this issue, we need to use an Attended Sysupgrade to create & install a custom firmware image.

I have also discovered that you don’t actually need any of the additional PowerLine OpenWRT packages installed. When you first flash OpenWRT on the TP-Link WPA8631P, it will remove the device from your existing PowerLine network. All you need is your standard TP-Link PowerLine utility software running on a Windows PC and the PowerLine keys (printed on the back of the TP-Link WPA8631P unit) to add it back into the PowerLine network. That’s the last time you need to do anything to the PowerLine network, so having the packages installed under OpenWRT is just unnecessarily taking up space – which we don’t have lots of.

WARNING: Don't get creative or over-enthusiastic when selecting packages to remove. Keep it Simple. What I have done below works first time and gives enough space to do what we need, so I wouldn't advise removing anything else.

I installed luci-app-attendedsysupgrade from System → Software

This gave me a new menu item under System: Attended Sysupgrade

System -> Attended Sysupgrade -> Configuration TAB
Client -> TICK Search on opening (makes life easier)
TICK Advanced Mode (doesn’t do what we need it to without this)
SAVE & Apply

Attended Sysupgrade -> Overview TAB

Click Search for ‘Firmware Upgrade’ which gives you the list of packages to customise for your image.
Some packages may not be in the list already, if you have disabled them in Luci

I removed these packages:

-odhcpd -odhcp6c -odhcpd-ipv6only 
-ppp -ppp-mod-pppoe -kmod-ppp -kmod-pppoe -kmod-pppox -luci-proto-ppp

Then I added these packages:


Click on Download firmware image, Keep settings and retain the current configuration

From your PC, set a ping to it's LAN IP Address in a terminal. Watch it as the upgrade is running, & after a short while you will see it suddenly start to time out. 30 seconds or so after this, your ping will start working again. At this point, open a new browser web tab and navigate back to the IP Address of your AP.

NOTE: The browser tab that you started the Attended Sysupgrade from will still be open & will be warning you not to reboot your device. Once you have logged in again a separate tab, you can safely close this one. It appears to be a bug in the interface – see this forum post about it.

Now, finally, I have everything needed to properly reassess my original question.

Current state of play:

Flashing all of my TP-Link networking kit with OpenWRT completely fixed my stability problems.

Ticking the 802.11r box on each AP sorts out all of my roaming problems. A beautiful & simple fix.

My PowerLine network is slow because of the way my house wiring works. The three AP's that form my WiFi network are using it as a backhaul, so I now want to add an 802.11s mesh backhaul to connect my AP's instead.

I have 3 TP-Link WPA8631P units running as dumb AP’s. Each has been flashed with custom OpenWRT firmware that includes wpad-wolfssl & mesh11sd

I have replaced my Internet ADSL Gateway router with a TP-Link TD-W8970 and flashed that with custom OpenWRT firmware that includes wpad-wolfssl & mesh11sd too. Currently it has its WiFi radio disabled. It only has a 2.4GHz radio, so no 5GHz.

My 3 AP’s run 2.4Ghz WiFi on channels 1, 5 and 9 (SSID: Home)

and 5GHz wife on Channel 40 (SSID: Home)

Each time I tried to set the 5Ghz to a 'free' higher channel, it wouldn't connect. Am I right in thinking that I should have just been more patient, & left it for 10 minutes to run its Emergency Service interference checks to make sure that the channel was actually available? It currently works like this, so I haven't looked at this issue in depth yet.

I now need your advice on Frequency & Channel selection for my AP's and Mesh. As all of my AP's & my Gateway router can 'see' each other at 2.4GHz, but at 5Ghz the ones at each end of the house can only see the one in the middle & my gateway doesn't even have a 5GHz radio, the advice from @bluewavenet to set up a 2.4Ghz 802.11s Mesh seems spot on.

Should I pick Channel 13 for my 2.4GHz Mesh and leave my existing 2.4Ghz AP's exactly as they are, running on Channels 1, 5 & 9...? Then wait until my family are out of the house & reset my 5GHz AP Channels to some of the unused higher frequencies - & give them time to check for interference?

Do I need to run my AP's to different channels to my Mesh, or have I got that bit all wrong?

Well before going into any detail, we should have a quick recap:

  1. You want seamless roaming for your smart devices within the house
  2. You want to replace the "Powerline" backhaul with an 802.11s mesh backhaul
  3. You fully understand that WiFi roaming, marketed as "Mesh", is not mesh at all.

There are numerous "conflicts of interest" here between 802.11r and 802.11s.

  1. 802.11r requires all AP radios to be on different channels (as far as can be seen from each AP radio).
  2. 802.11s requires all Meshnode radios to be on the same wireless channel.
  3. As most hardware available supports only one channel per radio, if you want both Mesh and AP on a device (on the same frequency range eg ~2.4GHz) then the available bandwidth is shared between AP and Mesh (resulting in a potential doubling of latency).

You could decide to use the 2.4GHz band for mesh and the 5GHz band for APs. This will be the best as all the 5GHz radios can be on the same channel without co-interference issues.
The problem here is your "gateway" does not have a 5GHz radio.....

If you chose to use the 5GHz band for mesh, then you can keep the current 802.11r roaming config, but, to quote the previous paragraph "The problem here is your "gateway" does not have a 5GHz radio....."

I guess you could buy another Tplink or similar device..... but disregarding this issue for the moment, as you are in a rural area you can almost certainly use 40MHz channel width on 2.4GHz. This allows a 300Mb/s connection speed between meshnodes and typically ~200ish Mb/s transfer rates between meshnodes.

In the UK and Europe, it is pretty common to only have channel 36 as a guaranteed available channel on the 5GHz band. Other channels might or might not eventually connect, and yes it can take 10 minutes or even more at times. Even then, some brief interference could cause the radio to drop the channel and start its scanning again. All this effectively renders other channels as unusable.

There are of course numerous other combinations of "stuff" you could try....

1 Like

Yes, Yes, & Yes...

OK, I think that I understand the situation better now. I will have a good think about my next move & what my options are, given the conflicts of interest in what I need. As always, thanks for your advice...