1. 26 Sep, 2018 1 commit
  2. 24 Sep, 2018 12 commits
  3. 21 Sep, 2018 10 commits
    • Thomas Haller's avatar
      dns: fix creating resolv.conf content · 511709c5
      Thomas Haller authored
      g_string_new_len() allocates the buffer with length
      bytes. Maybe it should be obvious (wasn't to me), but
      if a init argument is given, that is taken as containing
      length bytes.
          str = g_string_new_len (init, len);
      is more like
          str = g_string_new_len (NULL, len);
          g_string_append_len (str, init, len);
      and not (how I wrongly thought)
          str = g_string_new_len (NULL, len);
          g_string_append (str, init);
      Fixes: 95b006c2
    • Andrei Dziahel's avatar
      Do not manage Docker bridge interfaces · 0ce73275
      Andrei Dziahel authored
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      dns: always write "/var/run/NetworkManager/resolv.conf" · cddb9132
      Thomas Haller authored
      Previously, if "main.rc-manager" was set to "unmanaged"
      and "/etc/resolv.conf" was symlink to our internal file
      "/var/run/NetworkManager/resolv.conf", NM would not rewrite
      the file, in an attempt to honor the requirement of NetworkManager
      not changing resolv.conf.
      No longer special case this. I think it was wrong and inconsistent.
      If the user specifies rc-manager unmanaged, he also should manage
      /etc/resolv.conf accordingly. And if the user decided to symlink
      it to our internal file, that is fine. It should not stop NM from
      updating that file.
      Also, this was the only cases, where NM would not write our internal
      resolv.conf (errors aside). It was inconsitent, and also not documented
      behavior. Instead, it is documented that `man NetworkManager.conf`:
        Regardless of this setting, NetworkManager will always write
        resolv.conf to its runtime state directory
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      dns: write original DNS servers to /var/run/NetworkManager/no-stub-resolv.conf · 0dc673f0
      Thomas Haller authored
      When a DNS plugin is enabled (like "main.dns=dnsmasq" or "main.dns=systemd-resolved"),
      the name servers announced to the rc-manager are coerced to be
      Depending on the "main.rc-manager" setting, also "/etc/resolv.conf"
      contains only this coerced name server to the local caching service.
      The same is true for "/var/run/NetworkManager/resolv.conf" file, which
      contains what we would write to "/etc/resolv.conf" (depending on
      the "main.rc-manager" configuration).
      Write a new file "/var/run/NetworkManager/no-stub-resolv.conf", which contains
      the original name servers, uncoerced. Like "/var/run/NetworkManager/resolv.conf",
      this file is always written.
      The effect is, when one enables "main.dns=systemd-resolved", then there
      is still a file "no-stub-resolv.conf" with the same content as with
      The no-stub-resolv.conf may be a possible solution, when a user wants
      NetworkManager to update systemd-resolved, but still have a regular
      /etc/resolv.conf [1]. For that, the user could configure
      and symlink "/etc/resolv.conf" to "/var/run/NetworkManager/no-stub-resolv.conf".
      This is not necessarily the only solution for the problem and does not preclude
      options for updating systemd-resolved in combination with other DNS plugins.
      [1] #20
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      all: pass O_CLOEXEC flag to g_mkstemp() · 20a7e489
      Thomas Haller authored
    • Thomas Haller's avatar
      libnm: don't skip NMObject:path from documentation and introspection · bbc88cd0
      Thomas Haller authored
      The D-Bus path is a useful property, also exposed via
      nm_object_get_path() function. Don't mark it to be
      skipped from documentation and introspection.
      This was changed in "1f5b48a5 libnm: use the o.fd.DBus.ObjectManager
      API for object management" and was an API breakage of libnm.
      This also caused a bug in gnome-shell [1].
      [1] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/240/diffs
      [2] https://bugzilla.redhat.com/show_bug.cgi?id=1628263
      Fixes: 1f5b48a5
    • Frederic Danis's avatar
      core: fix route metric set to -1 on DHCP renewal · 7d155757
      Frederic Danis authored
      The first DHCP renew after setting back Ethernet metric to default (-1)
      applies a metric of 4294967295 (uint16 -1) instead of the default metric.
      The route becomes:
        Kernel IP routing table
        Destination     Gateway         Genmask         Flags Metric Ref Use Iface         U     700    0     0 ppp0         UG    -1     0     0 eth0 UH    0      0     0 ppp0 UH    700    0     0 ppp0     U     50     0     0 tun0   U     100    0     0 eth0 UH    100    0     0 eth0 UGH   100    0     0 eth0
      Route update traces:
        Sep 20 09:53:11.869027 tap-0FB1 NetworkManager[762]: <debug> libsystemd: DHCP CLIENT (0xfd5eaeb9): REQUEST (renewing)
        Sep 20 09:53:11.873766 tap-0FB1 NetworkManager[762]: <debug> libsystemd: DHCP CLIENT (0xfd5eaeb9): ACK
        Sep 20 09:53:11.873792 tap-0FB1 NetworkManager[762]: <debug> libsystemd: DHCP CLIENT (0xfd5eaeb9): lease expires in 1min 58s
        Sep 20 09:53:11.873800 tap-0FB1 NetworkManager[762]: <debug> libsystemd: DHCP CLIENT (0xfd5eaeb9): T2 expires in 1min 35s
        Sep 20 09:53:11.873808 tap-0FB1 NetworkManager[762]: <debug> libsystemd: DHCP CLIENT (0xfd5eaeb9): T1 expires in 50s
        Sep 20 09:53:11.873845 tap-0FB1 NetworkManager[762]: <debug> dhcp4 (eth0): client event 4
        Sep 20 09:53:11.873853 tap-0FB1 NetworkManager[762]: <debug> dhcp4 (eth0): lease available
        Sep 20 09:53:11.873881 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   address
        Sep 20 09:53:11.873890 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   plen 24
        Sep 20 09:53:11.873899 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   expires in 120 seconds
        Sep 20 09:53:11.873916 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   nameserver ''
        Sep 20 09:53:11.873925 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   hostname 'TAPOFB1'
        Sep 20 09:53:11.873932 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0):   gateway
        Sep 20 09:53:11.874064 tap-0FB1 NetworkManager[762]: <info>  dhcp4 (eth0): state changed bound -> bound
        Sep 20 09:53:11.874082 tap-0FB1 NetworkManager[762]: <debug> device[0x558dc60b3140] (eth0): new DHCPv4 client state 1
        Sep 20 09:53:11.874535 tap-0FB1 NetworkManager[762]: <debug> device[0x558dc60b3140] (eth0): ip4-config: update (commit=1, new-config=0x558dc6110be0)
        Sep 20 09:53:11.874569 tap-0FB1 NetworkManager[762]: <debug> platform: address: adding or updating IPv4 address: lft 120sec pref 120sec lifetime 237-0[120,120] dev 2 flags noprefixroute src unkn
        Sep 20 09:53:11.874626 tap-0FB1 NetworkManager[762]: <trace> platform-linux: event-notification: RTM_NEWADDR, flags 0, seq 141: lft 120sec pref 120sec lifetime 237-237[120,120] dev 2 flags noprl
        Sep 20 09:53:11.874653 tap-0FB1 NetworkManager[762]: <debug> platform: signal: address 4 changed: lft 120sec pref 120sec lifetime 237-237[120,120] dev 2 flags noprefixroute src kernel
        Sep 20 09:53:11.874671 tap-0FB1 NetworkManager[762]: <debug> device[0x558dc60b3140] (eth0): queued IP4 config change
        Sep 20 09:53:11.874699 tap-0FB1 NetworkManager[762]: <debug> platform-linux: do-add-ip4-address[2:]: success
        Sep 20 09:53:11.874723 tap-0FB1 NetworkManager[762]: <debug> platform: route: append     IPv4 route: via dev 2 metric 4294967295 mss 0 rt-src dhcp
        Sep 20 09:53:11.874778 tap-0FB1 NetworkManager[762]: <trace> platform-linux: event-notification: RTM_NEWROUTE, flags excl,create, seq 142: via dev 2 metric 4294967295 mss 0 rt-src rt-dhcl
        Sep 20 09:53:11.874809 tap-0FB1 NetworkManager[762]: <debug> platform: signal: route   4   added: via dev 2 metric 4294967295 mss 0 rt-src rt-dhcp scope global
        Sep 20 09:53:11.874846 tap-0FB1 NetworkManager[762]: <debug> platform-linux: do-add-ip4-route[ via dev 2 metric 4294967295 mss 0 rt-src rt-dhcp scope global]: success
        Sep 20 09:53:11.874867 tap-0FB1 NetworkManager[762]: <debug> platform: ip4-route: delete via dev 2 metric 100 mss 0 rt-src rt-dhcp scope global
        Sep 20 09:53:11.874904 tap-0FB1 NetworkManager[762]: <trace> platform-linux: event-notification: RTM_DELROUTE, flags 0, seq 143: via dev 2 metric 100 mss 0 rt-src rt-dhcp scope global
        Sep 20 09:53:11.874930 tap-0FB1 NetworkManager[762]: <debug> platform: signal: route   4 removed: via dev 2 metric 100 mss 0 rt-src rt-dhcp scope global
        Sep 20 09:53:11.874961 tap-0FB1 NetworkManager[762]: <debug> platform-linux: do-delete-ip4-route[ via dev 2 metric 100 mss 0 rt-src rt-dhcp scope global]: success
        Sep 20 09:53:11.874983 tap-0FB1 NetworkManager[762]: <trace> platform: ip4-dev-route: register via dev 2 metric 0 mss 0 rt-src rt-kernel scope link pref-src (update)
      Fixes: b9e6433a
  4. 20 Sep, 2018 3 commits
    • Thomas Haller's avatar
      cli: adjust error message about incompatible connection/device · 5f66700b
      Thomas Haller authored
        # nmcli connection up w ifname w
        Error: device 'w' not compatible with connection 'w':The connection was not an Ethernet or PPPoE connection..
    • Beniamino Galvani's avatar
      readme: update issue tracker address · 0cab530b
      Beniamino Galvani authored
      While at it, update the section about logging.
    • Thomas Haller's avatar
      acd: fix crash in acd-event loop · 29c95cd9
      Thomas Haller authored
      Don't emit signals while popping acd events. Otherwise, we can get
      a crash:
          #0  0x000055c2bb094e3b in n_acd_pop_event (acd=0x0, eventp=eventp@entry=0x7ffd47de65b0) at shared/n-acd/src/n-acd.c:846
                  node = <optimized out>
                  t_node = <optimized out>
          #1  0x000055c2baff53be in acd_event (source=<optimized out>, condition=<optimized out>, data=0x55c2bc4a6cf0) at src/devices/nm-acd-manager.c:180
                  self = 0x55c2bc4a6cf0
                  priv = 0x55c2bc4a6d08
                  __func__ = "acd_event"
                  event = 0x55c2bc593af0
                  info = 0x55c2bc4b76c0
                  address_str = "\000\000\000\000\000\000\000\000\bd\373\272\302U\000"
                  hwaddr_str = 0x0
                  r = <optimized out>
          #2  0x00007eff336238f9 in g_main_context_dispatch (context=0x55c2bc41f480) at gmain.c:3146
                  dispatch = 0x7eff336688a0 <g_io_unix_dispatch>
                  prev_source = 0x0
                  was_in_call = 0
                  user_data = 0x55c2bc4a6cf0
                  callback = 0x55c2baff5310 <acd_event>
                  cb_funcs = 0x7eff338eb920 <g_source_callback_funcs>
                  cb_data = 0x55c2bc558680
                  need_destroy = <optimized out>
                  source = 0x55c2bc58c160
                  current = 0x55c2bc43dd10
                  i = 0
      While at it, don't return from the events N_ACD_EVENT_DEFENDED,
      N_ACD_EVENT_CONFLICT, and <default>, but continue popping events.
      Fixes: d9a4b59c
  5. 19 Sep, 2018 14 commits