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(_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
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