R7000 can only connect if unencrypted connection (no WEP, no WPA)

[kenyee]

Turning on any kind of encryption prevents anything from connecting to it.

It didn't used to be like this. I think the neighbors added something that's jamming wifi a few weeks ago.
When I first installed the R7000, it was blazing fast compared to the Asus RT16 it replaced which was slugging because it was probably getting jammed for the past 9 months :-(

Tried renaming SSID names, tried using all the different WIFI channels for 2.4 and 5GHz, one by one. Tried using only 5GHz. Used android's wifi analyzer to avoid choosing channels that are busy. Tried shutting off any devices next to the router. Tried sitting right next to the router. Tried moving the router w/ a long ethernet cable. Tried TKIP and AES encryption. Tried exchanging the R7000 in case hardware is defective. Nothing works and I'm baffled. Usually can set these things up blindfolded, but no luck at all this time

So I've resorted to a hidden SSID w/ no encryption, but it only accept MAC addresses for my devices. This is suboptimal obviously. Anyone ever have this problem or have pointers to what this phenomenon is called so I can Google for it?
What's more puzzling is I've tried multiple wifi routers (old Asus RT16 has this problem as well as a Tripmate travel router) and they all exhibit the same problem.

 

[stevech]

Hidden SSID won't help.
TKIP - no.
AES yes. with WPA.
WEP - no.

I'd guess that there's a subtle typo in the WPA password on th R7000 and/or the clients.

 

[RogerSC]

Yes, you need to get WPA2/AES working, and use strong passwords in addition. WEP and WPA/tkip won't let your wireless go faster than legacy wireless-g (54Mbps). And no security is just that, you have no control over who logs into your wireless network. "SSID hiding" and MAC filtering aren't helpful for security, either both are easy to get around. "SSID hiding" also may give some of your client devices problems, which isn't helpful.

Not sure why WPA2/AES won't work for you, but using a simple password with it at first, just to get WPA2/AES working, and then making the password stronger when you see WPA2/AES working may help.

 

[kenyee]

Hidden SSID won't help.
TKIP - no.
AES yes. with WPA.
WEP - no.

Sorry...it's actually, no to all.
I've tried all the encryption methods. TKIP/WPA/WEP,WPA2. Only thing I haven't done is tried setting up Enterprise but I'd have to fire up a RADIUS server.
I've tried changing the password multiple times to different things. Even to something simple like "Stupid"
So it's hard to type those in wrong. And as I mentioned, the R7000 worked great for a few weeks where the RT16 was having slowdown issues, but whatever was jamming the RT16 was cranked up and everything got jammed :-(

 

[TonyH]

Sorry...it's actually, no to all.
I've tried all the encryption methods. TKIP/WPA/WEP,WPA2. Only thing I haven't done is tried setting up Enterprise but I'd have to fire up a RADIUS server.
I've tried changing the password multiple times to different things. Even to something simple like "Stupid"
So it's hard to type those in wrong. And as I mentioned, the R7000 worked great for a few weeks where the RT16 was having slowdown issues, but whatever was jamming the RT16 was cranked up and everything got jammed :-(

Hi,
Tried after factory reset? I mean try it as is using factory reset value of encryption.

 

[kenyee]

Hi,
Tried after factory reset? I mean try it as is using factory reset value of encryption.

Yep. Multiple times. Multiple different firmware (latest 1.04 stock, as well as latest Kong DDWRT and BS DDWRT and Tomato)...

 

[coldwizard]

Yep. Multiple times. Multiple different firmware (latest 1.04 stock, as well as latest Kong DDWRT and BS DDWRT and Tomato)...

Here is a long shot. Check the date / time on the clients. I remember reading somewhere that there is a limit as to how much a difference the client time can be when compared with the WiFi access point's time.

Other thought is check for a driver update for client.

 

[sfx2000]

Check the password/passprhase length - no less than 8 characters, better to have something that is longer that 15 characters so that certain versions of Windows don't store them in the older LANMAN hash format, and you can go up to 63 characters, however some devices stop at 50 - 15 characters is more than sufficient...

Any printable ASCII characters should be good, however I tend to stay away from "#, *, $, %, and ;" as these have specific string functions in both Linux and BSD, and if the UI code doesn't sanitize them...

 

[kenyee]

coldwizard: good thought on time...was set properly though...the Netgear OEM firmware doesn't even give you a chance to choose the wrong timezone. DDWRT does but I always set it to New York time. Times matched on all devices.

sfx2000: the passphrase was 9 characters long, but the connection failure happened on lots of devices: Windows 8 laptops, MacOSX Yosemite MacBook Pro, iPads, iPhones, various Android phones from HTC/Samsung w/ versions from 2.1 to 4.3, Nexus7 tablet w/ Android 5.0. The Thinkpad actually managed to send some packets in WPA2 mode, but you could tell there was lots of packet loss because of the slow speed
What baffles me is I had the other travel wifi router (a Tripmate) worked in WPA2-Personal mode for a while, then had the same symptom. Cheapy $60 router worked better than $150 relatively high end consumer router?
I'm still on unencrypted hidden SSID w/ MAC address lockouts. Really lame. Only thing I can think of is to buy an Ubiquiti router which is a commercial router w/ more diagnostics that might give me a better clue but I'm not sure dropping another $300 on a router is going to solve this...

 

[sfx2000]

That's pretty odd - and doesn't make much sense to be honest...

Very much a corner case - any chance that you've angered a neighbor?

Nice little thing to annoy neighbours is to send de-auth packets to that AP - and this bounces everything attached to it - need to have authentication enabled for this attack to work... pretty easy to do on a linux box with the right software and WiFi adapter..

http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/

And there isn't really any reasonable way to fight it...

sfx