[E 2015 Original Android Development] IronTechmonkey:
Possible wifi tether issue (like the one in CM13)

[MENTION=6485916]squid2[/MENTION] This is similar to what I saw briefly in CM13, but this time on hardware where the connecting device's age is not a question as it was in CM13 tests. There may indeed be a problem connecting to secured tethered Wifi. Scenario:

- Connecting from Moto E XT1511 running CM12.1, 11/30/15 nightly.

- Connecting to Moto E XT1511 running CM12.1, 12/16/15 unofficial with Wifi tether enabled.

- When Wifi tether is configured with no password all attempts to connect to it are successful.

- When Wifi tether is configured with password most attempts to connect unsuccessful.

- In dozens of attempts The one successful connection was with an all lowercase password. I dont see how that could really matter but was still testing different passwords in 3 categories: 1) all lowercase 2) lowercase and uppercase, 3) lowercase, uppercase and special (@).

- One authentication failure with forced wrong password could be considered a successful attempt.

It has been difficult to establish a pattern, other than that:

- With no password for tethered wifi, it connects, and quite quickly at that.

- Where the nature of the password may not be a factor, something about the timing or order of the events could be a factor; ie, a certain action creates state in which future attempts dont work. I'm presently searching for any "resetting" events after which a successful connection can be made.

- In broad strokes this pattern of events is similar to what occurred in the CM13 tests.

I can post logs if needed, and would do the same for CM13 but have to get CM12.1 set on new device first.

[EDIT] Might be a DHCP issue. When the connecting device is configured with static IP using the IP address that was issued with unsecured connection (192.168.43.77) and gateway left at subsequent default 192.168.43.1 all attempt to connect to secured wifi tether were good through multiple password changes. When set back to DHCP the problem returns. When put back to static, OK again, although still a little quirky.

[EDIT2] I was unable to reproduce this issue in a clean flash of CM13 12/16/15 unofficial, which did not have certain 3rd party factors and did not have any connection history. After reverting to CM12.1 12/15/15 unofficial, I reproduced and logged the issue from both devices before and after removing Adaway as a factor. After removing adaway the problem did not seem to occur as often but that could be coincidental and it still had problems connecting unless set to static IP. The logs from the latter of those test are attached. In the guest device log you might see some clutter related to the MyPhoneExplorer app that I'm using to control the device via USB connection (necessary due to a cracked screen).

[EDIT3] Repeated tests and reproduced results in clean flash of Otus CM12.1 12/15 unofficial with 12/12 open gaps pico, no additional appps, no google account configuration, no previous use of wifi. Also reproduced issue in same procedure with CM13 12/16 unofficial with open Gapps Pico.

Procedural note: I wanted to keep all 3rd party apps off the device and could not log by USB which was occupied by guest device so I did not capture logs from the host device. For what it is worth; attached is a log (wifitether3GUESTtoCM12_2015-12-17-15-04-01.txt) is from guest device. Logging was initiated during a failed attempt to connect and spans change to static IP and subsequent successfully attempt to connect.