1. 25 Jan, 2017 2 commits
    • Thomas Haller's avatar
      core: refactor parsing in match_device_s390_subchannels_parse() · 419151a1
      Thomas Haller authored
        - match_device_s390_subchannels_parse() should accept un-initialized
          arguments a,b,c, as they are striclty output arguments (without
          transfering ownership).
        - the output arguments should be set if (and only if) the function
          succeeds. That is, move assigning the output arguments to the end.
        - increase the BUFSIZE. It's unclear why choosing 10. Probably that
          was already sufficient as a subchannel looks like
          "0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
          If we want to restrict the parsing based on the lenght of the input,
          that should be done explicitly (but that seems not desirable).
        - use _nm_utils_ascii_str_to_int64() which checks that the range
          of the values fits in guint32.
      It seems wrong that match_device_s390_subchannels_eval() only compares
      the first of up to three subchannels. But leave it as is for now.
    • Lubomir Rintel's avatar
      core: add missing initializers to match_data_s390_subchannels_eval() · 20328ead
      Lubomir Rintel authored
      match_device_s390_subchannels_parse() asserts that arguments point to
        1299     static gboolean
        1300     match_data_s390_subchannels_eval (const char *spec_str,
        1301                                       MatchDeviceData *match_data)
        1302     {
        >>>     CID 160923:  Uninitialized variables  (UNINIT)
        >>>     Declaring variable "c" without initializer.
        1303            guint32 a, b, c;
      Fixes: b0aaff86
  2. 23 Jan, 2017 1 commit
  3. 21 Jan, 2017 1 commit
  4. 20 Jan, 2017 1 commit
    • Thomas Haller's avatar
      core: refactor evaluation of device's match-spec · b957403e
      Thomas Haller authored
      Previously, we would have different functions like
        - nm_match_spec_device_type()
        - nm_match_spec_hwaddr()
        - nm_match_spec_s390_subchannels()
        - nm_match_spec_interface_name()
      which all would handle one type of match-spec.
      So, to get the overall result whether the arguments
      match or not, nm_device_spec_match_list() had to stich
      them together and iterate the list multiple times.
      Refactor the code to have one nm_match_spec_device()
      function that gets all relevant paramters.
      The upside is:
        - the logic how to evaluate the match-spec is all at one place
          (match_device_eval()) instead of spread over multiple
        - It requires iterating the list at most twice. Twice, because
          we do a fast pre-search for "*".
      One downside could be, that we have to pass all 4 arguments
      for the evaluation, even if the might no be needed. That is,
      because "nm-core-utils.c" shall be independend from NMDevice, it
      cannot receive a device instance to get the parameters as needed.
      As we would add new match-types, the argument list would grow.
      However, all arguments are cached and fetching them from the
      device's private data is very cheap.
  5. 09 Jan, 2017 3 commits
    • Thomas Haller's avatar
      device: support dynamic "connection.stable-id" in form of text-substitution · f0d40525
      Thomas Haller authored
      Usecase: when connecting to a public Wi-Fi with MAC address randomization
      ("wifi.cloned-mac-address=random") you get on every re-connect a new
      IP address due to the changing MAC address.
      "wifi.cloned-mac-address=stable" is the solution for that. But that
      means, every time when reconnecting to this network, the same ID will
      be reused. We want an ID that is stable for a while, but at a later
      point a new ID should e generated when revisiting the Wi-Fi network.
      Extend the stable-id to become dynamic and support templates/substitutions.
      Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
      Any unrecognized pattern is treated verbaim/untranslated.
      "$$" is treated special to allow escaping the '$' character. This allows
      the user to still embed verbatim '$' characters with the guarantee that
      future versions of NetworkManager will still generate the same ID.
      Of course, a user could just avoid '$' in the stable-id unless using
      it for dynamic substitutions.
      Later we might want to add more recognized substitutions. For example, it
      could be useful to generate new IDs based on the current time. The ${} syntax
      is extendable to support arguments like "${PERIODIC:weekly}".
      Also allow "connection.stable-id" to be set as global default value.
      Previously that made no sense because the stable-id was static
      and is anyway strongly tied to the identity of the connection profile.
      Now, with dynamic stable-ids it gets much more useful to specify
      a global default.
      Note that pre-existing stable-ids don't change and still generate
      the same addresses -- unless they contain one of the new ${} patterns.
    • Thomas Haller's avatar
      core: add assertions for network_id/stable_type · 21ae09c1
      Thomas Haller authored
      We require a network-id. Assert that it is set.
      Also, we encode the stable-id as uint8. Thus, add
      an assertion that we don't use more then 254 IDs.
      If we ever make use of stable-type 255, we must extend
      the encoding to allow for more values. The assertion
      is there to catch that.
    • Thomas Haller's avatar
  6. 06 Jan, 2017 1 commit
  7. 05 Jan, 2017 1 commit
  8. 13 Dec, 2016 2 commits
  9. 06 Dec, 2016 3 commits
  10. 09 Nov, 2016 1 commit
    • Lubomir Rintel's avatar
      utils: allow valid_lft=0 addresses · 2dd384c8
      Lubomir Rintel authored
      We use the lifetime of 0 to indicate permanent addresses while
      DHCP uses that lifetime to indicate the addresses should be removed.
      Use the presence of a timestamp to differentiate the two.
        dhclient[10867]: XMT: Rebind on wls1, interval 1030ms.
        dhclient[10867]: RCV: Reply message on wls1 from fe80::21e:8cff:feec:3ca2.
        NetworkManager[10481]: <info>  [1478020967.7634] dhcp6 (wls1):   valid_lft 0
        NetworkManager[10481]: <info>  [1478020967.7634] dhcp6 (wls1):   preferred_lft 0
        NetworkManager[10481]: <info>  [1478020967.7636] dhcp6 (wls1):   address fd25:d463:2f14::927
        NetworkManager[10481]: <info>  [1478020967.7636] dhcp6 (wls1):   nameserver 'fe80::21e:8cff:feec:3ca2'
        NetworkManager[10481]: <info>  [1478020967.7637] dhcp (wls1):   domain search 'venom.'
        NetworkManager[10481]: <info>  [1478020967.7637] dhcp6 (wls1): state changed unknown -> bound, event ID="fa:cd:2c:86|1478020967"
        NetworkManager[10481]: ((src/nm-core-utils.c:3521)): assertion '<dropped>' failed
  11. 28 Oct, 2016 1 commit
    • Thomas Haller's avatar
      libnm-core/utils: update hwaddr utilities · e5fe5a4c
      Thomas Haller authored
      _nm_utils_hwaddr_length() did a validation of the string
      and returned the length of the address. In all cases where
      we were interested in that, we also either want to validate
      the address, get the address in binary form, or canonicalize
      the address.
      We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton()
      which both does the parsing and returning the length.
  12. 21 Oct, 2016 1 commit
  13. 12 Oct, 2016 1 commit
    • Beniamino Galvani's avatar
      core: introduce and use nm_utils_file_set_contents() · 21358edc
      Beniamino Galvani authored
      In some places we use g_file_set_contents() after a umask() to limit
      the permissions of the created file. Unfortunately if the containing
      directory has a default ACL the umask will be ignored and the new file
      will have a mode equal to the default ACL (since g_file_set_contents()
      opens the file with mode 0666).
      Calling a chmod() after the file gets created is insecure (see commit
      60b7ed3b) and so the only solution seems to be to reimplement
      g_file_set_contents() and accept a mode as parameter.
      We already had similar functions in the tree, consolidate them into a
      new generic utility function.
  14. 03 Oct, 2016 1 commit
  15. 01 Oct, 2016 1 commit
  16. 30 Jun, 2016 8 commits
    • Thomas Haller's avatar
      all: make MAC address randomization algorithm configurable · 96cabbcb
      Thomas Haller authored
      For the per-connection settings "ethernet.cloned-mac-address"
      and "wifi.cloned-mac-address", and for the per-device setting
      "wifi.scan-rand-mac-address", we may generate MAC addresses using
      either the "random" or "stable" algorithm.
      Add new properties "generate-mac-address-mask" that allow to configure
      which bits of the MAC address will be scrambled.
      By default, the "random" and "stable" algorithms scamble all bits
      of the MAC address, including the OUI part and generate a locally-
      administered, unicast address.
      By specifying a MAC address mask, we can now configure to perserve
      parts of the current MAC address of the device. For example, setting
      "FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
      MAC address.
      One can also explicitly specify a MAC address to use instead of the
      current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
      sets the OUI part of the MAC address to "68:F7:28" while scrambling
      the last 3 octects.
      Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
      all bits of the MAC address, except clearing the second-least
      significant bit. Thus, creating a burned-in address, globally
      One can also supply a list of MAC addresses like
      "FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
      case a MAC address is choosen randomly.
      To fully scamble the MAC address one can configure
      "02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
      which also randomly creates either a locally or globally administered
      With this, the following macchanger options can be implemented:
        `macchanger --random`
         This is the default if no mask is configured.
         -> ""
         while is the same as:
         -> "00:00:00:00:00:00"
         -> "02:00:00:00:00:00 02:00:00:00:00:00"
        `macchanger --random --bia`
         -> "02:00:00:00:00:00 00:00:00:00:00:00"
        `macchanger --ending`
         This option cannot be fully implemented, because macchanger
         uses the current MAC address but also implies --bia.
         -> "FF:FF:FF:00:00:00"
            This would yields the same result only if the current MAC address
            is already a burned-in address too. Otherwise, it has not the same
            effect as --ending.
         -> "FF:FF:FF:00:00:00 <MAC_ADDR>"
            Alternatively, instead of using the current MAC address,
            spell the OUI part out. But again, that is not really the
            same as macchanger does because you explictly have to name
            the OUI part to use.
        `machanger --another`
        `machanger --another_any`
        -> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
           "$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
    • Thomas Haller's avatar
      device: extend MAC address handling including randomization for ethernet and wifi · 8eed6712
      Thomas Haller authored
      Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
      settings. Instead of specifying an explicit MAC address, the additional
      special values "permanent", "preserve", "random", "random-bia", "stable" and
      "stable-bia" are supported.
      "permanent" means to use the permanent hardware address. Previously that
      was the default if no explict cloned-mac-address was set. The default is
      thus still "permanent", but it can be overwritten by global
      "preserve" means not to configure the MAC address when activating the
      device. That was actually the default behavior before introducing MAC
      address handling with commit 1b49f941.
      "random" and "random-bia" use a randomized MAC address for each
      connection. "stable" and "stable-bia" use a generated, stable
      address based on some token. The "bia" suffix says to generate a
      burned-in address. The stable method by default uses as token the
      connection UUID, but the token can be explicitly choosen via
      "stable:<TOKEN>" and "stable-bia:<TOKEN>".
      On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
      cannot express the new forms. It is replaced by the new
      "assigned-mac-address" field. For the GObject property, libnm's API,
      nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
      Deprecating the old field seems more complicated then just extending
      the use of the existing "cloned-mac-address" field, although the name
      doesn't match well with the extended meaning.
      There is some overlap with the "wifi.mac-address-randomization" setting.
    • Thomas Haller's avatar
      core: use nm_utils_read_urandom() in nm_utils_secret_key_read() · 83d23177
      Thomas Haller authored
      nm_utils_read_urandom() repeats on EINTR and repeats for partial reads.
    • Thomas Haller's avatar
      core: add utils for file handling · dcc8de16
      Thomas Haller authored
      Copied and adjusted from systemd code.
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      core: prefer connection.stable-id to generate IPv6 stable privacy addresses · 0a5af391
      Thomas Haller authored
      The Network_ID for generating RFC 7217 stable privacy IPv6 addresses
      is by default the UUID of the connection.
      Alternatively, prefer "connection.stable-id" as Network_ID to generate
      the stable addresses. This allows to configure a set of connections that
      all use the same Network_ID for generating stable addresses.
      Note that the stable-id and the UUID do no overlap, that is two
      generate distinct addresses.
    • Thomas Haller's avatar
      rdisc/trivial: rename @uuid field to @network_id · 0df5e9b7
      Thomas Haller authored
      Next we will optionally use a stable-id instead of the UUID. Rename it.
      Also, RFC 7217 calls this argument Network_ID.
  17. 28 Jun, 2016 3 commits
  18. 07 Jun, 2016 2 commits
  19. 03 Jun, 2016 1 commit
  20. 30 May, 2016 2 commits
  21. 12 May, 2016 2 commits
  22. 02 May, 2016 1 commit