1. 11 Sep, 2014 6 commits
  2. 10 Sep, 2014 4 commits
  3. 09 Sep, 2014 9 commits
  4. 08 Sep, 2014 2 commits
  5. 05 Sep, 2014 8 commits
  6. 04 Sep, 2014 11 commits
    • Dan Winship's avatar
      00695f19
    • Dan Winship's avatar
      examples: port dbus-glib-based examples to gdbus · 9e5ddb58
      Dan Winship authored
      Port the dbus-glib-based examples to GDBus.
      
      Also, don't use libnm in them at all; there's not much point in
      examples that use the D-Bus API directly if they're just going to fall
      back to libnm for the hard stuff... (And also, this avoids the problem
      that GDBus uses GVariant, while the libnm-core APIs currently still
      use GHashTables.)
      
      Also fix up some comment grammar and copyright style, and add emacs
      modelines where missing.
      
      Also rename the existing GDBus-based examples to have names ending in
      "-gdbus", not "-GDBus", since there's no reason to gratuitously
      capitalize here.
      9e5ddb58
    • Dan Winship's avatar
      89228569
    • Dan Winship's avatar
      66c238e7
    • Dan Williams's avatar
    • Dan Williams's avatar
      core: take over IPv6LL address management if kernel supports it (bgo #734149) · 5e4761a3
      Dan Williams authored
      NM keeps interfaces IFF_UP when possible to receive link layer
      events like carrier changes.  Unfortunately, the kernel also
      uses IFF_UP as a flag to assign an IPv6LL address to the interface,
      which results in IPv6 connectivity on the link even if the interface
      is not supposed to be activated/connected.
      
      NM sets disable_ipv6=1 to ensure that the kernel does not set up
      IPv6LL connectivity on interfaces when they are not supposed to
      be active and connected.  Unfortunately, that prevents users from
      manually adding IPv6 addresses to the interface, since they expect
      previous kernel behavior where IPv6 is enabled whenever the
      interface is IFF_UP.
      
      Furthermore, interfaces like PPP and some WWAN devices provide
      misleading information to the kernel which causes the kernel to
      create the wrong IPv6LL address for the interface.  The IPv6LL
      address for these devices is obtained through control channels
      instead (IPV6CP for PPP, proprietary protocols for WWAN devices)
      and should be used instead of the kernel address.  So we'd like
      to suppress kernel IPv6LL address generation on these interfaces
      anyway.
      
      This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE
      attribute to take over assignment of IPv6LL addresses while
      keeping the interface IFF_UP, to ensure there is only IPv6
      connectivity when the user requests it.
      
      To remain compliant with standards, if a user adds IPv6 addresses
      externally, NetworkManager must also immediately add an IPv6LL
      address for that interface too.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734149
      5e4761a3
    • Dan Williams's avatar
      platform: add support for kernel IPv6LL address generation modes · 37f11fbd
      Dan Williams authored
      This patch requires both upstream kernel support for
      IFLA_INET6_ADDR_GEN_MODE which was merged in this patch:
      
      ipv6: addrconf: implement address generation modes
      bc91b0f07ada5535427373a4e2050877bcc12218
      
      and corresponding libnl support, merged in these patches:
      
      veth: add kernel header linux/veth.h for VETH defines
      9dc6e6da90016a33929f262bea0187396e1a061b
      
      link: update copy of kernel header include/linux/if_link.h
      b51815a9dbd8e45fd2558bbe337fb360ca2fd861
      
      link/inet6: add link IPv6 address generation mode support
      558f966782539f6d975da705fd73cea561c9dc83
      37f11fbd
    • Dan Williams's avatar
      899df02e
    • Dan Williams's avatar
      tui: fix updating of NmtPasswordFields passwords (bgo #733002) · 82b0ea87
      Dan Williams authored
      The actual entry is a sub-widget, and was getting updated when the
      user changed the password, but those changes were not being
      propagated to the NmtPasswordFields object's 'password' property.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=733002
      82b0ea87
    • Dan Williams's avatar
      tui: fix requesting and displaying secrets · 240a9a92
      Dan Williams authored
      nmt_sync_op_complete_pointer() completes the operation after the
      caller of this function returns.  This means that any values passed
      to this function must either be allocated from its caller, or
      referenced by the caller.
      
      nm_remote_connection_get_secrets() owns the 'secrets' hash passed
      to the callback, and it is destroyed when the callback returns.
      So nmtui's got_secrets() must copy the hash to ensure the data
      sticks around for nmt_sync_op_wait_pointer() later.
      240a9a92
    • Dan Winship's avatar
      libnm: simplify property types [bgo #734492] · e7f01ae5
      Dan Winship authored
      e7f01ae5