1. 28 May, 2019 1 commit
  2. 20 May, 2019 1 commit
  3. 19 May, 2019 1 commit
  4. 14 May, 2019 1 commit
    • Thomas Haller's avatar
      core: fix file permissions for "/var/lib/NetworkManager/secret_key" · 7a0f8520
      Thomas Haller authored
      Ooherwise, the file has wrong permissions:
      
        # ls -la /var/lib/NetworkManager/secret_key
        ----r-xr-x. 1 root root 50 May 14 13:52 /var/lib/NetworkManager/secret_key
      
      Luckily, /var/lib/NetworkManager should be already
      
        # ls -lad /var/lib/NetworkManager
        drwx------. 2 root root 8192 May 14 13:57 /var/lib/NetworkManager
      
      which mitigates this a bit.
      
      Fixes: dbcb1d6d ('core: let nm_utils_secret_key_read() handle failures internally')
      
      #175
      (cherry picked from commit dc3a2f9b)
      (cherry picked from commit 2d46247c)
      7a0f8520
  5. 10 May, 2019 2 commits
    • Thomas Haller's avatar
      settings/d-bus: fix boolean return value of "LoadConnections" · 1337ebd9
      Thomas Haller authored
      The boolean value is intended to indicate success. It would indicated
      failure due to a bug.
      
      Fixes: 297d4985 ('core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API'):
      (cherry picked from commit 22e830f0)
      (cherry picked from commit e73a5058)
      1337ebd9
    • Thomas Haller's avatar
      settings: avoid assertion for LoadConnections D-Bus method with relative paths · 8fe900d3
      Thomas Haller authored
        $ busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Settings org.freedesktop.NetworkManager.Settings LoadConnections as 1 relative/filename
      
      triggers a g_critical() assertion in nm_utils_file_is_in_path():
      
        ...
        #3  0x00007ffff7a19e7d in g_return_if_fail_warning
            (log_domain=log_domain@entry=0x55555586c333 "NetworkManager", pretty_function=pretty_function@entry=0x55555586c0a0 <__FUNCTION__.38585> "nm_utils_file_is_in_path", expression=expression@entry=0x55555586c010 "abs_filename && abs_filename[0] == '/'") at ../glib/gmessages.c:2767
        #4  0x00005555555f1128 in nm_utils_file_is_in_path (abs_filename=abs_filename@entry=0x555555b56670 "dfd", abs_path=<optimized out>) at src/NetworkManagerUtils.c:1077
        #5  0x00005555555a4779 in load_connection (config=<optimized out>, filename=0x555555b56670 "dfd") at src/settings/plugins/keyfile/nms-keyfile-plugin.c:522
        #6  0x00005555557ce291 in nm_settings_plugin_load_connection (self=0x5555559fd400 [NMSKeyfilePlugin], filename=0x555555b56670 "dfd") at src/settings/nm-settings-plugin.c:70
        #7  0x000055555559ccdf in impl_settings_load_connections
            (obj=<optimized out>, interface_info=<optimized out>, method_info=<optimized out>, connection=<optimized out>, sender=<optimized out>, invocation=0x7fffe0015ed0 [GDBusMethodInvocation], parameters=<optimized out>) at src/settings/nm-settings.c:1439
        #8  0x00005555555a9bf9 in dbus_vtable_method_call
            (connection=0x5555559b91b0 [GDBusConnection], sender=sender@entry=0x555555b5c360 ":1.32283", object_path=object_path@entry=0x7fffe0019070 "/org/freedesktop/NetworkManager/Settings", interface_name=<optimized out>, interface_name@entry=0x7fffe002aa70 "org.freedesktop.NetworkManager.Settings", method_name=<optimized out>,
            method_name@entry=0x7fffe00276b0 "LoadConnections", parameters=parameters@entry=0x555555c4a690, invocation=0x7fffe0015ed0 [GDBusMethodInvocation], user_data=0x5555559a1a00)
            at src/nm-dbus-manager.c:947
        #9  0x00007ffff7c506c4 in call_in_idle_cb (user_data=user_data@entry=0x7fffe0015ed0) at ../gio/gdbusconnection.c:4874
        #10 0x00007ffff7a0e8eb in g_idle_dispatch (source=source@entry=0x7fffe00208a0, callback=0x7ffff7c50590 <call_in_idle_cb>, user_data=0x7fffe0015ed0) at ../glib/gmain.c:5627
        #11 0x00007ffff7a11fd0 in g_main_dispatch (context=0x555555994d00) at ../glib/gmain.c:3189
        #12 0x00007ffff7a11fd0 in g_main_context_dispatch (context=context@entry=0x555555994d00) at ../glib/gmain.c:3854
        #13 0x00007ffff7a12368 in g_main_context_iterate (context=0x555555994d00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927
        #14 0x00007ffff7a126b3 in g_main_loop_run (loop=0x555555995e60) at ../glib/gmain.c:4123
        #15 0x000055555558a741 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:444
      
      Filter out relative filenames early.
      
      (cherry picked from commit a1b102ea)
      (cherry picked from commit c21171e0)
      8fe900d3
  6. 08 May, 2019 5 commits
    • Beniamino Galvani's avatar
      device: fix intersecting IPv6 configurations · 33a01ab8
      Beniamino Galvani authored
      If the link is down we shouldn't drop the link-local address from
      configuration as it wasn't removed by user but by kernel.
      
      (cherry picked from commit 18d2edfa)
      (cherry picked from commit 6f691445)
      33a01ab8
    • Beniamino Galvani's avatar
      device: unconditionally reapply IP configuration on link up · 158dae6b
      Beniamino Galvani authored
      Consider the situation in which ipv4.method=auto and there is an
      address configured. Also, the DHCP timeout is long and there is no
      DHCP server. If the link is brought down temporarily, the prefix route
      for the static address is lost and not restored by NM because we
      reapply the IP configuration only when the IP state is DONE.
      
      The same can happen also for IPv6, but in that case also static IPv6
      addresses are lost.
      
      We should always reapply the IP configuration when the link goes up.
      
      (cherry picked from commit d0b16b92)
      (cherry picked from commit 4482ca64)
      158dae6b
    • Beniamino Galvani's avatar
      all: fix typos (milli seconds -> milliseconds) · 25af9b8f
      Beniamino Galvani authored
      (cherry picked from commit 4735d676)
      (cherry picked from commit f6b9366e)
      25af9b8f
    • Beniamino Galvani's avatar
      device: fix reapply of MTU · fc61af9a
      Beniamino Galvani authored
      When we set the MTU on the link we remember its previous source
      (ip-config, parent-device or connection profile) and don't change it
      again afterwards to avoid interfering with user's manual changes. The
      only exceptions when we change it again are (1) if the parent device
      MTU changes and (2) if the new MTU has higher priority than the one
      previously set.
      
      To allow a live reapply of the MTU property we also need to clear the
      saved source, or the checks described above will prevent setting the
      new value.
      
      Fixes: 2f891723 ('device: rework mtu priority handling')
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1702657
      (cherry picked from commit 4ed72fa6)
      (cherry picked from commit e738479b)
      fc61af9a
    • Beniamino Galvani's avatar
      settings: fix failed assertion · b7cd8f28
      Beniamino Galvani authored
      Fix the following assertion failure:
      
        g_object_ref: assertion 'G_IS_OBJECT (object)' failed.
      
      nm_settings_add_connection() can return a NULL connection.
      
      Fixes: f034f17f ('settings: keep the added connection alive for a bit longer')
      (cherry picked from commit 48ce3628)
      (cherry picked from commit d80818e6)
      b7cd8f28
  7. 03 May, 2019 1 commit
  8. 18 Apr, 2019 1 commit
    • Thomas Haller's avatar
      platform: fix nm_platform_lnk_gre_to_string() for tap links · 400293d3
      Thomas Haller authored
      Why didn't we get a compiler warning about this bug?
      At least clang (3.8.0-2ubuntu4, Ubuntu 16.04) warns:
      
          CC       src/platform/src_libNetworkManagerBase_la-nm-platform.lo
        ../src/platform/nm-platform.c:5389:14: error: data argument not used by format string [-Werror,-Wformat-extra-args]
                            lnk->remote ? nm_sprintf_buf (str_remote, " remote %s", nm_utils_inet4_ntop (lnk->remote, str_remote1)) : "",
                            ^
      
      Fixes: 4c2862b9 ('platform: add gretap tunnels support')
      (cherry picked from commit dfb899f4)
      (cherry picked from commit ed88c71f)
      400293d3
  9. 12 Apr, 2019 2 commits
  10. 10 Apr, 2019 2 commits
  11. 02 Apr, 2019 1 commit
  12. 28 Mar, 2019 4 commits
    • Lubomir Rintel's avatar
      ovs: don't traverse interface through disconnected when the ovsdb entry is removed · 8ec09545
      Lubomir Rintel authored
      Go straight to unmanaged. That's what all the other devices do when
      their backing resources vanish. If the device reached disconnected
      state, an autoconnect check would try to connect it back, in vain.
      
      https://github.com/NetworkManager/NetworkManager/pull/324
      (cherry picked from commit 045b88a5)
      8ec09545
    • Lubomir Rintel's avatar
      ovs-interface: dissociate the link on disconnection · 015ef82e
      Lubomir Rintel authored
      Open vSwitch is the special kid on the block -- it likes to be in charge of
      the link lifetime and so we shouldn't be. This means that we shouldn't be
      attempting to remove the link: we'd just (gracefully) fail anyways.
      
      More importantly, this also means that we shouldn't care if we see the link
      go away. Once the device reaches DISCONNECTED state, its configuration is
      cleaned up and we may already be activating another connection. We shouldn't
      alter the device state when OpenVSwitch decides to drop the old link.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1543557
      https://github.com/NetworkManager/NetworkManager/pull/324
      (cherry picked from commit 3a55ec63)
      015ef82e
    • Lubomir Rintel's avatar
      settings: keep the added connection alive for a bit longer · ebdc37e3
      Lubomir Rintel authored
      Fixes a crash on failed AddAndActivate:
      
        $ ip link set eth0 down
        $ nmcli d conn eth0
        Error: Failed to add/activate new connection: Connection 'eth0' is not available on device eth0 because device has no carrier
        <NetworkManager crashes>
      
        #3  0x000055555558b6c5 in _nm_g_return_if_fail_warning
        #4  0x00005555557008c7 in nm_settings_has_connection
        #5  0x0000555555700e5f in pk_add_cb
        #6  0x0000555555726e30 in pk_call_cb
        #7  0x0000555555726e30 in pk_call_cb
        #8  0x0000555555726e30 in pk_call_cb
        #9  0x00005555555aaea8 in _call_id_invoke_callback
        #10 0x00005555555ab2e8 in _call_on_idle
      
      https://github.com/NetworkManager/NetworkManager/pull/325
      (cherry picked from commit f034f17f)
      ebdc37e3
    • Lubomir Rintel's avatar
      device: fix the slave state change reason on master connection removal · b4359e57
      Lubomir Rintel authored
      If we surprise-remove the master, slaves would immediately attempt to bring
      things up by autoconnecting. Not cool. Policy, however, blocks
      autoconnect if the slaves disconnect due to "dependency-failed", and it
      indeed seems to be an appropriate reason here:
      
        $ nmcli c add type bridge
        $ nmcli c add type dummy ifname dummy0 master bridge autoconnect yes
        $ nmcli c del bridge
        $
      
      Before:
      
        (nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
        (nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
        (nm-bridge): detached bridge port dummy0
        (dummy0): state change: activated -> disconnected (reason 'connection-removed')
        (nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
        (dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
        policy: auto-activating connection 'bridge-slave-dummy0'
      
      After:
      
        (nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
        (nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
        (nm-bridge): detached bridge port dummy0
        (dummy0): state change: activated -> deactivating (reason 'dependency-failed')
        (nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
        (dummy0): state change: deactivating -> disconnected (reason 'dependency-failed')
        (dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
      
      https://github.com/NetworkManager/NetworkManager/pull/319
      (cherry picked from commit 8f2a8a52)
      b4359e57
  13. 26 Mar, 2019 1 commit
  14. 15 Mar, 2019 1 commit
  15. 11 Mar, 2019 8 commits
  16. 08 Mar, 2019 1 commit
  17. 07 Mar, 2019 7 commits