I build public Wi-Fi networks, you've probably used one of them. AMA if you have Wi-Fi questions.
To say it "sucks" is a bit harsh. It's delivering multiple hundreds of Mbps to you via an unlicensed contention-based medium. The air interface is like sending packets over a noisy Ethernet hub; it's impressive it works as well as it does. That said, this article's a good primer on some of the protocol's fundamental challenges.
In the coming years we'll hear more about 802.11ax, which is thankfully focused on efficiency vs. raw numbers, but likely won't be ratified until 2019/2020.
On macOS, someone below recommended "WiFi Signal", USD 5.
Not so fully featured, I assume, but free is Wireless Diagnostics. Ignore the popup, and go to Windows -> Info/Scan/Performance
(it's in System -> Library -> CoreServices -> Applications, but I start it via Spotlight)
> Not so fully featured, I assume, but free is Wireless Diagnostics. Ignore the popup, and go to Windows -> Info/Scan/Performance (it's in System -> Library -> CoreServices -> Applications, but I start it via Spotlight)
Protip: it's also easily accessible by holding Option and clicking on the Wifi icon in the menu bar.
Once you're connected wifi is great. It's the long connection negotiation and the slow reconnection process if it gets interrupted or you switch networks that's infuriating. I get upwards of a minute of downtime when I switch from my router to my AP at home.
Virtually none of the handoff delay is actually due to L1 or L2. The PHY handoff itself can happen in less than 10ms, and with Pre-Auth that handoff is actually happening before you even leave one AP for another.
I've always wondered about this, but given how slow WiFi connects I assumed it impossible. But with this new information....
You're saying that in a train, if I do a track once and connect to every open network (assuming no captive portal) and obtain DHCP offers, thereby obtaining IP subnet information and being able to guess an unoccupied IP address later, I can connect to the networks on my way back and get responses from a remote server to one or two packets?
Say there is about 20m of track where a given router is in range (train won't be running that close to the building and there is a wall in between) and we're doing 130km/h, that gives me about 20/(130/3.6)=0.56 seconds of range time. A server within the same country (the Netherlands) is usually <40ms RTT on any network, so PHY+SYN+data+responses = 10+40+40=90ms, easily in range of 560ms. A tricky part is knowing when I'm in range (I shouldn't wait for a beacon), but with GPS and triangulation of beacons it shouldn't be hard to figure out where each AP is and when I'm in range. Worst case I have to do the track a few times to get enough beacons to see where signal starts and stops.
It may simply be the DHCP that's the problem - the step it's hanging on is always "requesting IP address". I've tried fixed IPs and that hasn't helped. Part of the problem is that even though I bought a designated access point device instead of a generalist wifi router (and I suspect it's the same device with marginally different firmware), the configuration process to make this stuff work is completely opaque. I have no idea what I'm doing right or wrong, and every guide says something different - at this point I'm at just "give both networks the same SSID and encryption and password and hope it all works out".
Setting all APs in one network to same ESSID is exactly wbat you should do and for half-reasonable APs that works well.
Big name brand vendors will sell you APs that support some proprietary coordination mechanism between them (usually with central "wireless network controller" as separate device), but that is not required for roaming to work. Such solutions (apart from centralized management) are mostly to keep your APs from interfering with each other (which is non-issue unless you have more than three and unless they are placed in unfortunate physical locations).
Yes and nothing special, as long as the clients and AP are moving consistent to each other.
If the client is moving >10MPH relative to a fixed AP (i.e. you're driving past the AP in your car), Wi-Fi doesn't handle that well. Your movement creates Doppler shift in your RF signal, which Wi-Fi can't adjust for (vs. e.g. LTE which does).
Doppler shift in a radio wave at 10 mph? Wouldn't the Doppler shift be around 36 Hz in that case [1]? That's about 0.015 PPM. Seems temperature would have a bigger impact on frequency stability than that.
Edit: I'm certainly not an expert in RF. I checked my intuition against the datasheet of a radio module I've been working with (RFM69HCW), and found in a footnote of an equation (on page 31):
> crystal tolerance is in the range of 50 to 100 ppm
Keep in mind, modern WiFi uses OFDM where the signal is transmitted via a number of simultaneous carriers offset by very small frequencies. So while the center of the 20Mhz band might be shifted just a little the small carries might be shifted far enough onto each other that the signal is unintelligible.
If the individual carriers aren't overlapping in the transmitter, they won't be overlapping in the receiver, either. Each one will be shifted proportionally (∆f/f0=∆v/v0) in the same direction. The signal is still intelligible. It's just shifted.
A radio is a physical device subject to manufacturing variance, temperature fluctuations, and aging effects. It has to be manufactured to tolerate frequency deviations caused by these effects. What I was trying to show in my analysis is that the effect due to Doppler shift at 10 mph is orders of magnitude less than at least one of these effects. If the Doppler shift at 10 mph makes the signal unintelligible, then the other effects I mentioned should as well.
For example, a transmitter with 50 PPM accuracy could cause a 2.4 GHz signal to drift by up to 120 KHz (0.00012 GHz). That's about 3000 times more than the 36 Hz that I calculated for Doppler shift at 10 mph.
> If the client is moving >10MPH relative to a fixed AP (i.e. you're driving past the AP in your car), Wi-Fi doesn't handle that well. Your movement creates Doppler shift in your RF signal, which Wi-Fi can't adjust for (vs. e.g. LTE which does).
Perhaps current-generation WiFi has more of an issue with that, but I've helped build systems that used a much older generation of WiFi in an ad-hoc (no AP) mode between nodes with a speed differential of Mach 1 (between a rocket and the ground). It worked fine, and lost almost no packets over the course of the flight.
US, but TTBOMK it wouldn't have been with the combination of amp and antenna. At the time, we'd looked it up and the legal limit without an amateur license was somewhere in the hundreds-of-milliwatts range.
Normal Wifi is extremely low power by regulation -- the medium itself is capable of much more, and I assume this project used different antennas than you find in your router.
I worked a place that did roaming from one AP to another one on a train in Norway in the early 2000 / late 90s, think we was the first in the world to do it.
To don't have a huge network drop we used a VPN connection on the client computer so it had the same IP while jumping from one wifi over to the other one.
Even if you forget the ubiquity of it... it saves ridiculous amounts of money. 15 years ago, we'd spend like $50k to wire up new office space for 100-150 people. Now... maybe $5k with cable pull.
Yeah, it's ubiquitous but I'm not so hot on the reliability. It may save a lot of money to not wire up an office, but I wonder what the production losses are due to less reliability.
Wow, that article taught me that our office is probably using the wrong setup for optimal VoIP performance. When I started, I bought us an Asus RT-N66U to replace the ancient 802.11g router that was powering the 5 computers, 4 smartphones, 3 ethernet VoIP phones and 1 printer. Fast forward two years and now we have 12 computers on wifi using soft phones, 3 engineering rigs on ethernet, 11 smart phones, and that lonely printer.
I'm now thinking that our occasional VoIP issues probably aren't Time Warner (er, "Spectrum," whatever)'s fault, but might be caused by overwhelming the physical capabilities of our router.
So what sort of hardware should I plead with our CEO to let me purchase? Is there any way I can test, calculate, or prove that upgrading the infrastructure will prevent the operational staff from saying "Hello..? Hello..? Can you hear me?" on a phone call?
It sounds like, from hopping over to the linked CNet article, that maybe putting another router with the same network name and password, hardwired into the opposite corner from the existing router, would let us split the load across the office. But the end of Anand's article says I should throw up my hands and quit because the back room where a new router would go can still hear the original Asus transmitting loud and clear, so client devices would still have delays caused by picking up other networks.
The solution is don't do VoIP on WiFi. You mentioned the 3 ethernet VoIP phones, do those have issues? Also, unless you're running third party firmware on your Asus router, you're going to start dropping VoIP packets whenever anything maxes out your connection. The packet loss actually isn't really a problem, the problem is that when you max out your connection, whatever cable modem you're using is going to start filling up a massively oversized buffer instead of dropping packets and any new packets go to the back of that buffer and take hundreds of milliseconds before the packet even leaves your building.
The fix if you're stuck dealing with crappy equipment that has massively oversized buffers is to throttle the connection in another device downstream of the modem to slightly under what the modem will throttle you to and then in addition to that you can also implement QoS so that your VoIP traffic is put into a different queue and give that queue a higher priority.
This is all predicated on the assumption that your ISP is actually providing what they say they are 100% of the time. If you pay for 5 Mbps upstream, set the QoS to 4.5 Mbps and your ISP delivers 4 Mbps 10% of the time then for that 10% of the time your equipment will be sending too fast and you'll go back to filling up that oversized buffer just like before.
So he's specifically referring to collision on the same channel, not that a device connected to Router A on 2.4 channels 1->4, but can also see Router B on channels 10->13 has to wait to transmit data back to Router A.
Yes, collision occurs on the same channel transmit.
You'll probably have to setup two different essids. Most devices I've used will keep using the same ap even when its signal is lousy and they have a great signal to the other ap
Not the OP, but yes it works great. The APs themselves do not need to support it, the client does. But you can also do zero handoff (quicker, like for voip heavy environments) and that needs AP support. Read https://help.ubnt.com/hc/en-us/articles/205144590-UniFi-What...
It's worth noting that newer Ubiquity APs no longer support Zero Handoff. Part of the problem was that all the APs needed to be on the same channel, which caused co-channel interference under heavy usage; there was a significant performance impact. (Also, I believe that chipset in the newer Unifi models just don't support it.)
Without it, clients can still roam between APs, but you'll notice ~1 second of packet drops each time your client roams to a new AP. It won't drop a VoIP call, but you'll notice a moment of silence when it happens.
The future is 802.11r/k/v, which will allow clients to roam themselves quickly between participating BSSIDs without needing to renegotiate the connection each time (as opposed to relying on pure AP-based hacks).
In theory that works, but a lot of phones get angry when the AP stops talking to it. It just assumes that you lost WiFi and disconnects and doesn't try to rejoin right away
Yes it absolutely does, but it is dependent on the station (the client) doing so. One of my gripes about Wi-Fi is that it delegates too much to the station - your experience is thus dictated by whoever wrote your phone/computer's Wi-Fi chipset driver, and how they interpret the standard.
Any Wi-Fi network supports roaming on the network side, you just need all of your access points to use the same SSID, and to dump users onto the same subnet consistently (otherwise you'll need to re-IP after roaming).
So on that note, do you have any brands/manufacturers/chipsets that you see as particularly good in terms of being a client?
Its always a gamble when I get a new phone/laptop/device if it will work with the multi-AP setup I have in my house, and I'm really tired of getting something and bringing it home only to find it hangs on to the furthest AP for dear life.
> So on that note, do you have any brands/manufacturers/chipsets that you see as particularly good in terms of being a client?
As a client, the Intel wifi hardware works quite well, as does the software stack on top of it (at least on Linux). It helps that they're the ones who've written a fair bit of the wifi stack itself.
Ubiquiti UniFi AC or UniFi AC-LR. I'm not the poster above you were asking. Never need rebooting. Present a single AP name for multiple devices and both 2.4 and 5.x GHz. Reasonable price for home use. Based on personal experience in a large house. grk, roaming works just fine.
I've heard that Apple hardware in particular sticks with an AP longer than other devices, the Apple device is not continually looking for the best connection, it sticks with what it started with until the signal gets very weak. Don't take this literally but it's like Apple waits until you're down to one bar while some others wait until you're down to two bars before looking for a stronger connection from another AP.
You should make sure the APs don't interfere with each other. The automatic channel selection didn't work well for me. I had to manually set my two APs at each end of the 2.4GHz spectrum. It's also a good idea to turn on wide band channel. If you have an Android device somewhere you can download wifi analyser to make sure the channels don't overlap.
They don't need to be on different channels, but it's recommended for performance (due to co-channel interference).
Think of it this way: Each channel provides a fixed amount of bandwidth, and neighboring APs need to overlap slightly to provide seamless coverage. As a first order approximation, if two APs are on the same channel you'll have twice the range, but half the bandwidth because the spectrum would be shared between them.
(It's actually slightly worse than this, because collisions will happen causing additional overhead.)
I have a ubiquiti AP and as part of the set up it did a scan which picked my channels based on what it scanned and it seemed to do a decent job. You can go into the controller software to initiate a scan, though it will kick everything off the network for a few minutes.
If you option-click on the wifi symbol in the macOS menu bar, there's an option to access various diagnostic tools. One of them gives you channel recommendations as well.
I believe it is the responsibility of the client to correctly roam between similarly named APs. I vaguely recall reading into this when I read that my unifi AP didn't support roaming. I could be mistaken though!
It work but on every border there will be a zone where you can join AP on either side. You can be still on weak AP but device will consider it weak enough and won't switch just yet.
In the end if you have a problem with WiFi (e.g. not a default transparent walls and no interference) you will have a problem with it forever.
An unfortunate side effect of being in the industry is that I constantly have a surplus of enterprise-grade hardware at home. It's been a while since I looked at consumer hardware. Apple's Airports were solid, but have been discontinued. I've used both of the OnHubs and both were performant / stable. I've heard generally good things about Google's new Wi-Fi pucks, and Netgear's nighthawk series.
5G is the better of the two bands - it gives you many more channels and there's generally less interference. That sounds like something particular to your environment.
If you have a Mac, I recommend installing Wi-Fi signal (https://itunes.apple.com/us/app/wifi-signal/id525912054?mt=1...) - it gives you much greater insight into what's happening on the air. I'd start by installing something like that, and monitoring for correlation with your drops - what else happens when your connection drops? Does the SNR drop? Does the AP change channels? etc.
My phone doesn't do 5GHz, but other than that, 5GHz is significantly better until you get about 3-5 walls between you and the router.
In general, 5GHz is way better for apartments (less channel congestion, apartments are usually smaller than houses), and 2.4GHz is better for non-urban houses (better wall penetration).
For urban houses (I can see 15+ 2.4GHz networks from my living room; in a larger city it could be worse), the best bet is to have 2 or more APs and connect them with ethernet if possible, and powerline otherwise. My cable internet comes in the house in the corner of the house, and is under a different roof a-frame than the rest of the house (a previous owner built living space above the garage), so I can't run ethernet through the attic, and I use powerline adapters; there's a separate subpanel for this area too, but I still get minimum 30Mbps over the powerline, which is good enough for web/e-mail.
My next step is to see if any outlets under the main roof get good signal over the powerline, and then run ethernet throughout the attic; then I can have several routers throughout the house.
I use TP-Link APs running OpenWRT; they are cheap and OpenWRT lets you adjust the power down. If you aren't cost-constrained, I've heard almost nothing bad about Ubiquity.
Only have an anecdote, but when I replaced my latest (last?) generation Apple AirPort Extreme with a trio of Eeros for a ~1700 sq foot two-floor house I immediately wished I'd done it sooner.
Expensive for sure, but setup was a breeze, reliability has been great, and I get 200Mbit+ a floor away from my ISP router, where I used to see 20 on a good day.
I was skeptical of how well a mesh could work, but the performance has sold me.
Physics is the issue here. The 5GHz band is going to be better if you are in the same room as the AP. However, it does not penetrate walls as well, so depending on your set up (and the construction of your walls), that might explain your experience.
Not OP, but we run retail stores that do cell phone and computer repair, so we needed reliable routers that could routinely support at least 10-15 clients grabbing data at any given time. We've been using the Linksys WRT1900AC (now ACS) and they've been great.
I have one here at home as well. I'm on a Gigabit connection provided by AT&T at home, and the router sits two rooms away with 2 walls between me and it. Also, my daughter is watching YouTube videos using it right now. With all that, I just ran a speed test using fast.com on my iPhone 6 and it showed 150Mbps. Really solid router.
For the price, I think the best set up is getting what ever ethernet only router that has your needed feature set (or just use a box with linux/shorewall), and then for wifi, running cat5 with POE to some Mikrotik wAP access points.
Do you have suggestions for organizing semi-dense apartment complexes such that there aren't more SSIDs than units and are there legal ways to safely share wifi with neighbors? It seems to me that most TOS agreements from ISPs seem to not like the idea that I might share my wifi with my neighbors... Also comments on 20 MHZ v 40 MHZ routers?
For high latency, highly attenuated signal situations where varies from .1 Mbps to 3 Mbps, on OSX should one mess with MTU?
Last unrelated tangent, how far are we until we can expect to start seeing widerspread municipal wifi deployments? Is it possible that school districts might expect to see 100% home internet penetration in a non-trivial percentage of American school district areas?
What hardware, and what kind of settings do you need to seek to have a working roaming network?
I've a Mikrotik router at home (very educational), and I've very often heard UniFi ap's can do it properly. Can I do it with Mikrotik aps? Will setting it up be hell?
In general see my response to grk, you can roam with any network that meets these criteria:
1. All APs use the same SSID
2. All APs bridge users onto the same subnet
But the experience will vary from client to client in terms of how aggressively they roam. Many AP vendors offer knobs to "help" clients roam by kicking clients off at a certain signal threshold, supposedly triggering a roam: in practice, this just upsets many clients.
Re #1: "SSID" is actually shorthand for "ESSID" - Extended service set identifier. Each AP has its own "BSSID" - Basic service set identifier, which is the AP's Wi-Fi MAC address. The whole concept of an "ESSID" is to signal to clients that a certain group of APs belong to the same system.
Re #2: If you need to scale beyond a single subnet, you generally solve for this by terminating users on a centralized packet core / wireless controller, which shards users out onto multiple subnets.
I switched from single to multiple ESSID when I found most laptops would not switch BSSID until they completely lost connectivity. It was a shame because both Android phones one iPhone I tried worked great under this setup.
I've got a weird problem at my home where WiFi connection on my laptop gets really bad as soon as some particular other laptop connects to the WiFi. Reconnecting fixes the issue. Any idea what might cause this or how to gather more information on potential causes?
I had the same issue with a $300 netgear prosafe AP. When certain 802.11ac clients would connect (mostly cell phones), it would randomly get periods of of complete grid lock in the wlan. All clients would have good signal strength but they had no data throughput. Disconnecting and reconnecting the offending client would restore the wlan throughput.
The best I could see from packet sniffing was that these certain mobile clients would go into some kind of sleep mode, and when/if packets were transmitted to them, they would not respond with the proper ack (sometimes), the AP would then hang the whole wlan waiting for the ack (I guess). I tried several different netgear prosafe access points (all of them 802.11n). The only thing that worked was getting rid of my netgear hardware and replacing them with a Mikrotik wAP ac.
802.11ax won't mean anything unless you reduce interference (see my reply below). Without high SNR, all these new efficiency techniques won't get you anything. Shannon capacity is still what limits performance.
At my townhouse there are times that 2.4 GHz network dies completely in main floor. Usually its evenings, sometimes feels its periodic. Latency sky rockets even when I am 1 meter from the router.
What are the practical ways to find interference? The tools I have is openwrt router and a macbook.
I normally use 5GHz anyway, but wireless music device is still 2.4GHz which is incredibly annoying once it dies.
We had a specific lounge chair, which when you sat in it with a laptop, if someone was using the microwave, the wi-fi would drop out. If you stood up, everything was fine. We took that lounge suite to the holiday house. Good riddance :)
I love that tool. Tells me signal strength and quality (i.e. how much noise there is). Actually, opening it now, I see there has been an update and it has gained two new indicators. Used it multiple times to find APs. Also works on laptops (though a smartphone is much more handy to walk around with).
In topic of building a multi-AP but with same SSID wifi network: Do I choose the same channel too or not?
I have a wifi networks on a building built with brick and mortar, so I need more APs to cover the entire premise, there gonna be some overlaps in the coverage here and there...
No, set every AP to use the quietest channel. Using something like Wifi Analyzer on a phone positioned where the AP will be but with the AP off, see what's got the least going on... any loud APs on the same channel whether they're yours or not would be detrimental. Also completely avoid overlap. On 2.4 GHz that means 1, 6, 11.
Also, if there will be so many APs that they will share channels, you want the APs physically isolated from each other even if that means a little more isolation between AP and client than you'd otherwise have. For example, in a hotel or dorm put an AP in every third room instead of all in the hallway, so they don't hear each other.
To say it "sucks" is a bit harsh. It's delivering multiple hundreds of Mbps to you via an unlicensed contention-based medium. The air interface is like sending packets over a noisy Ethernet hub; it's impressive it works as well as it does. That said, this article's a good primer on some of the protocol's fundamental challenges.
In the coming years we'll hear more about 802.11ax, which is thankfully focused on efficiency vs. raw numbers, but likely won't be ratified until 2019/2020.