1. 12 Mar, 2014 1 commit
  2. 04 Mar, 2014 1 commit
  3. 03 Mar, 2014 2 commits
    • Dan Williams's avatar
      core: consolidate auto-activation recheck signals · 493bbbeb
      Dan Williams authored
      Add a generic signal that devices can use to indicate that something
      material in the network situation changed, and that auto-activation
      may now be possible.  This reduces specific knowledge of device types
      in the policy.
      493bbbeb
    • Dan Williams's avatar
      core: add nm_connection_provider_get() · fd3fe220
      Dan Williams authored
      In reality the connection provider (NMSettings) is always the same
      object, and some device plugins need access to it.  Instead of
      cluttering up the device plugin API by passing the provider into
      every plugin regardless of whether the plugin needs it, create
      a getter function.
      fd3fe220
  4. 31 Jan, 2014 1 commit
  5. 30 Jan, 2014 3 commits
  6. 23 Jan, 2014 4 commits
  7. 20 Dec, 2013 1 commit
  8. 13 Dec, 2013 1 commit
    • Thomas Haller's avatar
      core: reorder statements when creating fake AP in NMDeviceWifi:act_stage1_prepare · 8fe613b4
      Thomas Haller authored
      
      
      A fake AP should be the current access point. The code in act_stage1_prepare
      violated this invariant for a short time by emitting signals before
      setting current_ap. Reorder statements, so that
        - fake AP gets created and added to ap_list
        - fake AP gets set as current_ap (suppressing notify signals)
        - emit ACCESS_POINT_ADDED signal
        - thaw notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT signal
      
      When performing a series of actions that emit several signals, it is
      often difficult to emit them in an order, so that listeners get a
      consistent view. With this change, listeners will get ACCESS_POINT_ADDED
      signal, and the current ap already being set to the fake_ap. Next they
      get notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT. There is no perfect
      solution, but this way it makes slightly more sense.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      8fe613b4
  9. 12 Dec, 2013 5 commits
  10. 13 Nov, 2013 1 commit
  11. 08 Nov, 2013 1 commit
  12. 31 Oct, 2013 2 commits
  13. 25 Oct, 2013 1 commit
  14. 19 Oct, 2013 1 commit
  15. 14 Oct, 2013 1 commit
    • Dan Winship's avatar
      core: don't have IP4 and IP6 configs on slaves · f03635e5
      Dan Winship authored
      Although it's convenient in some places to have IP configs on all
      connections, it makes more sense in other places to not have IP
      configs on slaves. (eg, it's confusing for nmcli, etc, to report a
      full NMSettingIP4Config on a slave device). So revert parts of the
      earlier patch. However, it's still safe to assume that s_ip4 != NULL
      if method != DISABLED, so some of the earlier simplifications can
      stay.
      
      Also, add nm_utils_get_ip_config_method(), which returns the correct
      IP config method for a connection, whether the connection has IP4 and
      IP6 settings objects or not, and use that to keep some more of the
      simplifications from the earlier patch.
      f03635e5
  16. 11 Oct, 2013 1 commit
    • Dan Winship's avatar
      settings: make connections always have s_ip4 and s_ip6 · 68f12b4e
      Dan Winship authored
      Make sure that all connections returned from NMSettings or created via
      AddAndActivateConnection have an NMSettingIP4Config and an
      NMSettingIP6Config, with non-NULL methods, and get rid of
      now-unnecessary checks for those.
      
      Also move the slaves-can't-have-IP-config checks into the
      platform-independent code as well. This also gets rid of spurious
      "ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
      slave ifcfg file.
      
      Partly based on a patch from Pavel.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=708875
      68f12b4e
  17. 12 Sep, 2013 2 commits
  18. 02 Sep, 2013 1 commit
  19. 30 Aug, 2013 1 commit
    • Thomas Haller's avatar
      fix: nm-device-wifi disconnect signal from supplicatant.iface==NULL · f218f919
      Thomas Haller authored
      This fixes a glib assertion.
      
      Backtrace:
       #0  0x00007f139ab08e0d in g_logv () from /lib64/libglib-2.0.so.0
       #1  0x00007f139ab08ff2 in g_log () from /lib64/libglib-2.0.so.0
       #2  0x0000003f9aa3151a in g_type_check_instance () from /lib64/libgobject-2.0.so.0
       #3  0x0000003f9aa272d4 in g_signal_handlers_disconnect_matched () from /lib64/libgobject-2.0.so.0
       #4  0x0000000000495b7d in supplicant_interface_release (self=0xc58040) at devices/nm-device-wifi.c:423
       #5  0x0000000000498a28 in dispose (object=0xc58040) at devices/nm-device-wifi.c:3525
       #6  0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
       #7  0x000000000047699a in remove_device (manager=manager@entry=0xc09050, device=0xc58040, quitting=quitting@entry=1) at nm-manager.c:748
       #8  0x0000000000478a84 in dispose (object=0xc09050) at nm-manager.c:4558
       #9  0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
       #10
      
       0x0000000000428cc0 in main (argc=1, argv=0x7fffc0948c98) at main.c:626
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      f218f919
  20. 16 Aug, 2013 2 commits
    • Dan Winship's avatar
      core: add NMManager:startup property · bc091f2f
      Dan Winship authored
      Add a property on NMManager indicating that it is currently starting
      up and activating startup-time/boot-time network connections.
      
      "startup" is initially TRUE, and becomes FALSE once all NMDevices
      report that they have no pending activity (eg, trying to activate,
      waiting for a wifi scan to complete, etc). This is tracked via a new
      NMDevice:has-pending-activity property, which is maintained partially
      by the device itself, and partially by other parts of the code.
      bc091f2f
    • Dan Winship's avatar
      cee676e7
  21. 05 Jul, 2013 1 commit
  22. 14 Jun, 2013 2 commits
  23. 05 Jun, 2013 1 commit
    • Dan Winship's avatar
      devices: make constructors take an NMPlatformLink · b322c0dc
      Dan Winship authored
      Rather than passing UDI, ifname, and driver name to the device
      constructors as separate arguments, just pass the NMPlatformLink
      instead and let it parse them out.
      
      Virtual types still take UDI and ifname separately, since we create
      fake NMDevices for them for autoactivating connections. That's weird
      in other ways too though, so perhaps this should be revisted.
      b322c0dc
  24. 24 May, 2013 1 commit
  25. 20 May, 2013 2 commits
    • Dan Williams's avatar
      core: clean up and simplify device capabilities handling · be807819
      Dan Williams authored and Dan Winship's avatar Dan Winship committed
      This is really, really old 2007-era code.  Any NMDevice that gets
      created is already supported, so there's no reason to have every
      device set NM_DEVICE_CAP_NM_SUPPORTED.  For those subclasses that
      only set that capability, we can remove the subclass method
      entirely.  Next, it turns out that the "type capabilities" code
      wasn't used anywhere, so remove that too.  Lastly, "cipsec"
      interfaces haven't been used on linux in about 5 years (they
      were created by the Cisco binary-only IPSec kernel module for
      Cisco VPNs long before vpnc and openswan came around) so we can
      remove that code too.
      be807819
    • Dan Winship's avatar
      core: make nm-properties-changed-signal always export the right properties · 5a223b90
      Dan Winship authored
      Change the way that nm-properties-changed-signal works, and parse the
      dbus-binding-tool-generated info to get the exact list of properties
      that it's expected to export.
      
      This makes NM_PROPERTY_PARAM_NO_EXPORT unnecessary, and also fixes the
      problem of properties like NMDevice:hw-address being exported on
      classes where it shouldn't be.
      5a223b90