1. 28 May, 2019 2 commits
  2. 18 Apr, 2019 5 commits
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · 284ac92e
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      "libnm".
      
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      duplicated.
      
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
      
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
      
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
      
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
           nmcli).
      
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      twice.
      
      (cherry picked from commit af07ed01)
      284ac92e
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      
      (cherry picked from commit 80db06f7)
      d984b2ce
    • Thomas Haller's avatar
      ifcfg-rh: use nm_utils_escaped_tokens* for "MATCH_INTERFACE_NAME" · 93eb40ed
      Thomas Haller authored
      For one, use NM_ASCII_SPACES as delimiter when reading
      "MATCH_INTERFACE_NAME". Previously, it was only " \t".
      
      I think there is no change in behavior otherwise.
      
      (cherry picked from commit 941f27d3)
      93eb40ed
    • Beniamino Galvani's avatar
      all: use escaped_tokens API for bridge vlans · 6ac953e9
      Beniamino Galvani authored
      (cherry picked from commit 9f23c5e2)
      6ac953e9
    • Beniamino Galvani's avatar
      all: support bridge vlan ranges · da204257
      Beniamino Galvani authored
      In some cases it is convenient to specify ranges of bridge vlans, as
      already supported by iproute2 and natively by kernel. With this commit
      it becomes possible to add a range in this way:
      
       nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged"
      
      vlan ranges can't be PVIDs because only one PVID vlan can exist.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1652910
      (cherry picked from commit 70935157)
      da204257
  3. 27 Mar, 2019 1 commit
    • Thomas Haller's avatar
      ifcfg-rh: add support for routing rules as "ROUTING_RULE_#" keys · 4d468044
      Thomas Haller authored
      initscripts support rule-* and rule6-* files for that.
      
      Up until now, we ignored these files for the most part, except if
      a user configured such files, the profile could not contain any static
      routes (or specify a route-table setting). This also worked together
      with the dispatcher script "examples/dispatcher/10-ifcfg-rh-routes.sh".
      
      We cannot now start taking over that file format for rules. It might
      break existing setups, because we can never fully understand all rules as
      they are understood by iproute2. Also, if a user has a rule/rule6 file and
      uses NetworkManager successfully today, then clearly there is a script
      in place to make that work. We must not break that when adding rules
      support.
      
      Hence, store routing rules as numbered "ROUTING_RULE_#" and
      "ROUTING_RULE6_#" keys.
      
      Note that we use different keys for IPv4 and IPv6. The main reason is
      that the string format is mostly compatible with iproute2. That means,
      you can take the value and pass it to `ip rule add`.
      However, `ip rule add` only accepts IPv4 rules. For IPv6 rules, the user
      needs to call `ip -6 rule add`. If we would use the same key for IPv4
      and IPv6, then it would be hard to write a script to do this.
      Also, nm_ip_routing_rule_from_string() does take the address family as
      hint in this case. This makes
      
        ROUTING_RULE_1="pref 1"
        ROUTING_RULE6_1="pref 1"
      
      automatically determine that address families. Otherwise, such
      abbreviated forms would be not valid.
      4d468044
  4. 26 Mar, 2019 2 commits
  5. 12 Feb, 2019 1 commit
  6. 05 Feb, 2019 1 commit
  7. 12 Dec, 2018 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: fix persisting sriov setting · d48f389c
      Beniamino Galvani authored
      The writer should write all properties of the sriov setting when the
      setting exists without additional logic. Likewise, the reader should
      instantiate a sriov setting when any sriov key is present and blindly
      set properties from keys.
      
      The old code did not always preserve the presence of a sriov setting
      after a write/read cycle.
      
      Fixes: c02d1c48
      d48f389c
  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. 06 Sep, 2018 1 commit
  10. 04 Sep, 2018 1 commit
  11. 11 Aug, 2018 1 commit
  12. 10 Aug, 2018 4 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: always reset ETHTOOL_WAKE_ON_LAN value · 64e0e241
      Thomas Haller authored
      We must always set all variables, because othewise a previously set
      value might be merged into the new setting.
      64e0e241
    • Thomas Haller's avatar
      ifcfg-rh: split setting ETHTOOL_OPTS from write_wired_setting() · cd442112
      Thomas Haller authored
      Will be used later, because we will not only have ethtool options
      in conjunction with wired settings.
      cd442112
    • Thomas Haller's avatar
      ifcfg-rh: cleanup write_wired_setting() · 1bcf1047
      Thomas Haller authored
      Drop some local variables, or move them inside a nested scope,
      closer to where they are used.
      1bcf1047
  13. 08 Aug, 2018 1 commit
    • Thomas Haller's avatar
      all: add connection.multi-connect property for wildcard profiles · 55ae6923
      Thomas Haller authored
      Add a new option that allows to activate a profile multiple times
      (at the same time). Previoulsy, all profiles were implicitly
      NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
      a profile that is already active will deactivate it first.
      
      This will make more sense, as we also add more match-options how
      profiles can be restricted to particular devices. We already have
      connection.type, connection.interface-name, and (ethernet|wifi).mac-address
      to restrict a profile to particular devices. For example, it is however
      not possible to specify a wildcard like "eth*" to match a profile to
      a set of devices by interface-name. That is another missing feature,
      and once we extend the matching capabilities, it makes more sense to
      activate a profile multiple times.
      
      See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
      previously changed that a connection is restricted to a single activation
      at a time. This work relaxes that again.
      
      This only adds the new property, it is not used nor implemented yet.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1555012
      55ae6923
  14. 11 Jul, 2018 2 commits
    • Beniamino Galvani's avatar
      ifcfg-rh: SR-IOV support · c02d1c48
      Beniamino Galvani authored
      c02d1c48
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
      
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          587
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          21114
      
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
      
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      
      A simple style guide is instead: don't use these typedefs.
      
      No manual actions, I only ran the bash script:
      
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
            "${FILES[@]}"
      e1c7a2b5
  15. 15 Jun, 2018 1 commit
  16. 09 Jun, 2018 1 commit
  17. 30 Apr, 2018 1 commit
  18. 18 Apr, 2018 1 commit
  19. 27 Mar, 2018 1 commit
  20. 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
  21. 18 Jan, 2018 3 commits
  22. 16 Jan, 2018 1 commit
    • Masashi Honma's avatar
      wifi: add support for FILS · b4bbe517
      Masashi Honma authored
      The FILS(Fast Initial Link Setup) is a specification defined by IEEE 802.11ai to
      speed up roaming. This patch adds support of it.
      
      I have tested with these cases.
      +-----+-------------------------+----------------+
      | STA |            AP           |                |
      |FILS |         key-mgmt        |     result     |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP                 |       O        |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP-SHA256          |       O        |
      +-----+-------------------------+----------------+
      |  1  | FILS-SHA256             |       X        |
      +-----+-------------------------+----------------+
      |  1  | FILS-SHA384             |       X        |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | WPA-EAP-SHA256 |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP                 |       O        |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP-SHA256          |       O        |
      +-----+-------------------------+----------------+
      |  2  | FILS-SHA256             |       O        |
      +-----+-------------------------+----------------+
      |  2  | FILS-SHA384             |       O        |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | FILS-SHA384    |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP                 |       X        |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP-SHA256          |       X        |
      +-----+-------------------------+----------------+
      |  3  | FILS-SHA256             |       O        |
      +-----+-------------------------+----------------+
      |  3  | FILS-SHA384             |       O        |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | FILS-SHA384    |
      +-----+-------------------------+----------------+
      Signed-off-by: 's avatarMasashi Honma <masashi.honma@gmail.com>
      b4bbe517
  23. 09 Jan, 2018 3 commits
    • Thomas Haller's avatar
      core: implement setting MDNS setting for systemd · c03a5349
      Thomas Haller authored
      The connection.mdns setting is a per-connection setting,
      so one might expect that one activated device can only have
      one MDNS setting at a time.
      
      However, with certain VPN plugins (those that don't have their
      own IP interface, like libreswan), the VPN configuration is merged
      into the configuration of the device. So, in this case, there
      might be multiple settings for one device that must be merged.
      
      We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config
      track this piece of information. Although, stricitly speaking this
      is not tied to IPv4, the alternative would be to introduce a new
      object to track such data, which would be a tremendous effort
      and more complicated then this.
      
      Luckily, NMDnsManager and NMDnsPlugin are already equipped to
      handle multiple NMIPConfig instances per device (IPv4 vs. IPv6,
      and Device vs. VPN).
      
      Also make "connection.mdns" configurable via global defaults in
      NetworkManager.conf.
      c03a5349
    • Thomas Haller's avatar
      libnm: rename MDns flag UNKNOWN to DEFAULT · 9d92848a
      Thomas Haller authored
      "UNKNOWN" is not a good name. If you don't set the property
      in the connection explicitly, it should be "DEFAULT".
      
      Also, make "DEFAULT" -1. For one, that ensures that the enum's
      underlying integer type is signed. Otherwise, it's cumbersome
      to test "if (mdns >= DEFAULT)" because in case of unsigned types,
      the compiler will warn about the check always being true.
      Also, it allows for "NO" to be zero. These are no strong reasons,
      but I tend to think this is better.
      
      Also, don't make the property of NMSettingConnection a CONSTRUCT property.
      Initialize the default manually in the init function.
      
      Also, order the numeric values so that DEFAULT < NO < RESOLVE < YES with
      YES being largest because it enables *the most*.
      9d92848a
    • Ismo Puustinen's avatar
      mdns: add new connection property. · 2e2ff6f2
      Ismo Puustinen authored
      Add support for mDNS as a connection-level property. Update ifcfg-rh and
      keyfile plugins to support it.
      2e2ff6f2
  24. 18 Dec, 2017 1 commit
  25. 11 Dec, 2017 1 commit
    • Lubomir Rintel's avatar
      ifcfg-rh: add tc support · 902bbfdb
      Lubomir Rintel authored
      Format:
      
        QDISC1=ingress
        QDISC2="root handle 1234: fq_codel"
        FILTER1="parent ffff: matchall action simple sdata Input"
        FILTER2="parent 1234: matchall action simple sdata Output"
      902bbfdb