Problem with changing encryption for established connection

[Larry Finger]

I am using NetworkManager version 0.7.1 and kNM version 0.9. While
testing openSUSE 11.2 RC1, I did the unusual step of changing the
encryption scheme for a previously established ESSID/connection. As
expected, when I clicked on the entry in the kNM applet to connect, I
got the authentication/secrets pop-up. Supplying the new, correct
password and authentication scheme failed. I could connect only by
using the "Manage Connections" item from the applet and by editing the
wireless connection item before trying to connect.

Is this expected behavior?

Thanks,

Larry
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Thu, 2009-10-22 at 10:45 -0500, Larry Finger wrote:

> I am using NetworkManager version 0.7.1 and kNM version 0.9. While
> testing openSUSE 11.2 RC1, I did the unusual step of changing the
> encryption scheme for a previously established ESSID/connection. As
> expected, when I clicked on the entry in the kNM applet to connect, I
> got the authentication/secrets pop-up. Supplying the new, correct
> password and authentication scheme failed. I could connect only by
> using the "Manage Connections" item from the applet and by editing the
> wireless connection item before trying to connect.
>
> Is this expected behavior?

It might be the case that the AP's old encryption settings were still in
the scan list; How long was the AP powered off before it came back up
with the new settings?  Can you reproduce the situation and run
'nm-tool' to check what NM thinks the AP's settings are and make sure
that NM reflects what they really are?  If not, it's likely a stale
entry in NM's scan cache.

I'd expect to see the passphrase dialog if you change the passphrase on
the AP and not the security settings; if you switch between WEP and WPA
for example then you might also see that dialog, but NM might also be a
bit confused.

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

On Saturday 24 October 2009 00:53:16 Dan Williams wrote:

> On Thu, 2009-10-22 at 10:45 -0500, Larry Finger wrote:
> > I am using NetworkManager version 0.7.1 and kNM version 0.9. While
> > testing openSUSE 11.2 RC1, I did the unusual step of changing the
> > encryption scheme for a previously established ESSID/connection. As
> > expected, when I clicked on the entry in the kNM applet to connect, I
> > got the authentication/secrets pop-up. Supplying the new, correct
> > password and authentication scheme failed. I could connect only by
> > using the "Manage Connections" item from the applet and by editing the
> > wireless connection item before trying to connect.
> >
> > Is this expected behavior?
>
> It might be the case that the AP's old encryption settings were still in
> the scan list; How long was the AP powered off before it came back up
> with the new settings?  Can you reproduce the situation and run
> 'nm-tool' to check what NM thinks the AP's settings are and make sure
> that NM reflects what they really are?  If not, it's likely a stale
> entry in NM's scan cache.
>
> I'd expect to see the passphrase dialog if you change the passphrase on
> the AP and not the security settings; if you switch between WEP and WPA
> for example then you might also see that dialog, but NM might also be a
> bit confused.

Agreed, but Larry might also have mis-entered the encryption type on first
creating the connection and be trying to edit it in the GetSecrets popup.  I
show the whole settings group's UI on GetSecrets because I haven't got round
to making a minimal secrets-only UI yet, and I doubt NM is equipped to handle
the non-secret parts of 802-11-wireless changing at that point.

Will
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Larry Finger]

On 10/24/2009 04:15 AM, Will Stephenson wrote:

> On Saturday 24 October 2009 00:53:16 Dan Williams wrote:
>> On Thu, 2009-10-22 at 10:45 -0500, Larry Finger wrote:
>>> I am using NetworkManager version 0.7.1 and kNM version 0.9. While
>>> testing openSUSE 11.2 RC1, I did the unusual step of changing the
>>> encryption scheme for a previously established ESSID/connection. As
>>> expected, when I clicked on the entry in the kNM applet to connect, I
>>> got the authentication/secrets pop-up. Supplying the new, correct
>>> password and authentication scheme failed. I could connect only by
>>> using the "Manage Connections" item from the applet and by editing the
>>> wireless connection item before trying to connect.
>>>
>>> Is this expected behavior?
>>
>> It might be the case that the AP's old encryption settings were still in
>> the scan list; How long was the AP powered off before it came back up
>> with the new settings?  Can you reproduce the situation and run
>> 'nm-tool' to check what NM thinks the AP's settings are and make sure
>> that NM reflects what they really are?  If not, it's likely a stale
>> entry in NM's scan cache.
>>
>> I'd expect to see the passphrase dialog if you change the passphrase on
>> the AP and not the security settings; if you switch between WEP and WPA
>> for example then you might also see that dialog, but NM might also be a
>> bit confused.
>
> Agreed, but Larry might also have mis-entered the encryption type on first
> creating the connection and be trying to edit it in the GetSecrets popup.  I
> show the whole settings group's UI on GetSecrets because I haven't got round
> to making a minimal secrets-only UI yet, and I doubt NM is equipped to handle
> the non-secret parts of 802-11-wireless changing at that point.

I think changing the type after the connection was created would match
the situation you describe, and that is what happened. The original
connection was WPA2, then I used a wired connection to modify the
encryption in the AP. Next I tried to connect using that same
connection. A similar switch was later made to WEP, and finally to no
encryption. As I recall, the problem happened in the WPA2 => WPA
switch, but I'm not completely certain of that. Once I found that I
needed to edit the connection, I did that for the rest of the testing.

As this kind of type changing using the same ESSID is not usual
behavior, I have not filed a bug report, just this question on the ML.

Larry
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Sat, 2009-10-24 at 11:15 +0200, Will Stephenson wrote:

> On Saturday 24 October 2009 00:53:16 Dan Williams wrote:
> > On Thu, 2009-10-22 at 10:45 -0500, Larry Finger wrote:
> > > I am using NetworkManager version 0.7.1 and kNM version 0.9. While
> > > testing openSUSE 11.2 RC1, I did the unusual step of changing the
> > > encryption scheme for a previously established ESSID/connection. As
> > > expected, when I clicked on the entry in the kNM applet to connect, I
> > > got the authentication/secrets pop-up. Supplying the new, correct
> > > password and authentication scheme failed. I could connect only by
> > > using the "Manage Connections" item from the applet and by editing the
> > > wireless connection item before trying to connect.
> > >
> > > Is this expected behavior?
> >
> > It might be the case that the AP's old encryption settings were still in
> > the scan list; How long was the AP powered off before it came back up
> > with the new settings?  Can you reproduce the situation and run
> > 'nm-tool' to check what NM thinks the AP's settings are and make sure
> > that NM reflects what they really are?  If not, it's likely a stale
> > entry in NM's scan cache.
> >
> > I'd expect to see the passphrase dialog if you change the passphrase on
> > the AP and not the security settings; if you switch between WEP and WPA
> > for example then you might also see that dialog, but NM might also be a
> > bit confused.
>
> Agreed, but Larry might also have mis-entered the encryption type on first
> creating the connection and be trying to edit it in the GetSecrets popup.  I
> show the whole settings group's UI on GetSecrets because I haven't got round
> to making a minimal secrets-only UI yet, and I doubt NM is equipped to handle
> the non-secret parts of 802-11-wireless changing at that point.

I made that work at one point, so that if you did switch from WEP to WPA
it would just ask and you send the new settings.  But at some point I
think that became obsolete, because NM won't even try to connect to your
AP if the connection is WEP, but the AP is WPA; this filtering was
requested mainly for people with 'linksys' default-ssid APs where say
their neighbor was running one with WEP + 'linksys', but the one they
connected to was WPA or something.

In truth we could be smarter about this by detecting the saved BSSID or
something; if no other connection is appropriate for the AP, but you
have a non-matching connection with a scanned AP's BSSID, then maybe we
start that connection and ask for secrets, and allow NM's GetSecrets
response to update the whole 'security' and '8021x' settings.

But that might also be *too* smart.  In the end, I think we play it safe
and if you change the encryption on your AP, you get to pick it from the
menu again.  If you just change the password, NM should eventually let
you know that it can't connect and offer you some way to change the
password, but it shouldn't pop up the interrupt-me-immediately dialog.

Dan




_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Graham Lyon]

2009/10/26 Dan Williams <dcbw@...>

I made that work at one point, so that if you did switch from WEP to WPA

it would just ask and you send the new settings.  But at some point I
think that became obsolete, because NM won't even try to connect to your
AP if the connection is WEP, but the AP is WPA; this filtering was
requested mainly for people with 'linksys' default-ssid APs where say
their neighbor was running one with WEP + 'linksys', but the one they
connected to was WPA or something.

I'm curious about this. Are people with that model of router simply unable to change their SSID then? If not, surely if their neighbor's SSID is the same as theirs and this is causing them issues then the correct course of action would be to change their SSID and not cause everyone to lose what I personally think is an essential piece of functionality. Changing of encryption methods is actually quite common (no, I'm not saying it's done every day but it's certainly not unexpected behavior).   

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Sat, 2009-10-31 at 13:09 +0000, Graham Lyon wrote:

> 2009/10/26 Dan Williams <dcbw@...>
>        
>         I made that work at one point, so that if you did switch from
>         WEP to WPA
>         it would just ask and you send the new settings.  But at some
>         point I
>         think that became obsolete, because NM won't even try to
>         connect to your
>         AP if the connection is WEP, but the AP is WPA; this filtering
>         was
>         requested mainly for people with 'linksys' default-ssid APs
>         where say
>         their neighbor was running one with WEP + 'linksys', but the
>         one they
>         connected to was WPA or something.
>
>
> I'm curious about this. Are people with that model of router simply
> unable to change their SSID then? If not, surely if their neighbor's
> SSID is the same as theirs and this is causing them issues then the
> correct course of action would be to change their SSID and not cause
> everyone to lose what I personally think is an essential piece of
> functionality. Changing of encryption methods is actually quite common
> (no, I'm not saying it's done every day but it's certainly not
> unexpected behavior).

I believe there are some vendors where you can't change the SSID, or
where you aren't given access to the web interface to reconfigure.
These are mainly specific ISP devices that the ISP locks down and sends
out with "self-install" kits or whatever.

The other complication is APs that use the same BSSID but two different
SSIDs, which some Cisco devices do.  There's a "public" network that
broadcasts its SSID, and a private network with encryption that's hidden
and does not broadcast the SSID.  The same BSSID is used for both, but
they have different security settings.

Thus, we'd have to check the scan list before popping up that dialog
(asking for new security settings) to ensure that there was only one
other AP with that BSSID, ie the new one with new security.

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[代尔欣]

Hi all,
   I ever met this problem and test with my own router such as changing the ssid after connection established or changing the encryption. I know this rarely happen in the actually use.
case 1:
Connect to AP "a" with wpa encrption. Then change encrption to WEP.
After changing, wait a while, then I see the connection disconnect from AP "a". If have other wireless profile, NM will try to connect(But not AP "a"). Click on applet, I will see 2 AP named with "a" in the AP list. One can connect. Another can not connect of course. After about 6 minutes, the old AP "a" disappear from the ap list. I know NM will remove the AP if it can't be found in 3 scan cycles(MAX interval is 120 seconds). But for this case, I think the 2 same AP may make user confused, if it click on the wrong one, it never connect. It better we just show one AP "a" and notify user the AP already changed.

case 2:
Connect to AP "a" with wpa encrption. Then change the AP name to "b".
After changing, wait a while, same as case 1, then I see the connection disconnect from AP "a". If have other wireless profile, NM will try to connect(But not AP "a"). Click on applet, I will see both "a" and "b" in the ap list. After about 6 minutes, "a" is disappeared. This case more confused user than case 1. User will never connect to "a"(Because they do not know "a" already changed to "b").

For both case, I think it better remove the changed AP immediately(if we can) and give a notify to user.

2009/11/3 Dan Williams <dcbw@...>

On Sat, 2009-10-31 at 13:09 +0000, Graham Lyon wrote:
> 2009/10/26 Dan Williams <dcbw@...>
>
>         I made that work at one point, so that if you did switch from
>         WEP to WPA
>         it would just ask and you send the new settings.  But at some
>         point I
>         think that became obsolete, because NM won't even try to
>         connect to your
>         AP if the connection is WEP, but the AP is WPA; this filtering
>         was
>         requested mainly for people with 'linksys' default-ssid APs
>         where say
>         their neighbor was running one with WEP + 'linksys', but the
>         one they
>         connected to was WPA or something.
>
>
> I'm curious about this. Are people with that model of router simply
> unable to change their SSID then? If not, surely if their neighbor's
> SSID is the same as theirs and this is causing them issues then the
> correct course of action would be to change their SSID and not cause
> everyone to lose what I personally think is an essential piece of
> functionality. Changing of encryption methods is actually quite common
> (no, I'm not saying it's done every day but it's certainly not
> unexpected behavior).

I believe there are some vendors where you can't change the SSID, or
where you aren't given access to the web interface to reconfigure.
These are mainly specific ISP devices that the ISP locks down and sends
out with "self-install" kits or whatever.

The other complication is APs that use the same BSSID but two different
SSIDs, which some Cisco devices do.  There's a "public" network that
broadcasts its SSID, and a private network with encryption that's hidden
and does not broadcast the SSID.  The same BSSID is used for both, but
they have different security settings.

Thus, we'd have to check the scan list before popping up that dialog
(asking for new security settings) to ensure that there was only one
other AP with that BSSID, ie the new one with new security.

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list