1. 26 Feb, 2013 4 commits
  2. 25 Feb, 2013 1 commit
  3. 22 Feb, 2013 5 commits
  4. 20 Feb, 2013 4 commits
  5. 19 Feb, 2013 2 commits
  6. 18 Feb, 2013 5 commits
  7. 15 Feb, 2013 4 commits
  8. 14 Feb, 2013 8 commits
  9. 13 Feb, 2013 5 commits
  10. 12 Feb, 2013 2 commits
    • Dan Williams's avatar
      wifi: ensure new supplicant is noticed if previous one quit quickly · 3a2e6de0
      Dan Williams authored
      If the Wifi device hadn't yet had a chance to transition away from
      UNAVAILALBLE before the supplicant quit, the NMSupplicantInterface
      would not be re-acquired becuase that was only happening from
      the device state change handler when entering the UNAVAILALBE state,
      and clearly setting the same state is NOP.
      
      Since the old supplicant interface was torn down, and the wifi device
      hadn't created a new supplicant interface (because it hadn't changed
      state) nothing was listening for the supplicant to appear.
      
      Fix that by ensuring that the wifi device reacquires a supplicant
      interface whenever an old one is torn down and the device is enabled.
      
      NetworkManager[3062]: <info> (wlan0): supplicant interface state: scanning -> down
      NetworkManager[3062]: <info> (wlan0): device state change: config -> unavailable (reason 'supplicant-failed') [50 20 10]
      NetworkManager[3062]: <info> (wlan0): deactivating device (reason 'supplicant-failed') [10]
      NetworkManager[3062]: <info> wpa_supplicant started
      NetworkManager[3062]: <info> wpa_supplicant stopped
      NetworkManager[3062]: <info> (wlan0): supplicant interface state: starting -> down
      <start new supplicant, nothing happens>
      3a2e6de0
    • Dan Williams's avatar
      core: remove unused SIGUSR1 handling · 4973da78
      Dan Williams authored
      4973da78