1. 30 Jun, 2011 2 commits
  2. 29 Jun, 2011 2 commits
    • Dan Williams's avatar
      wifi: immediately request new 802.1x 'always-ask' passwords if they fail · 6187b850
      Dan Williams authored
      Instead of retrying the password a number of times, immediately fail the
      connection and ask for a new pasword if (1) the request fails during the
      802.1x authentication and (2) the password is an 'always-ask' 802.1x
      password.  The password is bad anyway, and in the case of RSA/OTP tokens
      the code may have already changed, so it's pointless to keep retrying
      the same password when it's already stale.
      6187b850
    • Dan Williams's avatar
      wifi: allow supplicant disconnect request more often · a27cd8e5
      Dan Williams authored
      Use a broader range of supplicant interface states to determine
      when to tell the supplicant to idle; we want to allow the
      disconnect in all of these states, not just some of them.
      
      Second, allow the active network to be removed from the supplicant's
      list in most of these states, even when the supplicant interface is
      inactive or disconnected.
      a27cd8e5
  3. 23 Jun, 2011 1 commit
  4. 20 Jun, 2011 3 commits
    • Dan Williams's avatar
      ifcfg-rh: fix distcheck after c2dbd1f8 · a5850e82
      Dan Williams authored
      IPV6_FAILURE_FATAL is now read and defaults to TRUE for ifcfg files
      even if IPv6 is turned off.  That means that if we write a connection
      for which NM_SETTING_IP6_CONFIG_MAY_FAIL is FALSE but IPv6 is disabled,
      ifcfg-rh won't write out IPV6_FAILURE_FATAL (because IPv6 is disabled
      so why bother writing out IPv6-related settings) but on re-read it will
      treat the absence of IPV6_FAILURE_FATAL as TRUE/yes.  This leads to
      a mismatch between the connection that was written out (which will
      have NM_SETTING_IP6_CONFIG_MAY_FAIL=FALSE and no IPV6_FAILURE_FATAL)
      and the re-read connection (which will have
      NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE since a missing IPV6_FAILURE_FATAL
      is treated as NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE).
      a5850e82
    • Dan Williams's avatar
      libnm-glib: fix make distcheck · 538cef08
      Dan Williams authored
      538cef08
    • Jorge González's avatar
      69f76d32
  5. 18 Jun, 2011 1 commit
  6. 17 Jun, 2011 1 commit
  7. 16 Jun, 2011 2 commits
  8. 15 Jun, 2011 5 commits
    • Dan Williams's avatar
      vpn: fix handling of connections with only system secrets · fb62f395
      Dan Williams authored
      The core problem was the nm_connection_need_secrets() call in
      nm-agent-manager.c's get_start() function; for VPN settings this
      always returns TRUE.  Thus if a VPN connection had only system
      secrets, when the agent manager checked if additional secrets
      were required, they would be, and agents would be asked for
      secrets they didn't have and couldn't provide.  Thus the
      connection would fail.  nm_connection_need_secrets() simply
      can't know if VPN secrets are really required because it
      doesn't know anything about the internal VPN private data;
      only the plugin itself can tell us if secrets are required.
      
      If the system secrets are sufficient we shouldn't be asking any
      agents for secrets at all.  So implement a three-step secrets
      path for VPN connections.  First we retrieve existing system
      secrets, and ask the plugin if these are sufficient.  Second we
      request both existing system secrets and existing agent secrets
      and again ask the plugin if these are sufficient.  If both those
      fail, we ask agents for new secrets.
      fb62f395
    • Jiří Klimeš's avatar
      2d461942
    • Jiří Klimeš's avatar
    • Jiří Klimeš's avatar
      core: socket() returns -1 on failure · acc3025d
      Jiří Klimeš authored
      acc3025d
    • Jiří Klimeš's avatar
      ifcfg-rh: socket() returns -1 on failure · 17bc5867
      Jiří Klimeš authored
      17bc5867
  9. 14 Jun, 2011 10 commits
  10. 13 Jun, 2011 2 commits
  11. 08 Jun, 2011 4 commits
  12. 07 Jun, 2011 4 commits
    • Dan Williams's avatar
      settings: ensure transient secrets are ignored when rereading connections (rh #703785) · 9cba854f
      Dan Williams authored
      When a connection changes on-disk, the in-memory copy of it may contain
      transient secrets (agent-owned or not saved) that dont' get written out
      to disk.  When comparing the on-disk copy to the in-memory copy make sure
      transient secrets are ignored so that we don't re-read the on-disk copy
      needlessly.
      9cba854f
    • Dan Williams's avatar
      libnm-util: add new compare flags for ignoring various types of secrets · 864db9f9
      Dan Williams authored
      It turns out we need a way to ignore transient (agent-owned or unsaved)
      secrets during connection comparison.  For example, if the user is
      connecting to a network where the password is not saved, other
      changes could trigger a writeout of that connection to disk when
      connecting, which would the connection back in due to inotify, and the
      re-read connection would then no longer be recognized as the same as
      the in-memory connection due to the transient secret which obviously
      wasn't read in from disk.
      
      Adding these compare flags allows the code to not bother writing the
      connection out to disk when the only difference between the on-disk
      and in-memory connections are secrets that shouldn't get written to
      disk anyway.
      864db9f9
    • Dan Williams's avatar
      core: simplify device activation precheck · a2acfdd4
      Dan Williams authored
      The FIXME is correct; comparing the whole connection is just dumb now
      since all connections are owned by NM, so we can simply compare pointers
      to figure out of the incoming activation request is using the same
      connection as the current activation request.  Plus, this comparison
      would fail entirely if the connection has transient/always-ask secrets.
      a2acfdd4
    • Dan Williams's avatar
      core: more BT device removed log message less noisy · f1329b48
      Dan Williams authored
      Don't log when any BT device is removed, just log when a device
      we actually care about is removed.
      f1329b48
  13. 06 Jun, 2011 3 commits