On Tue, 2007-11-20 at 15:05 +0100, Christopher Aillon wrote: > On 11/20/2007 02:33 PM, Jesse Keating wrote: > > On Tue, 20 Nov 2007 14:30:37 +0100 > > Christopher Aillon <caillon@xxxxxxxxxx> wrote: > > > >> What really should be happening is NM should notice there is a > >> new/different encryption scheme and offer to let you enter it. You > >> shouldn't have to force it. If this is not happening, file a bug. > > > > After talking to Dan, often it is impossible to tell. All we can do is > > fail to associate with the old method, and then popup a box to allow > > you to pick a different auth method. If all the auth methods aren't > > available in that popup, /that/ would be a bug. Jesse's only partially right, actually... He's talking about WEP auth modes, which cannot be distinguished. With WPA though, the AP broadcasts and Information Element telling what capabilities it supports (thankfully somebody had a clue). So we can tell between WEP and not-WEP [1]. When connecting to an AP that's changed properties, the APs current properties should override the properties of the stored connection details. If they don't, it's a bug. But it's also true that changing the capabilities on the fly isn't as well tested as connecting to them in the first place, mainly because people connect to APs much more often than they switch their APs settings. So I call bug. Dan [1] though we cannot tell when Enterprise class APs support _both_ WEP and WPA at the same time, but the user only wants to use WEP or only has a WEP-capable card. Some APs only broadcast the WPA-TKIP capability but accept WEP connections as well as a backwards compat measure. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list