UniFi - Troubleshooting Connectivity Issues


This article describes a series of tips and troubleshooting steps for UniFi Access Points' (UAPs) intermittent connectivity issues. This might manifest as a laptop or mobile phone displaying full WiFi signal, but pages either won't load or will appear to be loading but with no results. Read on for other symptoms.

  • This article focuses on resolving wireless issues only, not wired issues.

  • Recent UAP firmware releases have addressed many of the intermittent connectivity issues, so please verify that you are using the latest firmware release for your devices before investigating further. See this article on how to update device firmware.

Table of Contents

1. Introduction

2. Wired or Wireless?

3. Wired/Internet Packet Loss

4. Check Configuration

5. AP Proximity

6. Network Loops

7. Link Budget

8. Disabling Features 

9. DHCP Configuration

10. Modifying the DTIM Period

11. Wireshark - Packet Capture

12. Trace Packets Through the Network

13. Are the APs Rebooting?

14. Check Hardware

15. Ask the Community

16. Related Articles


Back to Top

Intermittent connectivity can appear as browsers reporting no Internet connectivity; or pages loading continuously with no results. Sometimes an exclamation point will appear over the WiFi bars, and sometimes the client device will select an auto-assigned IP (such as 169.254.x.x) for its IP address on the LAN.

Many of these types of issues have been fixed in recent UAP firmware releases, so please ensure that you are using the latest firmware release for your devices before investigating further. See this article for how to update device firmware. If issues continue after firmware upgrade, read on to troubleshoot.

Wired or Wireless?

Back to Top

First and foremost, it is important to determine whether the problem lies in either the wired or the wireless infrastructure of the network. Try to continuously ping Google's public DNS ( and your router simultaneously from two terminals on a laptop. If there is packet loss to both IPs, then you likely have a wireless issue. If there is only packet loss on, then you likely have a wired/Internet issue. This article focuses on resolving wireless issues only, not wired issues.

Please note that many laptops enable WiFi power-saving mode on their WiFi interface, regardless of whether the laptop is charging or not, and you may see ping responses up to 1.25 seconds late, especially if the laptop is not busy doing anything else on the network. This is designed by laptop manufacturers to conserve power, and this article will focus particularly on resolving packet loss , not packet latency.

Wired/Internet Packet Loss

If local devices are reachable via WiFi, but packet loss occurs to/from the Internet, please ensure that you have Smart Queues or some other traffic shaping method enabled on your router. It is also critical that the upload and download values of Smart Queues is configured accurately to match your contracted ISP rates. Smart Queues are enabled in a WAN network's settings. In Classic Settings go to Networks > Edit/New WAN Network. New Settings: Internet > WAN Networks > Edit/New WAN Network.

Check Configuration

Back to Top

The following AP network configuration, as seen on the access point's properties panel has three errors. 

  1. The subnet mask is too narrow to provide a route to the gateway.
  2. The Gateway itself is not on the same subnet as the static IP address.
  3. There is no Preferred DNS configured.

Misconfiguration can lead to inability to upgrade UAPs, NTP sync failure, among many other intermittent issues that are difficult to diagnose. For the best experience, it is important to ensure that all UAPs have full citizenship on the network, including DNS access and Internet-routability.

Another common mistake is to configure a switch port with inadequate VLANs. For example, if you would like to serve VLANs 100 and 200 wirelessly from your UAP, please ensure that the switch port that the UAP is connected to allows both of those VLANs. Also make sure that all intermediate switches between the UAP and the router have these VLANS configured and allowed.

AP Proximity

Back to Top

Try moving closer to the UAP that your client is associated to, to verify if the problem goes away. If the problem is resolved, then you may need to re-assess the locations and count of your UAP deployment. Interference with other electronics might also be involved, so just moving it to another location may solve it.

Network Loops

Back to Top

Network loops can easily be detected by running tcpdump on the affected UAP and/or UniFi Switches, and by viewing the output in Wireshark. Do so by following these steps:

1. SSH into the affected UAP, and issue the following command:

tcpdump -i br0 -n -v -s 0 -w /tmp/capture.pcap

2. Then copy the resulting pcap file to your laptop for viewing in Wireshark.

scp admin@192.168.1.X:/tmp/capture.pcap /tmp

This copies the capture.pcap to /tmp on your computer. You can also use winscp similarly.

3. Now open the file in Wireshark.

If there is a network loop somewhere, you will see a large amount of multicast or broadcast traffic in the capture file. Typical networks will have less than 100 kbps of multicast/broadcast traffic, totaling only dozens of packets per second. If there are thousands of multicast/broadcast packets per second, then you likely have a network loop somewhere that needs to be resolved. Keep disconnecting infrastructure devices until the number of multicast/broadcast packets goes down to a reasonable number.

If you have IPTV on your network, this may manifest as a “network loop” due to the high volume of multicast traffic. In this environment, Multicast Enhance is recommended, since it will convert these packets to unicast, and only transmit them to desired devices.

Link Budget

Back to Top

The high transmit power (TX power) of UniFi APs is great for single-AP installations, but can be problematic in enterprise/multi-AP deployments. The high TX power will extend the range for slower TX rates only, as faster rates are transmitted at a lower TX power, which is normal for ALL APs and devices. This eats up air-time for faster rates in multi-AP deployments, slowing down the entire network and potentially causing packet loss.

High TX power also causes an imbalance in the WiFi link budget between the mobile client and the UAP, because most mobile clients have a TX power between 14 and 18 dBm. Mobile clients will stay connected (and show full WiFi bars) to an AP with a strong signal from the AP to the mobile client, even if the signal from the mobile client to the AP is not sufficiently strong.

Lowering the TX power on the UAPs to 18 dBm or so will establish a more symmetrical link-budget for most devices and deployments. This can easily be done in the Controller UI.

  1. Go to Devices select an AP and click on the Configuration tab.
  2. Click on Radios dropdown menu and adjust Transmit Power under Radio 2G and set to Custom then set dbm to 18. Do the same for Radio 5G and click Queue Changes and Apply Changes. Do the same to your other access points.

Disabling Features

Back to Top

Some features such as band-steering, minimum RSSI, connection monitor, auto-optimize network and high performance devices can cause adverse effects if misconfigured or implemented with an insufficient number of APs. It is good to disable all of these features when debugging connectivity problems so that base functionality can be verified without any extra variables. The AirTime-Fairness feature can also be disabled to bring base functionality to the bare minimum.

To find the Band-steering and minimum RSSI options you will need to Enable Advanced Features by navigating to the Settings > Site > Services. Once it has been enabled, go to the Devices tab, select an AP, go to Configuration the Minimum RSSI settings you will find under Radios > Advanced Options drop-down menu. 


The Band Steering and AirTime Fairness are available within their own menu in the Config menu. Click to expand each section.


Many wireless clients also have various options in the wireless driver which may impact performance, such as “Throughput booster,” etc. It is always recommended that the latest drivers are used with default options. 

DHCP Configuration

Back to Top

Some older/misconfigured routers and DHCP servers transmit the DHCP offer/ack messages as broadcast packets, which are much more likely to be dropped. This can lead to slow connection times and intermittent connectivity. Please ensure that your DHCP offers and ack messages are unicast packets, not broadcast (the discover packet from the client can still be broadcast). To do this we would need to create different LAN segments (i.e. if you have only one LAN for multiple machines/devices create multiple LANs for your different areas) since this can really help avoid slow down by creating unicast packets. You can also accomplish this by creating different VLANS, you can use this article to help you create VLANs.

The DHCP Timeout counter can be useful in debugging common misconfiguration issues. This counter goes up by one every time a DHCP response is not seen for over 10 seconds, after a DHCP discover/request is forwarded to the wire from a wireless client. If the DHCP Timeouts number is rapidly increasing (by hundreds or thousands per day), please check:

  1. That the switch port your UAP is connected to allows traffic to pass for the desired VLAN.
  2. That your DHCP server is actually responding to DHCP requests, by sniffing DHCP traffic on your DHCP server itself. Also check the DHCP Server logs to see reasons why requests might be dropped or NAK’ed. There are many ways that DHCP relaying, etc. can be mis-configured and result in sporadic results.

Modifying the DTIM Period

Back to Top

A default DTIM period of 1 is used for compatibility and legacy reasons. However, many modern devices including recent iOS and Android phones, will perform better and save up to 66% of their WiFi battery consumption if the period is set to 3. For networks with nearly all modern devices, it is recommended to use a DTIM period of 3 instead.

  1. Go to Settings then Wireless Networks select the one that your modern devices connect to and click the Edit button.
  2. Click on the Advanced Options drop-down menu and scroll down until you see the 802.11 Rate and Beacon Controls drop-down menu.

  3. Open the drop-down menu and unclick the use default values box and then you will be able to modify the DTIM period for your 2G and 5G bands. Once modified remember to click the save button.

Wireshark - Packet Capture

Back to Top

Wireshark can be downloaded for most platforms at www.wireshark.org. Modern (2013+) MacBooks are recommended as they 1) have full driver-support for monitor mode, and 2) have premium 3x3 radios that are capable of hearing 3 NSS traffic (up to 1300 Mbps physical rate). Linux can also be used with some laptops, but most laptops only have 2x2 radios, so they are less useful.

  1. Download/install Wireshark.
  2. Open Wireshark.
  3. Click on the gear icon at the top.
  4. Ensure that monitor mode is enabled for the en0 interface: 
  5. Click Close, and restart Wireshark.
  6. Start a capture on en0. You should see beacon, control, and management frames interspersed with data frames.
    NOTE:At the time of writing this article, there was a bug in Wireshark where capturing in monitor mode would fail the first time it was enabled, unless Wireshark was completely restarted first.
    You can upload this capture to the community when asking for help, and be sure include the MAC address of the laptop or mobile device that is having issues.

Trace Packets Through the Network

Back to Top

In some cases, multicast/broadcast packets can be successful whereas unicast packets are not. It is important to understand which type of packets get how far on the network. You’ll need to determine which “VAP” interface your wireless client is connecting to first. You can ssh into the problematic AP and issue:


In the above example, you can see that ath6 is the VAP for the ubnt-ut-AP-LR network on the 5 GHz radio.

Determine if Broadcast Packets are Reaching the UAP

1. To see if broadcast packets are making it to your UAP, run tcpdump on the athX interface on the UAP (SSH on UAP):

tcpdump -i athX -n -v -s 0 -w /tmp/broadcast.pcap 

2. Send some broadcast packets using ping from your laptop (terminal on laptop):


3. Stop the capture, and start another capture named /tmp/unicast.pcap (ssh on UAP):

tcpdump -i athX -n -v -s 0 -w /tmp/unicast.pcap

4. Next, try to send unicast packets to your router (terminal on laptop):

ping (replace with your router’s IP)

5. If broadcast packets aren’t being transmitted or received, then the unicast packets won’t go out (due to a missing ARP entry in the OS), either, and you’ll need to force a static ARP entry into your laptop (terminal on laptop):

sudo arp -s 00:00:00:00:00:01 ifscope en0 (Mac OS X)
arp -s 00-00-00-00-00-01 (from Administrator Command Line in Windows

6. Try the ping again, and see if the 00:00:00:00:00:01 unicast packets arrive at the athX interface on the UAP.

Determine if Packets from the UAP are Reaching the Client

After you've determined whether there is packet loss from your client to the UAP, now it is time to determine if there is packet loss from the UAP to your client.

1. First, you will need to start Wireshark or tcpdump on your laptop to validate whether packets are getting to your laptop.

2. Then start a broadcast ping from your UAP to the network (ssh on UAP):


3. Capture the results in wireshark/tcpdump, then start a ping to your laptop (ssh on UAP):

ping 192.168.1.X

4. At the time of writing, UAPs do not have a way to set a static ARP entry, so if unicast traffic can’t be produced from the UAP, you can try producing the packets by setting a static ARP entry on a wired desktop/laptop, then sending the packets from that separate device.

You can share the capture results when asking for help in the community to diagnose where packet loss is occurring.

5. Lastly, it is good to double-check that the bridge is configured correctly (ssh on UAP):

brctl show

The output should look similar to this:

Bridge Name Bridge ID STP Enabled Interfaces
br0 ffff.44d9e7f9876a no










Are the APs Rebooting?

Back to Top

Check the uptime of the APs to make sure they aren't rebooting. Uptime can be checked by clicking on the UAP in the Devices section and seeing the Details > Overview section  of the Properties Panel. Or in the Uptime column if the Devices section is in list view. If the uptime keeps getting reset, and coincides with network downtime, then you may have uncovered a bug, and we’d love to know how we can reproduce the problem in our labs. Let us know via our Community.

Check Hardware

Back to Top

There is always a small chance that hardware could have been damaged as there are many hands that your UAP has passed through from our factory to your desk. For cases where major packet loss cannot be resolved, regardless of troubleshooting with previous sections please check the UAP with steps described in this section.

It is best to set the 2GHz and 5GHz radios up on separate SSIDs, and even better to set both of them to different SSIDs from all other UAPs, for testing purposes. For example, if the network name is "HomeNetwork", set the 2GHz SSID to “HomeNetwork-test2” and 5GHz SSID to “HomeNetwork-test5” so they don’t conflict with each other or any other SSID. If you have more than one SSID per radio, you only need to test one SSID per radio, so you only need to modify one of the SSIDs per band, not all of them. To do this go to:

1. Devices > Select the AP > In Properties Panel go to Config > WLANS. You should see WLAN 2G and WLAN 5G. Click on the edit pencil on the WLAN 2G network name you are going to modify and add "-test2" save the changes. Do the same for the 5G band wireless network then click on queue changes.

Network_selection.png  2g_network_changes.png

2. After getting the SSIDs in order, SSH into the UAP, and issue the following commands:

iwpriv wifi0 get_txchainmask

This will give you the number of chains available on radio 0. This is a mask, so 3 means you have 2 chains, 5 means you have 2 chains, 7 means you have 3 chains, 15 means 4 chains, etc.

3. Run the command again for the second radio on your UAP (if your UAP is dual-band):

iwpriv wifi1 get_txchainmask

4. Now test each of the chains on the UAP. This will test chain 0:

cm=1; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

5. Use the WiFiman app to view the signal strength of the UAP’s beacons on chain 0 for both 2 GHz and 5 GHz. Stand within 10 feet of the UAP, and if the signal strength is lower than -60 dBm, you may have an issue with that chain.

6. Try the other chains as well:

cm=2; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

7. View the signal strength on chain 1. Then:

cm=4; for a in 0 1; do for b in tx rx; do iwpriv wifi$a ${b}chainmask $cm; done; done; killall hostapd

Keep in mind that cm=1, 2, and 4, correspond to chains 0, 1, and 2, and if the UAP does not have chain 2, then you will not see any signal on that chain (and this is normal!)

8. Next, reboot the UAP to get the chains back to normal. Connect a known-good laptop within 10 feet of your UAP. Run iperf3 on a wired server (Linux, Mac, Windows OK) with:

iperf3 -s

9. Then run iperf3 from your WiFi connected laptop/mobile device:

iperf3 -u -c SERVER_IP -b 50M -R

10. Then run in the opposite direction.

iperf3 -u -c SERVER_IP -b 50M

11. Broken hardware will typically get far less throughput in one direction than the other (i.e. 50 Mbit one direction, and 0 the other). If this is the case, please @mention a Ubiquiti employee (employee usernames begin with UI-) in a UniFi Wireless Community topic for confirmation and next steps.

Ask the Community

Back to Top

If all else fails, feel free to post your symptoms and configuration for the community and/or Ubiquiti engineers. Please be sure that you've followed relevant steps in this guide, and also be sure to include details such as whether band-steering, minRSSI, ATF, VLANs, etc. are enabled. Don't forget to mark your topic as solved once the issue is resolved!

Related Articles

Back to Top

UniFi - Identifying Wi-Fi Issues with Debugging Metrics

Intro to Networking - How to Establish a Connection Using SSH

UniFi - Methods for Capturing Useful Debug Information

Was this article helpful?
62 out of 208 found this helpful
Can't find what you're looking for?
Visit our worldwide community of Ubiquiti experts for more answers
Visit the Ubiquiti Community