A mesh network (802.11s) IS a backhaul. If you have a Powerline backhaul, you do not need a mesh unless you want to extend your backhaul beyond the Powerline.
That is NOT what an 802.11s mesh does.
An 802.11s mesh knows nothing about access points.
Again, there is nothing a mesh backhaul can do about this.
As mentioned by @robho you need 802.11r to help with roaming, but be aware that not all devices will work with this (although newer ones are probably ok).
OLSR and batman-adv are specialised layer 3 ip routing protocols that sit on top of the layer 2 network provided by an 802.11s mesh.
These enhanced packages are targeted more for large infrastructure scenarios eg. city scale, rather than a typical home mesh application. In contrast, a basic 802.11s mesh serves all scenarios from home mesh through to high resilience neighbourhood WISP applications.
Unless you need some of the specialised functions, OLSR and Batman are somewhat of a complicated overkill in a typical domestic environment.
See:
An 802.11s mesh can be a very effective and resilient method of extending your backhaul to remote access points. It does not provide a WiFi network and does not provide access points. Non-mesh clients (like your phone) cannot connect to a mesh. Only mesh-nodes can connect.
(A mesh-node can of course also have an access point configured on it at the same time as its mesh configuration - but this has some potential downsides and at this point of the discussion will only add confusion - we can come back to this later if you wish).
You can get gigabit powerline 1000 adaptors, and 500Mb Powerline 500 is commonly available.
What you actually achieve depends on many factors such as the quality of the power cable connections, design of any RCD (Residual Current Detection) breakers, new style AFDD (Arc Fault Detection Device) breakers, physical range, and electrical interference (many coffee shop grade Espresso coffee machines seem to put out a broadband "white noise" that causes havoc, for example).
Yeah, after several years of use I'm really happy to finally retire my WPA8630Ps. I had a similar setup with WiFi on each end in 802.11r configuration and Powerline between the APs. It worked OK, but every now and then, depending on what the neighbors (!) did, the connection would drop.
I take it all back! I'm just busy eating my hat...
I just installed iperf and ran various tests around my network, & my AV1300 PowerLine speed is currently atrocious. I'm getting between 26 & 36 Mbits/sec & I don't know why yet. I think that what @bluewavenet said about RCD's and Electrical Interference is 100% spot on correct though, as I have recently had my fuse board replaced with new RCD's, & I have several potentially very noisy devices plugged in. I'll test more & tell you what's causing it as soon as I find out.
I'm also interested to find out what else you had to install into your TL-WPA8630P, or if you just used the basic OpwnWRT image for it?
I haven't installed any additional packages on my WPA8630P. What you want to do should be possible to do with what's installed by the OpenWrt image.
You may want to install scripts to handle the device buttons, but if you have your adapters paired before installing OpenWrt it's not necessary.
(Thanks for the bandwidth numbers, it's nice to hear what others get.. I did some benchmarking over a weekend some time back to try to see how performance varies over time. In my case I have stable connection and stable speed, but the speed stays at ~60 Mbit/s. So, no temporary noise sources for me, but just bad wiring for a powerline network. One other problem for me is that I don't use grounded sockets which prevents these powerline adapters to use the ground path for communication.)
Good test. The sensing coils in RCDs act as fairly good attenuators for the powerline carrier even with this test as the impedance for powerline signals is pretty low. I have tried this on RCD and non-RCD ring mains in the UK an found a consistent lower performance on RCD circuits. So it is not just "going through" an RCD, even just having one in the circuit somewhere has an effect. As for AFDD breakers, I am yet to find anyone with any, but expect to do so soon as it is I think, becoming mandatory to have them installed in business premises. They are not cheap, but a good safety addition....
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.)
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)?
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...
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.
