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
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.
On Wed, Jul 12, 2017 at 10:34 AM, Randy Bush <randy(_at_)psg(_dot_)com> 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
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.