When you change the password on the AP side, does the AP reboot?  Can you grab mark the place in 'dmesg' output right before you change the password, then change it, and then provide the subsequent 'dmesg' output from that machine?

The issue here is that we need to verify that when you change the AP password that it disconnects wifi clients, or that wifi clients are required to rekey with the new password.

That *should* look like the AP disconnected you, and NM should try to reconnect.  If you're using WPA, then NM should ask for a new password, otherwise the connection might simply fail if you're using WEP since it's not really possible to detect changed password with WEP until DHCP times out.

Also, if you could get some wpa_supplicant -dddt debug logs and perhaps mark the time when you hit "OK" on the AP's admin interface that would be great too.

http://live.gnome.org/NetworkManager/Debugging

will try both WEP and WPA .. but I used WEP for original testing. So you are saying that there is no way to determine that AP is not alive in that case? There should be some beacons or similar synchronization communication between ap and client. Can this be used?

will attach logs when I get back home

WEP used via MSI RG60 wireless router

# vvv this happened after I disconnected ap's power supply which was recognized
No probe response from AP 00:13:d3:7f:54:cf after 500ms, disconnecting.

Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: deauthenticating from 00:13:d3:7f:54:cf by local choice (reason=3)

# vvv new authentication here after reconnecting power supply
wlan0: direct probe to AP 00:13:d3:7f:54:cf (try 1)
wlan0: direct probe responded
wlan0: authenticate with AP 00:13:d3:7f:54:cf (try 1)
wlan0: authenticated
wlan0: associate with AP 00:13:d3:7f:54:cf (try 1)
wlan0: RX AssocResp from 00:13:d3:7f:54:cf (capab=0x431 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present

# somewhere here was password changed and ap rebooted

# vvv ethernet connected
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

no other changes in about 5 more minutes ..

and with WPA it works well.. 

it asks after a while for new password.

isn't there a way how to recognize that ap went down?

maybe something like that? vvv
No probe response from AP 00:13:d3:7f:54:cf after 500ms, disconnecting.

It works well with WPA because the AP and the client rekey periodically, and that rekey will fail, prompting for the new password.

With WEP, there is no rekeying, and thus the only way you know of the password change is if (a) the AP kicks everyone off when changing the key, which doesn't seem to be happening here, or (b) your DHCP renew times out.

That's a limitation of WEP.  So if NM doesn't ask for a password after DHCP times out the renew, then there's a bug here somewhere.  But there's no way to tell about the wrong password if you change the key on the AP in the middle of the lease.

That of course means that static IP configurations with WEP will *never* figure out the password changed until they reconnect.

The "No probe response" doesn't mean that the key changed; it means the AP isn't responding to probe requests.  That doesn't actually have anything to do with encryption since the management frames (which probe requests are a class of) are not encrypted.  If the stack can't probe the AP, then it should be sending a disconnect event  to wpa_supplicant, which will try to reconnect to the AP automatically.  But with WEP, that reconnection *does not* require the WEP key to be correct.  So if you have a valid DHCP lease already, and wpa_supplicant is able to reassociate to the AP within NM's timeout period, then you may be trying to talk to the AP with an invalid key.  That's just a limitation of WEP.

If you use WEP Shared Key authentication on the AP then we can detect an invalid WEP key at association/reassociation time, but Shared Key is actually less secure than Open System and thus shouldn't be used.  WEP is just screwed here.

So with all that in mind, should we close this bug and open a new bug if NM doesn't ask for the password when DHCP fails to renew?

Yeah, as reported, this is not a bug in NetworkManager, but a limitation of WEP.  So, I'm closing this, but if NetworkManager does not ask for a password when renewing a DHCP lease after changes occur, then please open a separate bug.