Great to see that this device is now supported!
I'm considering to flash my four pieces too. I'm very disappointed by the original firmware.
I have little experience with OpenWRT. I used it on a router before and it worked so far. I had to stop using it because the storage capacity was very limited.
Anyway, my question is, how easy and reliable is it to setup a wifi mesh using OpenWRT? I have ethernet in most rooms and want to have a wired connection between all D-Link nodes.
If all units have wired back haul, you're not setting up mesh....
Ok, maybe I'm lacking some knowledge here. What I want is one network with one SSID across my house where all mobile clients are continiously connected and seamlessly change to the next best access point. I thought this is what a Wifi Mesh is for. And isn't wired always better?
You want wireless roaming, setting one common SSID should be enough.
Yes, wired is usually better.
Thanks!
So just to be clear. Wired APs with same SSID will work better than wired "Mesh"-System like the COVR? My understand was that the handover of mesh systems works way more seamless. I'm confused. Why are mesh systems so popular then? Just for people who can't wire them up?
Mesh is for wireless inter connection, and the term itself is misleading.
As for the hw, it's usually cheap.
Ok, I guess I will try out the non mesh way. How to properly connect the COVR-X1860 devices? In front of my switch I have a router so the COVR is only for Wifi. Does the first device need two wires or is one enough? My understanding with mesh and the original firmware was to connect one wire to the router and one to the next COVR device.
probably doesn't matter if you daisy chain them, or connect them as a star, from the switch.
By default, the yellow internet
port is configured to be wan
, just like with stock firmware (usually WAN ports used to be blue, but they probably wanted to make it easier for the users, since they are supposed to connect that port to the yellow LAN port of their main router with the yellow cable that's shipped in the box, so... ), only the grey port ethernet
is LAN.
But if you set both interfaces to be bridged to br-lan
, technically the switch should still forward packets between ports directly in hardware without loss of performance (I hope this is still true with devices using DSA, haven't actually tried this myself yet).
Regarding mesh
, this is quite a complex topic, though after all it's still mostly a marketing term.
Trying to put it short here: Band steering was done in the past, by deliberately blocking connection attempts from devices, hoping they would eventually find the desired AP to connect to (i.e. as desired by the central controller). Nowadays, there are standards like 802.11k and 802.11v for this, which help guiding devices to choose the best AP (not just based on RSSI, but also actual channel occupation etc.). But even for this to work, there needs to be some sort of communication between the APs (to collect all that information from all the APs and provide it to the clients via all APs). This part was unfortunately not covered by the specs, so every vendor came up with their own stuff, making wifi "meshing" sets incompatible between vendors. So the WiFi Alliance stepped in and created "WiFi certified EasyMesh", also known as "Multi-AP specification", I think this is also what COVR-X1860 supported with OEM firmware.
For OpenWrt, the only actual "(de)centralized mesh control" implementation I know of would be DAWN, there is a wiki article on that, but I believe few people have ever actually configured this (me neither, so we're happy to hear about results I guess )
Thanks for all the information and help. I feel like I learned a lot. But I'm still not sure I have a clear answer to my question:
I have multiple COVR-X1860 devices (currently stock firmware) and other wifi routers. I have a house with multiple stories which I would like to have covered by a single wifi. To me not only the performance in terms of speed is important but also a seamsless hand over to the next AP if I'm moving through the building while being on a wifi call or having a video stream open.
Like I said, my understanding was that for this I need a "mesh". Now I know better what mesh is but can someone tell me if having 3 APs with the same SSID being connect by wire is enough for what I want or is some other technology or setup needed?
Unlike cellular networks, the roaming decisions in wifi are made by the client only, so the short answer would be "it really depends on your clients".
Current wifi stacks of popular Operating Systems should be capable of roaming seamlessly by default (though personally I use neither Android or iOS; Windows only rarely on machines connected via Ethernet and with Linux devices I rarely have roaming situations, so I'm not at all an expert on the practical side of this )
After all, it really should be enough to just configure all devices as dumb APs and have them use the same SSID. You can also enable 802.11r "fast transitioning" (which basically just transmits a hash of the wifi password within beacon frames, as an indication to the clients that these APs actually share the same credentials, so there would be no delay caused by failed connection attempts), so this does not require any further communication between the APs.
Although it was the main purpose of the ESSID ("network name") already to indicate which BSSIDs (AP MAC addresses) belong to the same underlying network.
Some more history: Initially, such things as "repeaters" were never considered in the wifi specs, but when vendors came up with these, they could not just have them broadcast the same ESSID as the one they are connecting to: When using more than one repeater configured that way, they might just as well accidentally create a loop among themselves, with no further connection to the uplink. So vendors used a different ESSID like "_ext" or "_RE" or something appended. This caused clients to stick to that network even if the signal quality becomes very low - but that's the desired behaviour. The device is supposed to consider a different ESSID to be a different network (i.e. you would expect a different IP address), so you do not just switch unless absolutely necessary, since it would break all current connections. So, using different ESSIDs on APs connected to the same network is discouraged.
Now with the recent "mesh" systems, vendors implemented their own topology detection and routing stuff, with wireless backhaul using a second radio on a different channel etc., they could finally get rid of these issues and actually provide a "Single SSID" Solution again.
Which is now being advertised like a new feature, although it is just the way WiFi was designed to be used from the beginning, and that way there should be no more issues with roaming anymore.
Thank you. I guess I will flash my devices to OpenWRT then and try the "dump" AP single SSID way.
While I certainly don't want to discourage the use of OpenWrt, keep in mind that OpenWrt is not required to do a dumb AP configuration. You just need the ability to:
- Set the IP address of the AP
- Disable DHCP server
- Configure wifi (SSID + encryption + passphrase)
- Ideally also configure power levels and channels for the wifi radios.
If your devices are supported by OpenWrt, you will certainly have all of the necessary configuration options available to you when running OpenWrt. But if your devices are not supported, that doesn't need to be a blocker for your to achieve the dumb AP goal.
Yea I understand that. In this case we are talking about the D-Link Covr devices and I'm not sure if they are made for being standalone APs rather than master-satelite.