Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a UniFi access point at home. My home is rather large, 2 stories, and wooden walls somewhat block reception. However, I do not see any huge issue with wifi once initial connection is established. I do see enough bars on wifi indicator to suggest a pretty strong signal.

The problem I am having is with initial connection. One laptop is rebooted or comes from sleep mode, it would not connect to access point when i'm not standing close to it. I need to bring laptop physically close to AP in order to get connection. But once connection is established, I can go very far away from it without disconnect, signal is strong, and connection is responsive.

what could be causing it, and how would one go about diagnosing the issue? laptop is running ubuntu 13.04

share|improve this question

It would be good to know if you have tested and gotten the same result with multiple devices. I have run across numerous problems with Ubuntu and the driver selection in the past (they have gotten better recently) that creates a large number of wireless problems. However I will hope you did some basic troubleshooting and test with multiple devices before posting.

Not familiar with Ubiquiti products, but my first thought is that you have some sort of probe response threshold (PRT) setting misconfigured (vendors name this differently, so you may have to look for other settings).

Basically, the PRT is used in enterprise gear (Unifi is pitched as enterprise) where you will have a deployment of multiple APs to help ensure that clients pick the right AP to connect to and receive good service.

The way it works is that you set some sort of PRT (either in SNR or RSSI). When the stations send out a probe request, the AP will only respond if the signal from the station is better than the threshold set. This is helpful because the station will not be able to associate to an AP that is further away (because it doesn't respond) than a closer one that would provide better service. If the PRT is set too high in a one AP environment, you will get the behavior you indicated.

In your case, you still see the network from further out when not connected because you still see the beacon frames. When you go to establish the connection, if the PRT is set too high, you won't be able to connect from further out (where the signal is weaker) but connect just fine from closer in. Once the connection is established, the PRT is no longer in play and you can move further out.

Check to see if there is a PRT setting or similar and if there is either disable it or reduce the threshold.

share|improve this answer
Thanks for answer! I do not have same issues with Android phone, connecting to same AP. Device I use in laptop is Intel Cenrino 6235AN, which is supposedly supporten on linux. I also do not think there's any threshold configurable on UniFi, but I might just need to dig deeper. At any rate, that's something to investigate. – galets May 13 '13 at 19:58
up vote 0 down vote accepted

Apparently, the 802.11N support is still not fully operational in linux, even with latest kernels.

11n_disable=1 option fixed the problem...

share|improve this answer
I believe you that turning it off fixed your problem, but it's extremely hard to believe that N support is not fully functional in Linux. N products started shipping six and a half years ago. All the vendors of Wi-Fi chipsets use Linux on their AP reference designs, including N and AC APs, and that's been the case since A and G first started taking over from B. It may be that the driver for your particular Wi-Fi chipset sucks, but I'm sure it's not a general problem with Linux's support for N. – Spiff May 15 '13 at 3:41
@Spiff It is hard to believe indeed, and it was part of why I was reluctant to turn it off for such a long time. And yet, it appeared to have been a problem. I wonder if there is some more fundamental issue at work here – galets May 17 '13 at 21:25
I'm saying you've jumped to the wrong conclusion. It's not a general Linux 802.11n support problem, it's an 802.11n support problem specific to the Linux driver for your particular 802.11n card. – Spiff May 17 '13 at 21:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .