3.2.1 WPA2 problem

I noticed this weekend that nothing in my home was connecting to my E400.  Logs on the devices/computers themselves and on the E400 indicated that the WPA2 passphrase was incorrect.  Note that the passphrase hasn't changed on my home wifi in 8 years, two UBNT Unifi APs on my network with the same config were catching most of the rejects.  (a couple devices can't see the UBNTs)  So nothing changed at the client ends.

Tried re-entering the passphrase in the direct AP login, and in the cnMaestro cloud, neither made any difference. (also tried disabling agressive steering, fast roaming, etc - basically everything not basic WPA2 802.11n: no difference) Then I downgraded to 3.1.1.1. (been running 3.2.1 for about a week, don't remember exactly) Still couldn't connect, so direct login to the E400 I again re-entered the passphrase, and now everything is connecting again.  (AND I noticed that the passphrase now shows in the webUI as three stars longer than it did before - coincidentally or not, I have three spaces in my passphrase)

It looks as though something gets mangled in the WPA2 passphrase under 3.2.1.  I may re-upgrade to 3.2.1 tonight and test a few simple passphrases to see if I can narrow the cause, but I suspect somewhere between the UI and settings storage some characters are being stripped from the passphrase.  (If I get the chance, I'll try all-alpha and/or all-numeric passphrase, see if it works, then add a space in the middle and see what happens - and also try changing passphrase via CLI instead of webUI)

j


@newkirk wrote:

I noticed this weekend that nothing in my home was connecting to my E400.  Logs on the devices/computers themselves and on the E400 indicated that the WPA2 passphrase was incorrect.  Note that the passphrase hasn't changed on my home wifi in 8 years, two UBNT Unifi APs on my network with the same config were catching most of the rejects.  (a couple devices can't see the UBNTs)  So nothing changed at the client ends.

Tried re-entering the passphrase in the direct AP login, and in the cnMaestro cloud, neither made any difference. (also tried disabling agressive steering, fast roaming, etc - basically everything not basic WPA2 802.11n: no difference) Then I downgraded to 3.1.1.1. (been running 3.2.1 for about a week, don't remember exactly) Still couldn't connect, so direct login to the E400 I again re-entered the passphrase, and now everything is connecting again.  (AND I noticed that the passphrase now shows in the webUI as three stars longer than it did before - coincidentally or not, I have three spaces in my passphrase)

It looks as though something gets mangled in the WPA2 passphrase under 3.2.1.  I may re-upgrade to 3.2.1 tonight and test a few simple passphrases to see if I can narrow the cause, but I suspect somewhere between the UI and settings storage some characters are being stripped from the passphrase.  (If I get the chance, I'll try all-alpha and/or all-numeric passphrase, see if it works, then add a space in the middle and see what happens - and also try changing passphrase via CLI instead of webUI)

j


Are the spaces in the middle of the passphrase or towards the start/end? Could you please give us a sample passphrase (not the exact one you use, just something we can try to recreate this, which has the spaces and/or any non-alphanumeric characters that you are using). We'll try some combinations here in the meantime.

something like "this is a passphrase".

My actual passphrase is 22 characters long, alphabetic with spaces.

j

Hi,

Will try get back on this one.

WIth Regards,

Channareddy

Thanks.  I didn't get a chance to test anything last night, had 8 APs go down due to GPS sync failure (looks like surge suppressor on CMM4's GPS antenna was the culprit) and working on a couple servers until about 2am.  Will try again tonight.

j

Update - (After downgrading to 3.1.1.1 a couple days ago I deleted the previously-disabled WLAN1, leaving just one defined) I added a second WLAN with ssid 'newktest' and passphrase "this is a passphrase" in 3.1.1.1, connected with phone and tablet and it worked fine.  Updated to 3.2.1 and it worked fine.  Tried editing it both locally and then via cnMaestro, seemed to work fine.  Then I edited the passphrase again in the direct webUI, setting it again to "this is a passphrase" and it started rejecting the WPA2 passhprase.

After a few tests to confirm, I then changed the passphrase in my tablet to "thisisapassphrase" and it connected...

So I don't know exactly what steps lead to it, but at some point it starts stripping spaces from the passphrase.  Once downgraded I need to re-enter the passphrase before anything can start connecting again, so the actual stored passphrase is altered.

Also worth noting, my original WLAN (also with spaces) continued to work under 3.2.1 when the test WLAN stopped, until I went into the local webUI and re-entered the passphrase for that one, then neither WLAN would work until I downgraded.

Suggests it's part of the webUI save process where the problem happens.

As an aside, it would have been really helpful if there was a way to view the plaintext WPA2 passphrase in the webUI.

j

Hi,

Thank you for the inputs wrt WPA2 problem.

Internally, we are able to reproduce this issue and will provide a new software image with fix, ASAP.  Following are the steps to reproduce:

  • Configure WLAN profile in cnMaestro with passphrase as "this is passphrase" and push it to AP.
  • AP accepts the configuration with passphrase as "this is passphrase".
  • Login to AP GUI and enter the passphrase "this is passphrase". AP saves the configuration but with spaces truncated.

Above issue is with R_3.2.1.

R_3.1.1.1  works abosolutely fine.