Will extending the router antennas to rooms be a better roaming solution?

Installing and Using OpenWrt Network and Wireless Configuration
1

Not sure if proper to ask here, I have 2 AP, one in the living room as the main AP, the other in kitchen as an extender AP, both connected to my main router which is running wrt.

The problem here is, the experience of roaming between these 2 AP is bad, there is always an interruption from few seconds to minutes, sometime it just never disconnect when the signal is weak but not weak enough.

I know there are solutions like Mesh or AC + AP, but after googled a while, those solutions may have lower latency for roaming, it still have an interruption in any way, I'm thinking a way as following,

wifi
wifi802×518 20.7 KB

I'm sort of short of related knowledge so I'm not sure whether will this work, use one AP only, but extend the antennas to each room, the ports for antennas may not be enough, so I'm planning to use the splitters to extend more ports for antennas.

I also found a topic like hidden node problem, since I just use this in my house only, if this works, just I can walk to any corner any my place and the signal will be alway in good condition since there is no roaming at all!

There must be some limitations coz I don't see ppl using this...

2

I am not sure if this is a good idea.
First of all, the cables will introduce a lot of attenuation to the signal that reaches the antenna. Back in the days of wireless metropolitan networks we used to use LMR400 class cable which is not suitable to run inside a flat.
Then splitters will also introduce attenuation. And I am not sure they can work as you imagine.
Another thing to take in consideration is that multiple antennas on an AP are meant to work together, receiving the same signal and keeping the best as well as boosting the throughput. You cannot spread them in a flat and expect them to operate individually.

If you have issues with coverage in the flat, it's better idea to do a survey, locate the dead spots and add another AP as needed. Mesh is not necessary, it's much more preferred to use Ethernet for uplink.

7 Likes
3

If you mean adding a cable to a 2.4 or 5.4 GHz antenna:

  • usually modification of the radio-portion is illegal anyways
  • as @trendy noted, adding cables to such high frequency bands - usually causes so much loss that the wires are actually burdensome
5 Likes
4

This would be a bad idea to implement - for a lot of technical reasons (some of which have already been covered), and several practices ones (like getting and running the right types of cables and such).

What you want is more full APs running over standard Ethernet and configured for lower power per ap. When tuned properly, the roaming can be very fast and barely noticeable.

7 Likes
5

Sounds like this really a bad idea, no wonder nobody implemented this ever, thank you all for sharing the very useful information and suggestions, I will probably go with more APs and tuning.

6

Just so you know, I have two OpenWrt routers connected via WDS. Not even using 802.11s mesh, just 802.11r plus a script in each router to kick clients out when signal strength is low. Zero interruption with roaming and handover.

And with 802.11s + BATMAN, I believe in theory there is zero interruption and seamless service throughout the entire coverage area if setup properly.

4 Likes
7

This is really awesome! would you share the scripts and little tips to set it up? I'm a very newbie to OpenWrt, not sure how can do this in a proper way, or any docs to refer, many thanks.

8

the client devices (phones, laptops, tablets etc) do not participate in the mesh, they just see a set of APs and roam between them. the best option is always ethernet backhaul. mesh is a good option if you cant run the ethernet to the APs

2 Likes
9

And this is a key point worth emphasizing: if you can run ethernet between the router and the APs, you will get better performance. Mesh and WDS (BATMAN included) have performance penalties even in the best case scenario. But they also rely on the ability for each standalone AP to establish a good wireless signal to at least one other AP which means that placement of the APs becomes a compromise. A wired connection, by contrast, will almost always be more reliable and higher performance (provided the cables are good and in-spec).

1 Like
10

hi may I know does 802.11r protocol require hardware support? I have Netgear N6100 v1, Netgear R7500, Netgear R7800, but I don't see from the hardware specs that any of them supports 802.11r? Do I need to buy specific routers to achieve the same roaming experience as yours? thank you.

11

802.11k/v/r are software features (hostapd/ wpad).

1 Like
12

I have no problem getting full-speed links between my two tri-band satellites and my main access point, while also having good client speeds and reliable roaming. Both satellite APs have at least two layers of plaster and (wood) lath between them and the main AP.

All the nodes are placed for convenience, not optimal signal characteristics. My network engineering has been a few rounds of tweaking transmit power while keeping an eye on link speeds and client signal strength.

People seem to ignore the fact APs have superior antennas compared to most client devices.

I'd still prefer a wired backhaul, but things work well-enough that I'm not motivated to pull and terminate ethernet cable in this old house.

13

I'm not saying that you can't get a good link and good coverage, but rather that when wiring is an option, you don't have to worry about wireless uplink signal quality. For example, if we assume that the practical range of an AP is ~125'-150' (for this example) and I have a 500 foot long space, I could put 2 APs up at approximately 125' from each end and have good client coverage with minimal overlap between the APs to enourage client roaming, But now the APs are around 250' away from each other, which may be too far for a reliable wireless uplink. To ensure a quality uplink signal, I'd likely have to move them closer together but that may actually compromise the extreme ends of the coverage area (or I could add an intermediate AP in the middle of the space).

Yup... people do often forget this. But I didn't -- I've actually talked about this in other posts. And in my example above, it is plausible that the the APs would actually be okay at those distances while the clients may be dropping down in signal quality. But, wherever possible, a wired backhaul is preferred for link quality as well as avoiding the performance penalties that come with wireless uplink in general.

In the OP, the idea discussed was literally moving the antennas into different rooms which would involve wiring (with coax cables). While this would not work well for many reasons, if wires can be run, it makes sense to run ethernet and add hardwired APs to the network. If cables are not plausible or are cumbersome, wireless uplink obviously becomes a more attractive option (although there are other options like MoCA and power line adapters, which can be considered based on the objectives and constraints).

14

…and it gets much more interesting with multiple storeys involved (signal propagation through floors/ ceilings tends to be much worse than 'just' through walls).

1 Like
15

Indeed. And then there are all the other RF considerations about building materials and objects in a space (including people) that have absorptive and/or reflective characteristics, RF noise/interference from other APs and similar 2.4/5GHz devices, and so on. I ignored all real-world variables for simplicity. A spherical cow is sliding on a frictionless surface with no air resistance....

16

Sorry, didn't notice you sent me a reply. Take a look at this: https://github.com/barbieri/barbieri-playground/tree/master/openwrt/wifi-disconnect-low-signal

Aturally pretty easy to set up. If you run into problems, I can share more information with you. Just let me know.

Note: recently I realised the script will render 802.11r useless. But even without 802.11r, many of the devices will still be able to roam seamlessly.

Also note: I have now switched to batman + dawn that do take advantage of 802.11r. but for legacy devices that don't behave well with these tools, the script still seems to be a better solution.

17

No worries and thank you for the sharing, I have just set up my 802.11r network by simply ticking the 802.11r checkbox of each AP, the roaming works fine compare to last time, I saw that script days ago but yet apply, and probably will never do coz you mentioned that will put 802.11r useless.

How's the batman + dawn solution, does it run a better seamless roaming for you? I have all my APs wired to primary router, theoretically it should be much batter that 802.11r w/o that script right?

I have checked all my routers and they all support 802.11s, sounds batman + dawn is the ideal solution for me too.

18

If you have wired backbone for your APs (i.e. All your APs wired to your primary router / gateway), then

  1. That script will still help kick your devices out of a weak AP. That script however is based on a very simple concept: if the current connection between device and AP is weaker than a certain signal strength, the AP kicks the device out. It will then be up to the device to quickly connect to any other AP. 802.11r all by itself doesn't do any active kicking. If roaming works, then that particular device of yours simply has the capability to make its own choice on which AP to roam to without any external help.

  2. Even if you decide to switch to batman + dawn, you do NOT need batman. So no need to even consider batman. As for dawn, it still seems to be pretty buggy at the moment. So if you say your device(s) roam fine as it is now, no need to do anything if you ask me.

Edit: just read my response again and realised my point number one above is a little confusing. What I meant to say is that if you say your device roams well already even without the script, that means this device you have has the capability to make its own decisions on which AP to roam to without any external help like that script. Whether or not you still want the script for other devices in your environment that may not be that smart will be up to you.

1 Like
19

Hi thank you for the clarifications, I do have few Android devices which seems not complying the FT rules, anyway I don't use them very often so it's fine at this moment.

I wonder if have you tried signal_blacklist to that script? the broken part might be caused by the devices which have original capability for 802.11r, use this option to block those already working devices e.g. Apple devices might help.

I read through batman too, and I can't agree with you more, this option is not necessary when ethernet is in use, Dawn acts as the AC (access controller) only, I think I will do nothing for now since dawn got issues reported either.

20

... not really. The script makes use of a function called "del_client" (more appropriately termed the "del_client" method in hostapd) to disconnect clients. This method of disconnecting a client will leave the client scrambling to find another AP to attach to. No Fast Transition or 802.11r will take place in this scenario.

I believe this "del_client" method is also used by the disconnect button you see on the Luci's Status -> Overview page (scroll down until you see the red "Disconnect" buttons). If you go ahead and try it for yourself by disconnecting your Apple device there, it will still quickly connect to another AP (if within range), and in fact it will seem like the transition is seamless as indicated by your phone's wifi indicator never disappearing. But no 802.11r doesn't kick in. It is a slow transition not a fast transition.

It is actually easy to tell if it is 802.11r FT or not for each transition that takes place. Type 'logread' on an SSH terminal session to the router right after a device has been transitioned to that router. If you see

Thu Nov 25 01:08:07 2021 daemon.err hostapd: nl80211: kernel reports: key addition failed
Thu Nov 25 01:08:07 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 10)
Thu Nov 25 01:08:07 2021 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx

getting displayed, with xx:xx:xx:xx:xx:xx being the MAC address of your client device, then FT / 802.11r was used to do the quick transition (a ~20ms switch according to some other forum posts).

If you see this instead

Thu Nov 25 01:06:38 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Thu Nov 25 01:06:38 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Thu Nov 25 01:06:39 2021 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Thu Nov 25 01:06:39 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 8F14899AA89FD72E
Thu Nov 25 01:06:39 2021 daemon.info hostapd: wlan0-1: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Thu Nov 25 01:06:39 2021 daemon.notice hostapd: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx

Then no, FT / 802.11r was not involved in the transition.... a slow transition if you will (~200ms according to that same post I have read somewhere).

Just for the sake of knowledge sharing, some of the transition management tools like Dawn instead use a function called "wnm_disassoc_imminent" (more appropriately termed the "wnm_disassoc_imminent" method in hostapd) to reassign clients to other APs. With this method, 802.11r will for sure be taking part in the transition process. As this method allows for all relevant information to be sent to the client regarding the transition --> from which source AP to which destination AP. The script on the other hand simply cannot use "wnm_disassoc_imminent" so it is stuck with "del_client", as it as no knowledge of any other AP in the local network.

Edit: I should point out one more thing too - you mentioned about using the 'blacklist' option provided by the script to block those already working devices like Apple devices.... Essentially what this does is equivalent to telling the script "leave my Apple devices alone, do not touch them at all, do not issue "del_client" commands to them". So your Apple devices will continue to make their own roaming decisions like they always have, and yes these self-initiated roaming actions will make use of 802.11r.

Edit 2: It actually might be a good idea for you to implement the script for your Android devices. Add your Apple devices to the blacklist so they continue to make their own 802.11r roaming decisions as you say they are roaming well with 802.11r enabled in your network. The script will (from experience) certainly encourage your Android devices to roam more aggressively, albeit doing "slow transitions" (but still zero interruption most of the time). With that said, I have faith that once Dawn stabilizes and bugs are ironed out, it will be a once-and-for-all solution of managed roaming with FT for all of your devices that support 802.11 r/k/v, which pretty much covers all modern Apple and Android devices.

2 Likes