1. 28 May, 2019 1 commit
  2. 12 Feb, 2019 3 commits
  3. 05 Feb, 2019 1 commit
  4. 04 Feb, 2019 1 commit
  5. 19 Dec, 2018 1 commit
    • Aleksander Morgado's avatar
      settings,gsm: deprecate and stop using 'number' property · 6ed21e83
      Aleksander Morgado authored
      The 'number' property in GSM settings is a legacy thing that comes
      from when ModemManager used user-provided numbers, if any, to connect
      3GPP modems.
      
      Since ModemManager 1.0, this property is completely unused for 3GPP
      modems, and so it doesn't make sense to use it in the NetworkManager
      settings. Ofono does not use it either.
      
      For AT+PPP-based 3GPP modems, the 'number' to call to establish the
      data connection is decided by ModemManager itself, e.g. for standard
      GSM/UMTS/LTE modems it will connect a given predefined PDP context,
      and for other modems like Iridium it will have the number to call
      hardcoded in the plugin itself.
      
      https://github.com/NetworkManager/NetworkManager/pull/261
      6ed21e83
  6. 29 Nov, 2018 1 commit
    • Lubomir Rintel's avatar
      all: say Wi-Fi instead of "wifi" or "WiFi" · b385ad01
      Lubomir Rintel authored
      Correct the spelling across the *entire* tree, including translations,
      comments, etc. It's easier that way.
      
      Even the places where it's not exposed to the user, such as tests, so
      that we learn how is it spelled correctly.
      b385ad01
  7. 04 Oct, 2018 1 commit
    • Thomas Haller's avatar
      keyfile: split automatically setting ID/UUID for keyfile · 837d44ff
      Thomas Haller authored
      keyfile already supports omitting the "connection.id" and
      "connection.uuid". In that case, the ID would be taken from the
      keyfile's name, and the UUID was generated by md5 hashing the
      full filename.
      
      No longer do this during nm_keyfile_read(), instead let all
      callers call nm_keyfile_read_ensure_*() to their liking. This is done
      for two reasons:
      
       - a minor reason is, that one day we want to expose keyfile API
         as public API. That means, we also want to read keyfiles from
         stdin, where there is no filename available. The implementation
         which parses stdio needs to define their own way of auto-generating
         ID and UUID. Note how nm_keyfile_read()'s API no longer takes a
         filename as argument, which would be awkward for the stdin case.
      
       - Currently, we only support one keyfile directory, which (configurably)
         is "/etc/NetworkManager/system-connections".
         In the future, we want to support multiple keyfile dirctories, like
         "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles".
         Here we want that a file "foo" (which does not specify a UUID) gets the
         same UUID regardless of the directory it is in. That seems better, because
         then the UUID won't change as you move the file between directories.
         Yes, that means, that the same UUID will be provided by multiple
         files, but NetworkManager must already cope with that situation anyway.
         Unfortunately, the UUID generation scheme hashes the full path. That
         means, we must hash the path name of the file "foo" inside the
         original "system-connections" directory.
         Refactor the code so that it accounds for a difference between the
         filename of the keyfile, and the profile_dir used for generating
         the UUID.
      837d44ff
  8. 14 Sep, 2018 2 commits
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · fe866fbe
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      
      (cherry picked from commit a10156f5)
      fe866fbe
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · a10156f5
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      a10156f5
  9. 04 Sep, 2018 1 commit
    • Thomas Haller's avatar
      ifcfg-rh: don't use 802-1x certifcate setter functions · e3ac45c0
      Thomas Haller authored
      The certificate setter function like nm_setting_802_1x_set_ca_cert()
      actually load the file from disk, and validate whether it is a valid
      certificate. That is very wrong to do.
      
      For one, the certificates are external files, which are not embedded
      into the NMConnection. That means, strongly validating the files while
      loading the ifcfg files, is wrong because:
       - if validation fails, loading the file fails in its entirety with
         a warning in the log. That is not helpful to the user, who now
         can no longer use nmcli to fix the path of the certificate (because
         the profile failed to load in the first place).
       - even if the certificate is valid at load-time, there is no guarantee
         that it is valid later on, when we actually try to use the file. What
         good does such a validation do? nm_setting_802_1x_set_ca_cert() might
         make sense during nmcli_connection_modify(). At the moment when we
         create or update the profile, we do want to validate the input and
         be helpful to the user. Validating the file later on, when reloading
         the profile from disk seems undesirable.
       - note how keyfile also does not perform such validations (for good
         reasons, I presume).
      
      Also, there is so much wrong with how ifcfg reader handles EAP files.
      There is a lot of duplication, and trying to be too smart. I find it
      wrong how the "eap_readers" are nested. E.g. both eap_peap_reader() and
      "tls" method call to eap_tls_reader(), making it look like that
      NMSetting8021x can handle multiple EAP profiles separately. But it cannot. The
      802-1x profile is a flat set of properties like ca-cert and others. All
      EAP methods share these properties, so having this complex parsing
      is not only complicated, but also wrong. The reader should simply parse
      the shell variables, and let NMSetting8021x::verify() handle validation
      of the settings. Anyway, the patch does not address that.
      
      Also, the setting of the likes of NM_SETTING_802_1X_CLIENT_CERT_PASSWORD was
      awkwardly only done when
           privkey_format != NM_SETTING_802_1X_CK_FORMAT_PKCS12
        && scheme == NM_SETTING_802_1X_CK_SCHEME_PKCS11
      It is too smart. Just read it from file, if it contains invalid data, let
      verify() reject it. That is only partly addressed.
      
      Also note, how writer never actually writes the likes of
      IEEE_8021X_CLIENT_CERT_PASSWORD. That is another bug and not fixed
      either.
      e3ac45c0
  10. 30 Aug, 2018 1 commit
  11. 11 Aug, 2018 1 commit
  12. 10 Aug, 2018 2 commits
    • Thomas Haller's avatar
      libnm, cli, ifcfg-rh: add NMSettingEthtool setting · df30651b
      Thomas Haller authored
      Note that in NetworkManager API (D-Bus, libnm, and nmcli),
      the features are called "feature-xyz". The "feature-" prefix
      is used, because NMSettingEthtool possibly will gain support
      for options that are not only -K|--offload|--features, for
      example -C|--coalesce.
      
      The "xzy" suffix is either how ethtool utility calls the feature
      ("tso", "rx"). Or, if ethtool utility specifies no alias for that
      feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
      If possible, we prefer ethtool utility's naming.
      
      Also note, how the features "feature-sg", "feature-tso", and
      "feature-tx" actually refer to multiple underlying kernel features
      at once. This too follows what ethtool utility does.
      
      The functionality is not yet implemented server-side.
      df30651b
    • Thomas Haller's avatar
      ifcfg-rh/tests: regenerate .cexpected files with NM_TEST_REGENERATE=1 · f69fb04c
      Thomas Haller authored
      The tests already honored the environment variable $NMTST_IFCFG_RH_UPDATE_EXPECTED
      to indicate that the .cexpected files should be written by the tests.
      
      However, in the meantime, we instead use NM_TEST_REGENERATE=1 at various
      places for this purpose. Honor that flag as well.
      f69fb04c
  13. 11 Jul, 2018 1 commit
  14. 31 May, 2018 1 commit
    • Thomas Haller's avatar
      build: use default NM_BUILD_* defines for tests · b7426e91
      Thomas Haller authored
      Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR
      for specifying the location of srcdir and builddir.
      
      Note that this is only relevant for tests, as they expect
      a certain layout of the directories, to find files that concern
      them.
      b7426e91
  15. 10 May, 2018 1 commit
    • Lubomir Rintel's avatar
      all: use the elvis operator wherever possible · e69d3869
      Lubomir Rintel authored
      Coccinelle:
      
        @@
        expression a, b;
        @@
        -a ? a : b
        +a ?: b
      
      Applied with:
      
        spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
      
      With some manual adjustments on spots that Cocci didn't catch for
      reasons unknown.
      
      Thanks to the marvelous effort of the GNU compiler developer we can now
      spare a couple of bits that could be used for more important things,
      like this commit message. Standards commitees yet have to catch up.
      e69d3869
  16. 30 Apr, 2018 1 commit
  17. 21 Apr, 2018 1 commit
  18. 18 Apr, 2018 2 commits
  19. 20 Mar, 2018 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: preserve NULL wifi mode when persisting a connection · e09ffb0c
      Beniamino Galvani authored
      The wireless mode property can be unset (NULL), in which case it
      assumed to be equivalent to "infrastructure". If we convert an unset
      mode to infrastructure, the connection will change on write,
      triggering errors like:
      
       settings-connection[...]: write: successfully updated (ifcfg-rh: persist (null)), connection was modified in the process
       device (wlp4s0): Activation: (wifi) access point 'test1' has security, but secrets are required.
       device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
       device (wlp4s0): The connection was modified since activation
       device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
      
      To fix this, remove the MODE key when the mode is unset so that the
      property is read back exactly as it was. Note that initscripts need
      the MODE set, but in most cases there are other issues that make Wi-Fi
      connection written by NM not compatible with initscripts.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1549972
      e09ffb0c
  20. 16 Jan, 2018 1 commit
  21. 08 Jan, 2018 1 commit
    • Thomas Haller's avatar
      tests: use NMTST_EXPECT*() macros · 25ade397
      Thomas Haller authored
      Tests are commonly created via copy&paste. Hence, it's
      better to express a certain concept explicitly via a function
      or macro. This way, the implementation of the concept can be
      adjusted at one place, without requiring to change all the callers.
      
      Also, the macro is shorter, and brevity is better for tests
      so it's easier to understand what the test does. Without being
      bothered by noise from the redundant information.
      
      Also, the macro knows better which message to expect. For example,
      messages inside "src" are prepended by nm-logging.c with a level
      and a timestamp. The expect macro is aware of that and tests for it
      
        #define NMTST_EXPECT_NM_ERROR(msg)      NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg)
      
      This again allows the caller to ignore this prefix, but still assert
      more strictly.
      25ade397
  22. 18 Dec, 2017 1 commit
  23. 07 Dec, 2017 2 commits
  24. 04 Dec, 2017 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: persist the wep key type · c6eb18ee
      Beniamino Galvani authored
      The wireless-security setting has a 'wep-key-type' property that is
      used to specify the WEP key type and is needed because some keys could
      be interpreted both as a passphrase or a hex/ascii key.
      
      The ifcfg-rh plugin currently stores the key type implicitly: if
      wep-key-type is 'passphrase' it uses the KEY_PASSPHRASE%d variable, if
      it's 'key' the KEY%d variable and when it's 'unknown' it uses either
      variables depending on the detected type (preferring 'key' in case
      both are compatible).
      
      This means that some connections will be read differently from how
      they were written, because once the KEY (or KEY_PASSPHRASE) is read
      there is no way to know whether the 'wep-key-type' property was 'key'
      (or 'passphrase') or 'unknown'.
      
      Fix this by persisting the key type explicitly in the file. The new
      variable is redundant in most cases because the variables used for
      keys also determine the key type.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1518177
      c6eb18ee
  25. 30 Nov, 2017 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: use different variables for IPv4 and IPv6 DNS options · 83797855
      Beniamino Galvani authored
      Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
      and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
      variable. This is wrong because writing a connection and reading it
      back gives a different connection compared to the original.
      
      This behavior existed since when DNS options were introduced, but it
      became more evident now that we reread the connection after write,
      because after doing a:
      
       $ nmcli connection modify ethie ipv4.dns-options ndots:2
      
      the connection has both ipv4.dns-options and ipv6.dns-options set. In
      order to delete the option, an user has to delete it from both
      settings:
      
       $ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""
      
      To improve this let's use different variables for IPv4 and IPv6. To
      keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
      uses a new IPV6_RES_OPTIONS variable.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1517794
      83797855
  26. 23 Nov, 2017 2 commits
    • Beniamino Galvani's avatar
      ifcfg-rh: use distinct variables for bridge and wired mac address · fb191fc2
      Beniamino Galvani authored
      Currently both bridge.mac-address and ethernet.cloned-mac-address get
      written to the same MACADDR ifcfg-rh variable; the ethernet property
      wins if both are present.
      
      When one property is set and the connection is saved (and thus reread)
      both properties are populated with the same value. This is wrong
      because, even if the properties have the same meaning, the setting
      plugin should not read something different from what was written. Also
      consider that after the following steps:
      
       $ nmcli con mod c ethernet.cloned-mac-address 00:11:22:33:44:55
       $ nmcli con mod c ethernet.cloned-mac-address ""
      
      the connection will still have the new mac address set in the
      bridge.mac-address property, which is certainly unexpected.
      
      In general, mapping multiple properties to the same variable is
      harmful and must be avoided. Therefore, let's use a different variable
      for bridge.mac-address. This changes behavior, but not so much:
      
       - connections that have MACADDR set will behave as before; the only
         difference will be that the MAC will be present in the wired
         setting instead of the bridge one;
      
       - initscripts compatibility is not relevant because MACADDR for
         bridges was a NM extension;
      
       - if someone creates a new connection and sets bridge.mac-address NM
         will set the BRIDGE_MACADDR property instead of MACADDR. But this
         shouldn't be a big concern as bridge.mac-address is documented as
         deprecated and should not be used for new connections.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1516659
      fb191fc2
    • Beniamino Galvani's avatar
      ifcfg-rh: read wired properties for bridge connections · 56a02c9b
      Beniamino Galvani authored
      A bridge connection can have ethernet settings, read them from the
      ifcfg file.
      56a02c9b
  27. 21 Nov, 2017 1 commit
  28. 13 Nov, 2017 1 commit
    • Thomas Haller's avatar
      all: support route-attribute "onlink" for IPv4 · 0ed49717
      Thomas Haller authored
      Kernel doesn't support it for IPv6.
      
      This is especially useful, if you combine static routes
      with DHCP. In that case, you might want to get the device-route
      to the gateway automatically, but add a static-route for it.
      0ed49717
  29. 06 Nov, 2017 2 commits
    • Beniamino Galvani's avatar
      ifcfg-rh: persist the connection type for TeamPort connections · 29371043
      Beniamino Galvani authored
      Currently the ifcfg-rh plugin doesn't explicitly store the connection
      type for team slaves and is only able to read back ethernet and vlan
      connections.
      
      Leave this unchanged for ethernet and vlan slaves, but store the TYPE
      variable for other connection types (Wi-Fi and Infiniband) so that we
      can properly determine their type when the connection is read.
      
      (cherry picked from commit 29a57649)
      29371043
    • Beniamino Galvani's avatar
      ifcfg-rh: persist the connection type for TeamPort connections · 29a57649
      Beniamino Galvani authored
      Currently the ifcfg-rh plugin doesn't explicitly store the connection
      type for team slaves and is only able to read back ethernet and vlan
      connections.
      
      Leave this unchanged for ethernet and vlan slaves, but store the TYPE
      variable for other connection types (Wi-Fi and Infiniband) so that we
      can properly determine their type when the connection is read.
      29a57649
  30. 31 Oct, 2017 2 commits
  31. 26 Oct, 2017 1 commit
    • Thomas Haller's avatar
      libnm: fix nm_connection_diff() for settings without properties · 6f94b165
      Thomas Haller authored
      NMSettingGeneric has no properties at all. Hence, nm_connection_diff() would report that
      a connection A with a generic setting and a connection B without a generic setting are
      equal.
      
      They are not. For empty settings, let nm_setting_diff() return also empty difference
      hash.
      6f94b165