>From time to time, my devices fail to bind adequately to the secure SSID. When that happens, I find the unsecured one works. Perhaps simpler logic, perhaps different codepaths? I don't know. I observe that it works more often than not. So, I use it opportunistically, as a function of unknown failures in cryptographically secured SSD binding logic, as exposed in OSX and Android. I don't use it by preference: I use it as a fallback. When the SSID binding is fine, the DHCP/DHCPv6/slaac is all a subsequent issue. I do still find that from time to time, the WiFi decides not to have a default router. If you tcpdump your WiFi the typical view at these times, is a million IETF people sending ARP. I like to imagine the NOC looks like a herd of kittens with a large ball of wool, desperately searching for an end, while simultaneously biting each others tails. -George On Wed, Jul 12, 2017 at 10:34 AM, Randy Bush <randy@xxxxxxx> wrote: > the noc sees a quite large number of associations to the unencrypted > ietf-legacy ssid as opposed to say the encrypted ietf ssid > > some of us are wondering if those using ietf-legacy > > o do not realize it is completely unencrypted over the air, or > > o don't care as their threat model sees runnin' nekkid over the air as > not a significant additional weakness, or > > o believe that they are using sufficient encryption at higher layers > to meet their needs, or > > o other > > these days, some meetings do not provide unencrypted wifi at all and > seem not to get complaints. maybe their attendees are just geekier > and/or more security conscious. > > clue bat, please. unicast responses accepted too. > > randy >