Tim, No, this isn't actually recoverable, and it isn't something that Connman should attempt to work around (I'm not even certain that a userland application could fix this issue, even if you wanted to).
What's happening here is that the Wi-Fi driver is erroneously sending data frames to the wireless AP before it's fully authenticated to the network. This is an illegal mode of operation. The Wi-Fi driver is supposed to buffer any data and hold off transmission until it's authenticated, or drop the data and let the upper layers handle retransmission (upper layers being the IP stack in the kernel, or the application layer, depending). When the wireless AP gets a data frame from an unauthenticated/unauthorized client, it's allowed to deauth it. Now, one could potentially argue that the AP should realize it has an in-progress authentication happening with that client, and it could probably safely ignore the data frames and let the auth finish and assume that the client should retransmit, but that may be a fuzzy area of the 802.11 spec - I'm honestly not sure. What I do know is that the AP is perfectly within its rights to deauthenticate a client that isn't fully associated. It's the Wi-Fi driver's responsibility to properly manage its state and not forward data frames until it has a valid association. It's also important to realize that the data frames being sent might not be due to something your application is doing - but rather, any subsystem above the driver that wants to send network traffic could trigger this. You might want to see if there's a newer version of the driver available, or a patch to fix this particular issue. On Tue, Nov 18, 2014 at 6:57 AM, Tim Tisdall <tisd...@gmail.com> wrote: > On Mon, Nov 17, 2014 at 8:48 PM, Terry Simons <terry.sim...@gmail.com> > wrote: > > > It might be a bug in your Wi-Fi driver. > > > > If the driver is trying to send data frames before it's fully > > authenticated, you'll see this happen. > > > > I've seen this with some Realtek chips in Linux before, so it's certainly > > a possibility, but not likely connman. > > > This was on Atheros hardware using the ath9k_htc driver. > > Is connman not able to recover from such an error? It seems that after > that error the device stayed dormant (with respect to making wifi > connections). > _______________________________________________ > connman mailing list > connman@connman.net > https://lists.connman.net/mailman/listinfo/connman > _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
