wifi (sta) - wifi (AP) in a repeater mode, and wifi (sta) - ethernet in a 'downlink' mode on the same subnet is not directly supported by the 802.11 standard.
You can easily do these things in a normal routed mode (where the AP/ethernet is on a different subnet than the sta mode uplink).
But for a true 'repeater' mode, you must use something like relayd. But, these are hacks on top of the 802.11 standard that have some quirks and don't universally work (they don't support IPv6, for example).
The vendor firmware for repeaters often use some proprietary 'magic' (often using relayd under the hood and/or non-open-source code from the wifi chipset vendors) to make it transparent... but even those don't always work properly. Others may do some encapsulation between the nodes to make it work (for example, Unifi APs can do a wireless backhaul that includes all associated VLANs and can operate as an ethernet downlink, too; but these are using a proprietary method to achieve this). In general, you need to have consistency in the chipsets and/or firmware in order to do this stuff -- you may notice that many wifi repeaters are only technically compatible within a given brand/product line and may not work with other vendor's equipment).
I accept your post, with one reservation: I am a retired sys and network admin and I cannot confirm "but even those don't always work properlyt". From a silly old Fritz Repeater to a recent acquisition for 8 USD including shipping from China (only bought as client WiFi-2-RJ45), they all worked here as what I needed at times: extending the range of an IPv4 AP. This same EAP600 has been totally okay with a different AP for the last 5 years.
I do know how things are; I don't like that 'repeater' concept myself. But here I am bound to just having a power plug, and need to extend the range. The vendor firmware did just fine. WDS also has its quirks. So I was actually most happy to find OpenWRT to support this AP; and me to replace a six year old dubious firmware based on a 3-something kernel with the greatest and the latest.
The point here was that some of these devices are flaky. Even OpenWrt with relayd has known issues, including the inability to pass DHCP packets properly in some situations.
Many may work well, of course, but they often have some proprietary methods happening under the hood.
Sure... I can understand that. But your disappointment should be directed at the original 802.11 spec -- this was not a use case that was envisioned (or prioritized) at the time that it was ratified.
Good. So let's open a new path. Should I open a new topic, or can we continue here? I'll try.
So what is the suggestion of the community for the situation that I find myself in?
I need to extend a wireless network, so that users can roam from one AP to another, without being cut off, without reconnecting, same SSID, same IP, dished out from a DHCPd in front of said first AP for which the range must be extended. That first AP neither runs OpenWRT nor can it be converted to it.
and replace it with OpenWrt supported hardware, or if it is an ISP modem/AP that cannot be replaced, put it in bridge mode and treat it like a modem only device with a new OpenWrt supported hardware device for the AP, if you can.
I've found used and open box OpenWrt supported hardware on ebay to be very economical over the years.
Typical protocols for roaming are 802.11k, 802.11r, 802.11v.
I personally have never tried them though. You will likely still need to compromise. In particular: How are you going to activate and configure your first ap to use these protocols, if your first ap is not configurable? Even if you manage to set them up, for the reasons mentioned by others in this thread, they might not fulfill all your requirements. There are complex technical reasons for the way things are (right now?). E.g. just look at Mode WIFI STA bridge with LAN does not work - #11 by mk24. It's complicated.
About a year ago I replaced my last repeater with a pair of Powerline Adapters and get a reliable 200 Mbps. YMMV depending on where in the circuit these reside.
This is standard roaming behavior (and does not require 802.11 k/r/v -- those are additions to the 802.11 standars that aim to improve roaming performance, but they aren't necessary, nor are they a slam dunk).
The only thing that complicates your situation is the need to do this wirelessly. Wireless backhaul is not always easy for a variety of reasons, some of which have already been discussed. If you can run a wire (or per the suggestion from @RangerZ -- maybe powerline adapters could work for you), you would find this whole process almost trivially easy.
The following is out of scope for detailed discussion on this (OpenWrt) forum, but in general...
You can try to get an 'extender' from the same manufacturer who makes your first AP... implementations like WDS tend to only work properly/well with the same vendor providing both sides.
Or buy a commercially available 'repeater' device and see if it works (like I said, some actually do work well, some don't, and some require that they work with the same brand in order to function).
And there is always the option of replacing your first AP with one running OpenWrt.
As far as I know, all of this (except the "without reconnecting" clause) is achieved by the "relayd" configuration. A STA can be connected to only one AP at the same time, so the clients must disconnect from one AP and then connect to another one; this can be made seamlessly, but it has to be done.
Building on what @eduperez said about the disconnect/reconnect requirement, I want to point out that I glossed over this... This disconnect-reconnect cycle will necessarily happen, but at a human scale it should be (nearly) seamless if everything is tuned well, and it should certainly be automatic. Roaming is a client side process, so the APs have limited-to-no direct control over this, but there are things that can be done to improve the performance and to encourage clients to make good roaming decisions.
802.11k/v/r are intended to improve roaming by sharing information across the APs and client devices so that the re-connect phase is faster and requires fewer steps. However, these standards can be hit-or-miss, and it is sometimes worse than plain old roaming due to client device issues. As such, it is recommended to work first on creating a good traditional roaming environment and then implement these standards (if applicable to your situation) only after things are generally smooth.
Now this sounds more reasonable. 'Seamlessly' doesn't mean 'without reconnecting', naturally! So, like @psherman correctly writes, not doing any real-time stuff like audio or video conferencing while moving about, my users usually don't notice.
Just for the fun of it, I tried @RangerZ , but the wireless way: pulled a crappy TL-802N from the box, piggybacked it to the EAP600, extra USB power supply, short RJ45-cable from the TL to the EAP. Of course this works, kind of sh**y, but does.
Why can't OpenWRT do the same with a built-in radio and a single, simple software switch? Isn't a TL-802N just a normal 802.11 client and the EAP a normal AP; just in series?
Please, correct me if I'm wrong.
The 802N that you're using (assuming it is running the vendor firmware) is almost certainly running relayd and/or other possibly propriatary methods of achieving a similar goal. The point here is that the 802.11 standard does not support a direct bridge approach with wifi-sta > wifi-ap modes.
OpenWrt can achieve it using relayd, but this method isn't perfect and is kind of annoying to setup. Could it be better? Maybe, but it would require a lot of development work, especially given all the various target architectures it would have to accomodate.
Remember -- in the case of a commercially available device intended to be used as an extender/repeater, they have a single known architecture target, and therefore can put a lot of time and energy into getting it to work reasonably well; this is much much more challenging if you have to design a package (or set of packages) and/or method(s) for a huge variety of chipsets that each have their own quirks, as is the case with OpenWrt.
So I am very confused why so many people are saying you can't do this or need relayd, I've been doing a version of this for years with different routers all running OpenWRT, but you'd need to install OpenWRT on your EAP6000 and it looks like it's supported.
Option 1: Basic Repeater
I'm basically going to just call out how to setup a dumb AP so search for those guides as they will probably help.
On your EAP6000 login in to OpenWRT and navigate to Network -> Wireless and on radio of choice SCAN for the AP you want to connect the EAP to.
Once connected you will need to create a matching SSID
Follow Dumb AP instructions to set your LAN IP address in range of the network, set gateway to point to main AP or Server (which ever is doing DCHP), turn off DHCP and Firewall and then save and commit everything.
Option 2: Setup as Mesh
Confirm that your devices will support (i forget how to check but you can google it) the WPAD-Mesh software on Openwrt. I just use the full "wpad-wolfssl" but wpad-mesh-wolfssl will also work. The EAP is ath79 so I think it will work.
In Network -> WiFi you will need to add a Mesh interface (Mode = 802.11s) on both AP's and everything will need to match.
I did. Since I'm a newbie on OpenWRT, I didn't find any settings for what I want.
Yep. Read further up, please, that's (Option 1) exactly what I had tried to configure umpteen times. Alas, to no avail.
I concede, that I didn't actually grasp OpenWRT; these interfaces, some LAN, some br, that you can delete, all sorts of things. No, despite of my best undertakings I didn't grasp the architecture.
The documentation is exhaustive, though for me not too well structured. So I didn't find a most simple client configuration; like if I wanted to just plug a printer into the Ethernet port. There was no simple 'client' option. I also missed the settings for nameservers on that same page; like what you usually see.
Whatever, whenever I had some client working (time was adjusted), and I added an AP, all client functionality was gone.
I'd be grateful - only if you have the time - to specify step-by-step? As an old networker, I do understand the relevant parts of it; only the UI seems to be in my way.
This is because of the limitations of the 802.11 standard... a wifi > wired (or wifi > wifi repeater) requires relayd or other 'hacks' to be supported.
I have difficulty believing that @CoffeyInOrlando 's option 1 can actually work -- I'd like to see the configuration as proposed and proof that it is working.
You wrote this before. Are we sure to talk about the same thing? I don't want to question your knowledge. Only, from 25 years in networking, I think I never came across any WiFi device that wouldn't work as a simple client. The USB dongles of 20 years ago did just that. Actually, I think I never came across any hard- or software that would do WiFi without a client functionality.
I mean, it doesn't make any sense to have any WiFi device (nor software) that isn't out of the box able to participate in a WiFi range as client. Does it? Okay, except an AP supplied via wired Ethernet. But even ALL those that at least I ever had in my hands, would also provide client functionality. If memory still serves me right.
Sorry if there was some ambiguity in my earlier response.
Simple client, yes... no problem.
Routed client, no problem.
Bridge from wifi > ethernet (downlink) or wifi > wifi (repeater) doesn't work without either routing our relayd.
If you have a tested and working wifi repeater that doesn't use 802.11s, relayd, or routing (just wifi sta - wifi AP), which is what I interpreted as your option 1 statement above, I'd love to see how you did this. So this would mean looking at the config files (network, wireless, and possibly firewall and dhcp).