1. 12 Feb, 2013 6 commits
  2. 11 Feb, 2013 8 commits
    • Dan Williams's avatar
      settings: load keyfile plugin even if no plugins are given · e5f8b426
      Dan Williams authored
      If no config file was specified, and if no other plugins were given
      on the command-line, the keyfile plugin would not be loaded.  This
      meant no connections would be read, and no connections could be
      created either.
      
      Always load the keyfile plugin.
      e5f8b426
    • Dan Williams's avatar
      wifi: don't warn on unknown nl80211 ciphers · 6cba496a
      Dan Williams authored
      6cba496a
    • Dan Williams's avatar
      core: fix duplicating (not removing) active connections · aa5013cf
      Dan Williams authored
      This is a regression introduced by reworked active connections tracking:
      7258dd27 core: add the NM_ACTIVE_CONNECTION_STATE_DEACTIVATED state
      59420add core: track active connections directly in the manager
      
      Because nm-manager.c:active_connection_state_changed() postpones active
      connection removal to an idle handler (to be able to receive last property
      change notifications), we also need to ensure that NM_ACTIVE_CONNECTION_STATE_DEACTIVATED
      state is not changed again in the meantime in nm-activation-request.c:device_state_changed().
      After the NMActRequest was deactivated (which is a terminal state) it was still
      listening to state changes of its child NMDevice which could be starting a
      new activation request.  Thus the new activation's NMDevice state would cause
      the old activation request's state to change from DEACTIVATED.  To fix this
      stop listening to the child NMDevice when DEACTIVATED becuase there's no point
      to doing so anyway.
      
      Reproducer:
      Just activate already active connection by clicking it in nm-applet or
      run 'nmcli con up id <connnection name>' several times, and then check
      active connections with 'nmcli c s'.
      aa5013cf
    • Dan Williams's avatar
      Revert "core: fix duplicating (not removing) active connections" · 527cbf19
      Dan Williams authored
      This reverts commit df796527.
      
      We found the real problem.
      527cbf19
    • Dan Winship's avatar
      core: add NM_WIFI_DEVICE_CAP_ADHOC · fc700e92
      Dan Winship authored
      Some wireless devices don't support Ad-Hoc mode. Expose this fact in
      the wireless capabilities so that clients can disable the hot-spot
      option if neither CAP_ADHOC nor CAP_AP is available.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=692869
      fc700e92
    • Jiří Klimeš's avatar
      core: fix duplicating (not removing) active connections · df796527
      Jiří Klimeš authored
      This is a regression introduced by reworked active connections tracking:
      7258dd27 core: add the NM_ACTIVE_CONNECTION_STATE_DEACTIVATED state
      59420add core: track active connections directly in the manager
      
      Because nm-manager.c:active_connection_state_changed() postpones active
      connection removal to an idle handler (to be able to receive last property
      change notifications), we also need to ensure that NM_ACTIVE_CONNECTION_STATE_DEACTIVATED
      state is not changed again in the meantime in nm-activation-request.c:device_state_changed().
      
      Reproducer:
      Just activate already active connection by clicking it in nm-applet or
      run 'nmcli con up id <connnection name>' several times, and then check
      active connections with 'nmcli c s'.
      df796527
    • Jiří Klimeš's avatar
    • Jiří Klimeš's avatar
      d9c1fb17
  3. 09 Feb, 2013 6 commits
  4. 08 Feb, 2013 1 commit
  5. 07 Feb, 2013 6 commits
    • Dan Williams's avatar
      efe52765
    • Dan Williams's avatar
      todo: real AP mode support has been added · b5978575
      Dan Williams authored
      b5978575
    • Dan Williams's avatar
      core: track which interface an IP config came from · 778d1cf2
      Dan Williams authored
      Various bits of code want the network interface which an IP config
      came from, for example when distinguishing which interface to
      send DNS requests to when the DNS servers are link-local.  DNS
      plugins may also want this data for various reasons.
      
      So it makes sense to attach the interface name to the IP config
      object when the DNS manager gets it, so that later DNS updates
      that don't have any interface information (hostname changes, etc)
      can still generate correct DNS information.
      
      This also eliminates the "last_iface" hack, which was often
      inaccurate.
      
      It also now sends "NetworkManager" to SUSE netconfig as the
      interface name, because the DNS information being sent is already
      merged/prioritized and not specific to a network interface, so
      it's time to stop lying about where it came from.
      778d1cf2
    • Dan Williams's avatar
      trivial: fix spacing in AP mode message · f2b33e31
      Dan Williams authored
      f2b33e31
    • Dan Williams's avatar
      dhcp: generate DUID-UUID from /etc/machine-id (bgo #691885) · 140ebbbf
      Dan Williams authored
      DHCPv6 RFCs require the DUID to be constant over time and to
      be used as a permanent identifiers of the machine.  This precludes
      using a network interface MAC address since the MAC address may
      change, and there may be more than one network interface installed.
      
      Storing the DUID causes problems when an OS image is cloned between
      virtual or physical machines because then the saved DUID is no longer
      unique.
      
      To fix all these issues, generate the DUID from the machine's hashed
      machine-id, which is already a unique identifier of the machine and
      will always be present because dbus requires it, and NM requires
      dbus.  It is assumed administrators will change the machine-id when
      cloning an OS image; thus they only have to update one file, not
      two (machine-id and the stored DUID).
      
      Administrators may still override the machine-id-derived DUID by
      setting a DUID in the default dhclient config file or the
      interface-specific dhclient config files.
      
      dhclient no longer saves a generated DUID to the config files,
      because the default DUID will always be regenerated from
      the machine-id on startup and thus always stable.
      140ebbbf
    • Aleksander Morgado's avatar
      modem-manager: properly follow name-owner changes · 3b2556ae
      Aleksander Morgado authored
      We avoid requesting to auto-start the service when the 'MMManager' is created,
      so that we can use it to follow name-owner changes (when auto-starting
      requested the 'MMManager' creation may fail).
      
      We still handle the periodic poking to the service, but instead of re-creating
      the 'MMManager', we just call org.freedesktop.DBus.Peer.Ping().
      3b2556ae
  6. 06 Feb, 2013 3 commits
  7. 05 Feb, 2013 8 commits
  8. 04 Feb, 2013 2 commits
    • Dan Williams's avatar
      core: ensure IP interface removal doesn't remove the NMDevice · 62bae8ac
      Dan Williams authored
      Some devices (namely PPPoE (pppX), ADSL (nasX, pppX), and
      mobile broadband (pppX, bnepX)) create a kernel netdevice for IP
      communication (called the "IP interface" in NM) as part of the
      connection process and thus the IP interface lifetime does not
      correspond to the NMDevice lifetime.  For these devices we must
      ignore removal events for the IP interface name otherwise the
      NMDevice would be removed.
      
      Caused by 8cce42f2.
      
      For example, this bug caused the NMDeviceBt to be removed when
      a PAN connection's bnepX interface went down in response to a
      terminated Bluetooth connection, which of course means that
      you can't restart the PAN connection as your phone is no longer
      in the NM device list.
      62bae8ac
    • Dan Williams's avatar
      core: only manage those bridges created by NetworkManager (rh #905035) · 17338069
      Dan Williams authored
      Until we handle bridges non-destructively, only manage bridges
      created by NM.  When quitting write out a file listing all
      bridges created by NM and a timestamp, and when starting read
      that file and if the timestamp is within 30 minutes, manage
      any bridge that was listed in that file.  This scheme, while
      not foolproof (eg, if NM crashes), should ensure that NM can
      recognize bridges it created if it's restarted.  The file
      is stored in /run or /var/run, which is cleaned each restart,
      ensuring that the state does not persist across reboots.
      
      If an automatic or user-initiated activation request for
      a bridge NM does not manage is received, that request is
      denied.  Only if the bridge interface does not yet exist, or
      was present in the managed bridges file, will an
      NMDeviceBridge be created and activation be possible.
      17338069