SSID Broadcast As Unsecure

[kion7]

When I initially setup my Tetra everything worked fine but now I seem to be having 2 issues that are probably related.

1) I now notice that when the spoofed SSIDs are broadcast that they show up with the exclamation point and registers as unsecure (on Windows) in the Network Manager.
   The spoofed SSIDs don't show up at all on my android and I have not tested it on Mac or Linux. Any ideas on why this may be and how I can change it?
2) The next thing is that clients no longer associate after deauthentication. The broadcast APs have to be manually selected in order to connect. I suspect this
   is because the APs are showing up as unsecure and therefore the clients just reconnect to the original AP even after deauth packets are sent.

All clients and SSIDs have been added to Filtering with both in Allow Mode. I have increased both the Beacon Response & Broadcast SSID Pool Interval to aggressive with the same results. I also have shutdown, restarted and reset the Tetra a couple of times. I am running Kali with the Tetra connected by Y cable.

Any ideas what's going on?

[Mr-Protocol]

The exclamation point is any network without security enabled.

If the clients don't connect to your pineapple, they may not be close enough or are configuring to the "Secure" network priority over the open networks.

[Skinny]

As far as question #1 with your Android, I've noticed something similar.  Here is an example regarding the conditions that cause a similar behavior.

First, I use my android device to connect to an access point called GOODGRAVY with WPA2 security. Next, I kill that access point and bring up the pineapple using the same SSID. The android device will not show that it sees the pineapple because in its list of approved SSIDs, it sees an access point already called GOODGRAVY. Furthermore, the legitimate access point required a password, whereas the new one does not. If I tell my android device to forget the first access point (the legitimate one), then it will see the pineapple beaconing out the unsecure version(s).

I believe you are correct regarding your assumption for question #2. If you are trying to deauth clients from a secure network and then get them to reconnect to you via an unsecure connection, you may have issues. WPA2 encryption is implemented so that both the client and the AP can verify the legitimacy of each other via a 4-way handshake. Your clients may not be seeing your spoofed AP as legitimate because it can't participate in this process as the clients expect. 

Past this point is where my knowledge abruptly ends. I think someone mentioned on this forum that if you capture that 4-way handshake and crack the password, there might be a way to get the pineapple to legitimize itself to a client using the APs credentials.