Opened 14 years ago

Last modified 10 years ago

#1674 assigned defect

change of encryption requirement on an access point prevents network connection

Reported by: quozl Owned by:
Priority: Low Milestone: Unspecified
Component: Sugar Version: 0.84.x
Severity: Minor Keywords:
Cc: Distribution/OS:
Bug Status: Unconfirmed

Description

Sugar continues to prompt for an encryption key when connecting to an access point that has had the encryption requirement removed.

This has not yet been verified in Sugar after 0.84.

Relates to #1673 as this was a previous workaround.

Current workaround is to remove nm/connections.cfg and restart Sugar.

From dev.laptop.org 9977 (AP association failure after removing encryption).

Change History (14)

comment:1 Changed 14 years ago by tomeu

Why "r?"? Forgot to attach patch?

comment:2 Changed 14 years ago by quozl

  • Keywords r? removed

comment:3 follow-up: Changed 14 years ago by quozl

In the situation where a key dialog appears after an access point has been opened (changed from WEP to open), this occurs because NetworkManager calls the GetSecrets method in the Sugar Shell.

comment:4 Changed 14 years ago by quozl

A patch on laptop.org 9977 improves the situation significantly, but still doesn't fix the reported symptom of this ticket "Sugar continues to prompt for an encryption key when connecting to an access point that has had the encryption requirement removed."

comment:5 in reply to: ↑ 3 ; follow-up: Changed 14 years ago by sascha_silbe

Replying to quozl:

In the situation where a key dialog appears after an access point has been opened (changed from WEP to open), this occurs because NetworkManager calls the GetSecrets method in the Sugar Shell.

Does this mean it is actually a NetworkManager bug, not Sugars fault? If so, do you know if a ticket has been filed upstream?

comment:6 in reply to: ↑ 5 Changed 14 years ago by quozl

Replying to sascha_silbe:

Does this mean it is actually a NetworkManager bug, not Sugars fault?

It may mean that, but I've not enough evidence yet to draw that conclusion. It might also be that Sugar is causing the GetSecrets method to be called.

It is a problem with either NetworkManager or Sugar, or interoperability between them.

If so, do you know if a ticket has been filed upstream?

I'm not aware of any upstream ticket that relates.

comment:7 Changed 14 years ago by quozl

Related to #1806. Only just discovered the relationship today. There are NetworkManager tickets mentioned.

comment:8 Changed 14 years ago by quozl

Sugar had not informed NetworkManager that the connection should not be retried, which is why the GetSecrets happens again.

comment:9 Changed 14 years ago by quozl

  • Owner changed from tomeu to quozl
  • Status changed from new to assigned

Patch relative to 0.84 posted to sugar-devel for review.

comment:10 Changed 13 years ago by quozl

  • Owner quozl deleted

comment:11 Changed 13 years ago by sascha_silbe

  • Bug Status changed from Unconfirmed to New
  • Distribution/OS OLPC deleted
  • Severity changed from Unspecified to Minor

Just tried this on current git master with some of Quozls network patches applied (but not the one mentioned above). After changing the access point from WEP to open, the following behaviour can be observed:

  1. The wifi LED turns off (indicating no connection to AP), but the old icon still has the "connected" badge.
  2. The wifi LED blinks a few times (indicating scanning).
  3. A new icon with a color different from the old icon, but with a "favourite star" badge appears.
  4. After some time the old icon looses the "connected" badge and starts pulsing.
  5. The key dialog appears, asking for WEP credentials.
  6. After cancelling the dialog, the old icon stops pulsing, but still shows the "favourite star" badge.
  7. After clicking the new icon, the old icon starts pulsing.
  8. The key dialog appears, asking for WEP credentials.

Analysis:

The reason for showing a new icon probably is that jarabe.model.network.AccessPoint.network_hash() returns a different hash for networks with the same SSID, but different security settings. This seems to be on purpose.

For connecting to the network, however, jarabe.desktop.networkviews.WirelessNetworkView._connect() looks up the connection from the Sugar-side NetworkManager User Settings service using only the SSID:

    def _connect(self):
        connection = network.find_connection_by_ssid(self._name)
        if connection is None:
          [create connection object, add it to User Settings service]
[...]

This will yield the old "connection" instance, including security settings. NetworkManager obediently tries to connect using WEP and fails.

comment:12 Changed 13 years ago by quozl

Yes, I know. My patch explained and fixed this, at the cost of removing backward compatibility with previous saved passphrases. However, I withdrew those patches once it became clear that the rework would be too complex. You may be able to figure out a partial or incremental solution.

comment:13 Changed 11 years ago by dnarvaez

  • Bug Status changed from New to Unconfirmed

comment:14 Changed 10 years ago by tch

  • Priority changed from Unspecified by Maintainer to Low

This bug is still present in Sugar 0.101.6. Even though you can see the unsecured network as different icon in neighborhood view, sugar still tries to connect to the previous secured one.

Note: See TracTickets for help on using tickets.