1. 26 Sep, 2018 1 commit
  2. 24 Sep, 2018 8 commits
    • Lubomir Rintel's avatar
      connectivity: fix a wrong comparision · 60007d7c
      Lubomir Rintel authored
      Thanks clang 7.
      
      Fixes: cbfe6aa9
      60007d7c
    • Lubomir Rintel's avatar
      connectivity: create a multi-handle for all requests · cbfe6aa9
      Lubomir Rintel authored
      This is dead ugly and works around what probably is a libcurl (7.59) bug:
      It shares the resolver cache among easy handles in a multi handle when
      it shouldn't:
      
      When we create two easy handles, one for IPv4 and one for IPv6 in a
      single mhandle:
      
        curl_easy_setopt (ehandle6, CURLOPT_RESOLVE,
          "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda"
          "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1")
        curl_easy_setopt (ehandle4, CURLOPT_RESOLVE,
          "fedoraproject.org:8.43.85.67"
          "fedoraproject.org:152.19.134.198")
        curl_multi_add_handle (mhandle, ehandle6);
        curl_multi_add_handle (mhandle, ehandle4);
      
      Both end up connecting to the same (either v4 or v6) address. None of
      CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3),
      CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make
      any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
      cbfe6aa9
    • Lubomir Rintel's avatar
      device: expose connectivity check result on a device · d8971fcb
      Lubomir Rintel authored
      Separate properties for IPv4 and IPv6.
      d8971fcb
    • Lubomir Rintel's avatar
      connectivity: allow limiting the connectivity check to a specified AF · 9664f284
      Lubomir Rintel authored
      Nothing changes practically, as the NMDevice still starts this with
      AF_UNSPEC. That is going to change in the following commit.
      
      The ugly part:
      
      priv->concheck_x[0] in few places. I believe we shouldn't be using union
      aliasing here, and instead of indexing the v4/v6 arrays by a boolean it
      should be an enum. I'm not fixing it here, but I eventually plan to if
      this gets an ACK.
      9664f284
    • Lubomir Rintel's avatar
      connectivity: use systemd-resolved for resolving the check endpoint · 2cec94ba
      Lubomir Rintel authored
      This allows us to use the correct DNS server for the particular interface
      independent of what the system resolver is configured to use.
      
      The ugly part:
      
      Unfortunately, it is not all that easy. The libc's libresolv.so API does
      not provide means for influencing neither interface nor name servers used
      for DNS resolving.
      
      Curl can also be compiled with c-ares resolver backend that does provide
      the necessary functionality, but it requires and extra library and the
      Linux distributions don't seem to enable it. (Fedora doesn't, which is a
      good sign we don't have an option of relying on it.)
      
      systemd-resolved does provide everything we need. If we take care to
      keep its congfiguration up to date, we can use it to do the resolving on
      a particular interface with that interface's DNS configuration. Great!
      
      There's one more problem: Curl doesn't provide callbacks for resolving
      host names.  It doesn't, however, allow us to pass in the pre-resolved
      hostnames in form of an CURLOPT_RESOLVE(3) option. This means we have to
      parse the host name out of the URL ourselves. Fair enough I guess...
      2cec94ba
    • Lubomir Rintel's avatar
      connectivity: improve curl error messages · 753ffdbc
      Lubomir Rintel authored
      753ffdbc
    • Lubomir Rintel's avatar
      dns: allow loading nm-dns-systemd-resolve alongside other DNS plugins · d4eb4cb4
      Lubomir Rintel authored
      Even when the system resolver is configured to something else that
      systemd-resolved, it still is a good idea to keep systemd-resolved up to
      date. If not anything else, it does a good job at doing per-interface
      resolving for connectivity checks.
      
      If for whatever reasons don't want NetworkManager to push the DNS data
      it discovers to systemd-resolved, the functionality can be disabled
      with:
      
        [main]
        systemd-resolved=false
      d4eb4cb4
    • Lubomir Rintel's avatar
      initrd/cmdline-reader: fix whitespace errors · ecde3e90
      Lubomir Rintel authored
      Detected by checkpatch.pl
      ecde3e90
  3. 21 Sep, 2018 5 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.
      
      So,
      
          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
      511709c5
    • 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
        /var/run/NetworkManager/resolv.conf.
      cddb9132
    • 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 127.0.0.1
      or 127.0.0.53.
      
      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
      "main.dns=default".
      
      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
      
          [main]
          dns=systemd-resolved
          rc-manager=unmanaged
      
      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
      0dc673f0
    • Thomas Haller's avatar
    • 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
        0.0.0.0         0.0.0.0         0.0.0.0         U     700    0     0 ppp0
        0.0.0.0         192.168.19.193  0.0.0.0         UG    -1     0     0 eth0
        10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0     0 ppp0
        10.64.64.64     0.0.0.0         255.255.255.255 UH    700    0     0 ppp0
        10.250.0.0      0.0.0.0         255.255.0.0     U     50     0     0 tun0
        192.168.19.0    0.0.0.0         255.255.255.0   U     100    0     0 eth0
        192.168.19.193  0.0.0.0         255.255.255.255 UH    100    0     0 eth0
        217.114.201.194 192.168.19.193  255.255.255.255 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 192.168.19.100
        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 '192.168.19.193'
        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 192.168.19.193
        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: 192.168.19.100/24 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: 192.168.19.100/24 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: 192.168.19.100/24 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: 192.168.19.100/24]: success
        Sep 20 09:53:11.874723 tap-0FB1 NetworkManager[762]: <debug> platform: route: append     IPv4 route: 0.0.0.0/0 via 192.168.19.193 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: 0.0.0.0/0 via 192.168.19.193 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: 0.0.0.0/0 via 192.168.19.193 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[0.0.0.0/0 via 192.168.19.193 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 0.0.0.0/0 via 192.168.19.193 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: 0.0.0.0/0 via 192.168.19.193 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: 0.0.0.0/0 via 192.168.19.193 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[0.0.0.0/0 via 192.168.19.193 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 192.168.19.0/24 via 0.0.0.0 dev 2 metric 0 mss 0 rt-src rt-kernel scope link pref-src 192.168.19.100 (update)
      
      https://mail.gnome.org/archives/networkmanager-list/2018-September/msg00020.html
      
      Fixes: b9e6433a
      7d155757
  4. 20 Sep, 2018 1 commit
    • 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
      29c95cd9
  5. 19 Sep, 2018 9 commits
    • Thomas Haller's avatar
      core: improve logging why startup-complete is blocked · 793afb7d
      Thomas Haller authored
      Before:
      
          "manager: check_if_startup_complete returns FALSE because of eth0"
      
      Now:
      
          "manager: startup complete is waiting for device 'eth0' (autoactivate)"
      
      Also, the logging line is now more a human readable sentence, but still
      follows the same pattern as later
      
          "manager: startup complete"
      
      Meaning: grepping for "startup complete" becomes more helpful because
      one first finds the reasons why startup-complete is not yet reached,
      followed by the moment when it is reached.
      793afb7d
    • Beniamino Galvani's avatar
      initrd: enable meson builds · 470c5c0a
      Beniamino Galvani authored
      470c5c0a
    • Beniamino Galvani's avatar
      build: meson: fix computing NM exported symbols · 19a718bc
      Beniamino Galvani authored
      The script didn't include all the symbols needed by plugins because
      libNetworkManager.a, as built by meson, doesn't include symbols from
      other static libraries that are linked in. Since we used
      libNetworkManager.a to know which symbols are potentiall available
      from NM, the result was an incomplete list.
      
      Unfortunately, the only way to include the whole static library is to
      create a dependency object and use 'link_whole', but this is only
      available in meson >= 0.46. Since 'link_whole' is available for
      executables in meson >= 0.40, create a fake executable and use that to
      enumerate symbols.
      
      Also add tests to check that plugins can be loaded correctly.
      
      Fixes: dfa2a2b4
      19a718bc
    • Lubomir Rintel's avatar
      settings/ifupdown/tests: avoid asserting on an array · b64ae759
      Lubomir Rintel authored
      char[] is not a char *; it can not go NULL.
      
        test-ifupdown.c:147:27: error: address of array 'n->name' will always evaluate
                                       to 'true' [-Werror,-Wpointer-bool-conversion]
                      g_assert (b->name && n->name);
        test-ifupdown.c:156:27: error: address of array 'm->key' will always evaluate
                                       to 'true' [-Werror,-Wpointer-bool-conversion]
                              g_assert (k->key && m->key);
      b64ae759
    • Lubomir Rintel's avatar
      devices/acd-manager: avoid uninitialzied variable use · 36f08256
      Lubomir Rintel authored
        src/devices/nm-acd-manager.c:419:31: error: variable 'info' is uninitialized
                                             when used here [-Werror,-Wuninitialized]
                             nm_utils_inet4_ntop (info->address, NULL),
      36f08256
    • Andrew Zaborowski's avatar
      wifi/iwd: don't change state in secrets callback · 061913c5
      Andrew Zaborowski authored
      Also make sure the secrets request callback only send a reply to IWD and
      the Connect method return callback executes the device state change to
      "disconnected".
      061913c5
    • Andrew Zaborowski's avatar
      wifi/iwd: actually wait for Connect() call return · 44af62eb
      Andrew Zaborowski authored
      state_changed (called when IWD signalled device state change) was
      supposed to not change NM device state on connect success or failure and
      instead wait for the DBus Connect() method callback but it would
      actually still call nm_device_emit_recheck_auto_activate on failure so
      refactor state_changed and network_connect_cb to make sure
      the state change and nm_device_emit_recheck_auto_activate are only
      called from network_connect_cb.
      
      This fixes a race where during a switch from one network to another NM
      would immediately start a new activation after state_changed and
      network_connect_cb would then handle the Connect failure and mark the
      new activation as failed.
      44af62eb
    • Andrew Zaborowski's avatar
      wifi/iwd: don't save secrets in mirror NM connections · e3aba12d
      Andrew Zaborowski authored
      When creating the mirror 802.1x connections for IWD 802.1x profiles
      set the NM_SETTING_SECRET_FLAG_NOT_SAVED flag on the secrets that
      may at some point be requested from our agent.  The saved secrets could
      not be used anyway because of our use of
      NM_SECRET_AGENT_GET_SECRETS_FLAG_REQUEST_NEW in
      nm_device_iwd_agent_query.  But also try to respect whatever secret
      caching policy has been configured in the IWD profile for those secrets,
      IWD would be responsible for storing them if it was allowed in the
      profile.
      e3aba12d
    • Andrew Zaborowski's avatar
      wifi/iwd: access Network objects through ObjectManager · fd1cfa6d
      Andrew Zaborowski authored
      In two places stop using g_dbus_proxy_new_* to create whole new
      interface proxy objects for net.connman.iwd.Network as this will
      normally have a huge overhead compared to asking the ObjectManager
      client that we already have in NMIwdManager for those proxies.
      dbus-monitor shows that for each network path returned by
      GetOrderedNetworks () -- and we call it every 10 or 20 seconds and may
      get many dozens of networks back -- gdbus would do the following each
      time:
      org.freedesktop.DBus.AddMatch("member=PropertiesChanged")
      org.freedesktop.DBus.StartServiceByName("net.connman.iwd")
      org.freedesktop.DBus.GetNameOwner("net.connman.iwd")
      org.freedesktop.DBus.Properties.GetAll("net.connman.iwd.Network")
      org.freedesktop.DBus.RemoveMatch("member=PropertiesChanged")
      fd1cfa6d
  6. 18 Sep, 2018 16 commits