1. 28 May, 2019 2 commits
  2. 12 Feb, 2019 1 commit
  3. 05 Feb, 2019 1 commit
  4. 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
  5. 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
  6. 06 Sep, 2018 1 commit
  7. 04 Sep, 2018 1 commit
  8. 11 Aug, 2018 1 commit
  9. 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
  10. 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
  11. 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
  12. 15 Jun, 2018 1 commit
  13. 09 Jun, 2018 1 commit
  14. 30 Apr, 2018 1 commit
  15. 18 Apr, 2018 1 commit
  16. 27 Mar, 2018 1 commit
  17. 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
  18. 18 Jan, 2018 3 commits
  19. 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
  20. 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
  21. 18 Dec, 2017 1 commit
  22. 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
  23. 07 Dec, 2017 1 commit
  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 1 commit
    • 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
  27. 21 Nov, 2017 2 commits
  28. 15 Nov, 2017 1 commit
    • Thomas Haller's avatar
      ifcfg-rh: avoid coverity false positive in write_secrets() · cfdb962e
      Thomas Haller authored
      Comparing @secrets_keys indicates to coverity that it might be NULL.
      Below, we access @secrets_keys without check, and coverity doesn't realize
      that this cannot crash, because secrets_keys_n would be zero too.
      
      Anyway, this way we safe the sorting, in case we only have
      one element.
      cfdb962e
  29. 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