Opened 14 years ago

Last modified 10 years ago

#1882 new defect

cannot connect to wireless network after restarting NetworkManager

Reported by: sascha_silbe Owned by: tomeu
Priority: Low Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Major Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

After restarting NetworkManager (because it died after resume - a separate bug), I cannot connect to my AP anymore. On the Sugar side, there are no error messages - it just silently fails (without pulsing). In syslog, NetworkManager says:

Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  (eth0): device state change: 4 -> 5 (reason 0)
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0/wireless): access point 'Auto Sinus W 500V' has security, but secrets are required.
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  (eth0): device state change: 5 -> 6 (reason 0)
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  (eth0): device state change: 6 -> 9 (reason 7)
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) failed for access point (Sinus W 500V)
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Marking connection 'Auto Sinus W 500V' invalid.
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  Activation (eth0) failed.
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  (eth0): device state change: 9 -> 3 (reason 0)
Mar 31 17:33:43 xo-sascha NetworkManager: <info>  (eth0): deactivating device (reason: 0).
Mar 31 17:33:55 xo-sascha NetworkManager: <info>  Activation (msh0) starting connection 'olpc-mesh-1'

Restarting Sugar doesn't help; a reboot is required.

The log for a successfull attempt differs after the "5 -> 6" state change and "Stage 2 of 5 (Device Configure) complete" (maybe because Sugar sent the required secrets?):

Mar 31 18:22:09 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Mar 31 18:22:10 xo-sascha NetworkManager: <WARN>  secrets_update_setting(): Failed to update connection secrets: 2 ssid
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  (eth0): device state change: 6 -> 4 (reason 0)
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  (eth0): device state change: 4 -> 5 (reason 0)
Mar 31 18:22:10 xo-sascha NetworkManager: <info>  Activation (eth0/wireless): connection 'Auto Sinus W 500V' has security, and secrets exist.  No new secrets needed.

Change History (3)

comment:1 Changed 11 years ago by dnarvaez

  • Milestone changed from 0.88.x to Unspecified

comment:2 Changed 11 years ago by dnarvaez

  • Bug Status changed from New to Unconfirmed

comment:3 Changed 10 years ago by tch

  • Priority changed from Unspecified by Maintainer to Low

This is still present in Sugar 0.101.6 (tested with 34003xx4 from Australia). Even though a little different behavior.

Steps to reproduce (pretty restart):

  1. in sugar neighborhood view, connect to AP.
  2. in terminal, $sudo service NetworkManager restart.
  3. during the restart, AP icons disappear from neighborhood view.
  4. once NetworkManager is back, the AP icons are visible again
  5. at this point, sugar autoconnect to the AP properly (ie., try ping, browse, etc).
  6. BUT, if you explicitly disconnect from the AP, clicking on disconnect option, you can no longer connect to the AP.

Steps to reproduce (ugly restart):

  1. in sugar neighborhood view, connect to AP.
  2. in terminal, $sudo killall NetworkManager.
  3. during the restart, AP icons disappear from neighborhood view.
  4. in terminal, $sudo service NetworkManager start.
  5. at this point, sugar autoconnect to the AP properly (ie., try ping, browse, etc).
  6. 6. BUT, if you explicitly disconnect from the AP, clicking on disconnect option, you can no longer connect to the AP.

The same happens in both cases.

I wonder if using NM bindings would make any difference.

Note: See TracTickets for help on using tickets.