Poll: How Do You Make Your Wi-Fi Go Faster?

Helping others with Wi-Fi has been something I've had to do more often than I'd like - but it's basically boiled down to a few key points:

1. Use wired for everything that you can to preserve the air for those who need it.
2. Update the firmware on your devices - many times this improves security and stability, which helps with some of the flakiness.
3. Use 5GHz in preference to 2.4GHz if possible (device dependent). This frees up limited 2.4GHz spectrum and throughput for the few devices which need it most.
4. Choose channels wisely - in 5GHz, you can try choosing "outdoor" rated channels to avoid transmit power caps in some regions to extend your range. For both, choose channels with the least overlaps with neighbouring networks and potential interferers (spectrum analyser could be useful). For 2.4GHz, ensure you stick to the 1-6-11 or 1-5-9-13 channel raster depending on your area. There are additional technicalities in 5GHz which are region-dependent - DFS/TPC channels require radar avoidance which may cause outages and unexpected channel changes if you have operating radar nearby. Likewise, some sections of the band do not have enough contiguous spectrum (80MHz or 160MHz) to really let 802.11ac run its full bandwidth, thus you will be stuck at 20/40MHz wide channels! Whatever you do, do not leave this to Auto!
5. Use RTS/CTS protection - it adds overhead to the transmission but can help with hidden node problems by announcing your intention to transmit and receiving approval from the AP, thus other devices which hear this approval will remain quiet during your transmission. This avoids congestive rate collapse where collisions result in Wi-Fi rate fall-backs which tie up more air-time to transmit the same data, and is something which most people have turned off because of the slight overhead that it adds. In congested environments, this often improves stability.
6. Position your AP properly and get the right number of APs for your needs. Ideally, choose higher-end units from business-grade equipment if possible, but even cheap consumer gear often works well enough if properly configured. If you have one AP, position it centrally as much as possible but also away from large bits of metal, fish tanks, microwave ovens. Higher is not always better - try centrally locating it in the vertical axis of the building as well if trying to cover multiple floors. APs positioned higher up may end up receiving more competing interference from neighbours and contributing to the problem! If you can't get the coverage you need with one AP, go with several but cable them together for the best throughput experience. Use different channels on the other APs and connect them "LAN to LAN" as a bridge. Configure the same SSID/PSK for seam-less roaming. Best to choose channels which have wider gaps to provide a bit of guard band. Mesh is a last-resort choice, being expensive and tying up more spectrum! Optimising your transmit power to avoid extensive cell overlaps is also useful to push cards to roam to the better AP and to avoid causing extra unnecessary interference.
7. Choose the right antennas and configure them correctly. If you have an unavoidable situation where your AP is in a corner of the house, a sectorial antenna will work better. If you need to reach a long distance down a corridor, perhaps opt for a Yagi. Sometimes USB adapters can be favourable for allowing easy attachment to external antennas, but less portable. For MIMO access points, it can be beneficial to have say one antenna pointing up and one antenna pointing horizontally, with a third pointing at a 45 degree angle. The orthogonality in transmission polarity will increase the signal to noise ratio for each of the separate spatial streams and also provide some polarity diversity in the case of devices that may not be oriented the same way at all times (e.g. a smart phone in a bed when you roll about). The downside is that often you will have very uneven signal strengths on each spatial stream depending on the antenna configuration of the receiving device.
8. Do not use hidden SSIDs and avoid having many virtual APs (e.g. guest networks) - Hidden SSIDs cause many additional association frames from passing devices that want to check that the hidden network is not one they are allowed to join - this additional traffic can have an impact on speeds. Virtual APs require the one wireless card to send out beacon frames for each of them which reduces the available throughput. This can be especially severe when above four networks - best to avoid altogether if you can or choose to use a second radio/AP for those networks.
9. Put slower devices on another AP on a different channel - if you still have some 802.11g-only devices on 2.4GHz or 802.11a/n-only devices on 5GHz, it's best to put them on another radio/AP on a different channel. This way, you can dedicate an AP to operate in 802.11ac (VHT) mode without any co-existence strategies, improving throughput dramatically. Likewise, to enforce this, you should configure your APs so as to block associations for those without a minimum set of rates.
10. Increase your basic rate setting - some APs will let you configure the basic rate setting for broadcast/multicast traffic. If your signal strength around the property is good, you can increase this from the usual 1Mbit/s or 6Mbit/s to something a little quicker to avoid broadcast/multicast traffic from tying up all your air time. The risk is that some far-away nodes with weaker signals may not receive the broadcast due to interference and this could cause intermittent issues (e.g. ARP/DHCP failures).
11. Use multicast helper if available - some APs (e.g. Mikrotik) have a way to transmit multicast/broadcast frames as if they were unicast frames, ensuring everyone receives the broadcasts but sending them at the best individual link rate that each client is capable of. If you only have a handful of clients (e.g. <10) with good signal, it may be better to send out 10 copies of the frame at ~108MBit/s rather than 1 copy of the frame at 6MBit/s - you save time while ensuring reliability of broadcasts.
12. Consider using different SSIDs for your 2.4GHz and 5GHz networks to ensure devices are connected to the best band available. If you use the same SSID, the devices typically will decide. In this case, you could put in MAC blocking on your 2.4GHz APs to force them off the network in a crude "band-steering" move (or use a corporate AP with this capability), but the easiest way is just to use separate SSIDs.
13. Set Static DHCP leases for your devices - this can speed up the process of getting an IP address from the router as you will be (fairly) sure that the IP address is not being used by anyone else with the benefit of not having your IP address change depending on who joins the network first. Also consider setting longer DHCP lease times, as this avoids needing to "renew" the lease as often, saving a little traffic but also preventing situations where a renew may be "lost" in transit causing you to lose your address entirely along with all your open sockets.
14. Avoid multiple NATs - so many people I've seen set up a better wireless router behind an existing wireless router which results in a double-NAT situation. This is a terrible configuration as it breaks most NAT traversal strategies and can result in issues with peer-to-peer applications (e.g. one way audio, calls which fail after a certain amount of time) and or the use of fall-back strategies (i.e. routing via a cloud intermediary). It's best to ensure you do what you can to have your network have the least number of NATs possible, plus enable any NAT traversal technologies necessary - for example uPnP. This does have a risk - devices in the network which are compromised may be able to configure port forwarding via uPnP to gain a direct connection to the outside and older implementations are vulnerable, so if you want to avoid uPnP then set up static port forwards/triggers.
15. Disable IPv6 if you don't need it and your ISP doesn't offer you IPv6 connectivity - there are some routers which are now also offering IPv6 services (e.g. routing, DHCPv6). This can be a vulnerability if your ISP offers IPv6 and your device becomes exposed on a direct 1:1 mapping on an IPv6 public address. But worse still is that sometimes your ISP doesn't offer IPv6 connectivity (mine doesn't) and your router is still offering IPv6 connectivity to your downstream devices. This may lead some devices to try connecting over IPv6 first, before timing out and trying IPv4 and getting through. Disabling IPv6 may help in this limited circumstance - but also means that you won't have the ability to directly connect to IPv6 services.
16. Reposition your wireless devices as a last resort - if you can't get a good signal, then perhaps you need to turn things around or explore other connectivity methods.

I think this about covers all that I normally do - Wi-Fi usually works just fine if you take some time to plan out the network. I've not had any issues myself - most of the time it's my WAN which lets me down ...

- Gough

Excellent pointers there Gough. I think you may have helped me resolve my Skype connection problem (my calls drop after a lengthy conversation - usually my cue that I'm talking too much, LOL), with point 14.

Another potential reason for that, which I forgot to throw in, is that some consumer routers have DDoS attack prevention which is a simple "packet rate" filter. Unfortunately, some of these are set too conservatively (e.g. 100 packets per second) and detect a mass of UDP packets as a DoS attack and start dropping them causing reduced video/audio quality or downright failure of a call. For example, a VoIP voice call using 20ms frames on G.711a/u would itself result in 50 packets each way per second - adding any background traffic or a second call simultaneously could trigger a DDoS attack detection by the router causing the call to fail or "go robotic". Usually these features can be disabled or the thresholds increased, but newer routers generally don't have these issues as they have their firmware adapted to handle these common use cases.

Another issue which crops up from time to time is the Application Layer Gateway (ALG) setting - some routers have ALGs which are basically "protocol aware" mechanisms to rewrite the information exchanged between client and server (e.g. in the case of SIP) so that the addresses/ports reflect the NAT condition in a hope that they will improve compatibility with NATs. Sadly, older devices with ALGs rarely have good implementations of them, resulting in partial rewrites of headers and sometimes results in the RTP streams heading to the wrong places or inconsistent SIP sessions which confuse the gateway at the VSP. As a result, it's sometimes better to disable ALGs and set manual port forwards as necessary, ensuring non-overlapping RTP ranges and SIP ports for each of your endpoints ... it's a hassle but I've had to do this especially with older equipment.

The more you deal with networking, the more you see how many bits of gear "deviate" from the ideal case ... often because they're trying to be "smart".

- Gough

Another potential reason for that, which I forgot to throw in, is that some consumer routers have DDoS attack prevention which is a simple "packet rate" filter. Unfortunately, some of these are set too conservatively (e.g. 100 packets per second) and detect a mass of UDP packets as a DoS attack and start dropping them causing reduced video/audio quality or downright failure of a call. For example, a VoIP voice call using 20ms frames on G.711a/u would itself result in 50 packets each way per second - adding any background traffic or a second call simultaneously could trigger a DDoS attack detection by the router causing the call to fail or "go robotic". Usually these features can be disabled or the thresholds increased, but newer routers generally don't have these issues as they have their firmware adapted to handle these common use cases.

Another issue which crops up from time to time is the Application Layer Gateway (ALG) setting - some routers have ALGs which are basically "protocol aware" mechanisms to rewrite the information exchanged between client and server (e.g. in the case of SIP) so that the addresses/ports reflect the NAT condition in a hope that they will improve compatibility with NATs. Sadly, older devices with ALGs rarely have good implementations of them, resulting in partial rewrites of headers and sometimes results in the RTP streams heading to the wrong places or inconsistent SIP sessions which confuse the gateway at the VSP. As a result, it's sometimes better to disable ALGs and set manual port forwards as necessary, ensuring non-overlapping RTP ranges and SIP ports for each of your endpoints ... it's a hassle but I've had to do this especially with older equipment.

The more you deal with networking, the more you see how many bits of gear "deviate" from the ideal case ... often because they're trying to be "smart".

- Gough