1. 03 Nov, 2016 13 commits
  2. 02 Nov, 2016 5 commits
  3. 01 Nov, 2016 4 commits
  4. 31 Oct, 2016 1 commit
  5. 28 Oct, 2016 12 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      device: suppress log message in nm_device_update_hw_address() when no MAC address · 0e0018c8
      Thomas Haller authored
      For example for tun devices we get a lot of
      
        (tun7): hw-addr: failed reading current MAC address
      
      warnings. Just be silent about it. We log when something
      changes, we don't need to log when we fail to obtain
      a MAC address.
      
      Thereby, refactor nm_device_update_hw_address() to return early.
      0e0018c8
    • Thomas Haller's avatar
      device: don't evaluate IP config changes until device is initialized · 31ca7962
      Thomas Haller authored
      The unmanaged flags PLATFORM_INIT indicates whether UDEV is done
      initializing the device. We should not handle IP config changes
      before that pointer.
      
      This avoids codepaths that require the permanent MAC address of the
      device. We should not freeze the permanent MAC address before
      UDEV initialized the device, for two reasons:
      
      - getting the permanent MAC address using ethtool is racy as
        UDEV might still rename the interface.
      - freezing a fake permanent MAC address should only happen after
        UDEV is done configuring the MAC address of software devices.
      
          #0  0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817
          #1  0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0)
              at src/devices/nm-device.c:12227
          #2  0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237
          #3  0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294
          #4  0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461
          #5  0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277
          #6  0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169
          #7  0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234
          #8  0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142
          #9  0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161
          #10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0)
              at src/devices/nm-device.c:4787
          #11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532
          #12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651
          #13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154
          #14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769
          #15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
          #16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034
          #17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
      31ca7962
    • Thomas Haller's avatar
      device: delay evaluating unmanaged-by-user-settings flags until link initialized · c0d249b7
      Thomas Haller authored
      Before the link is initialized, that is before UDEV completed
      initializing the device, we should not evaluate the user-settings
      unmanaged flags.
      
      The reason is, that evaluating it likely involves looking at the
      permanent MAC address, which might use the wrong fake MAC address
      (before UDEV set the right one). Also, it might use the wrong ifname
      to lookup the permanent MAC address via ethtool.
      c0d249b7
    • Thomas Haller's avatar
      device: delay capturing permanent MAC address until UDEV is settled · 7b7c653c
      Thomas Haller authored
      The permanent MAC address of an NMDevice shall not change as
      long as the device is realized. That is, we read it only once
      and don't change it afterwards.
      
      There are two issues that this commit tries to mitigate:
      
      (1) users are advised to use UDEV to rename interfaces. As we lookup
        the permenent MAC address using ethtool (which uses the interface
        name), there is a race where we could read the permanent MAC
        address using the wrong interface name. We should wait until
        UDEV finished initializing the device and until the interface
        name is stable (see rh#1388286).
        This commit still cannot avoid the race of ethtool entirely. It only
        tries to avoid ethtool until UDEV has done its work. That is, until we
        expect the interface name no longer to change.
      
      (2) some device types, don't have a permanent MAC address so we fall
        back to use the currently set address (fake). Again, users are advised
        to use UDEV to configure the MAC addresses on such software devices.
        Thus, we should not get the fake MAC address until UDEV initialized
        the device.
      
      This patch actually doesn't solve the problem at all yet.
      The reason is that a regular caller of nm_device_get_permanent_hw_address() can
      not afford to wait until UDEV settled. Thus, any user who requests the
      permanent MAC address before the link is initialized, runs into the
      problems above.
      
      In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address()
      and delay them until the link is initialized.
      7b7c653c
    • Thomas Haller's avatar
      device: don't allow mutating the device's hardware address length · cbea1f9f
      Thomas Haller authored
      We repeatedly call nm_device_update_hw_address() to reset the cached
      MAC address of the device. However, we don't allow changing the address
      length once it is set.
      
      Multiple entities (initial, current and permanent MAC address) are all
      checked to have the same address length. Changing the length would be a
      very strange thing (and probably indicate a bug somewhere else).
      
      Just don't allow that.
      cbea1f9f
    • Thomas Haller's avatar
      device: treat fake permanent MAC address mostly like a real one · 416164aa
      Thomas Haller authored
      Now that we persist the fake permanent address across
      restart of NetworkManager, we want to consider fake
      addresses as good enough in most cases.
      416164aa
    • Thomas Haller's avatar
      core: persist the fake permanent hardware address to the device's statefile · 5912b2f9
      Thomas Haller authored
      On devices that have no real permanent hardware address (as returned
      by ethtool), we take the current MAC address of the device.
      
      Currently, NM is a bit flaky about whether to accept such fake permanent
      addresses for settings like keyfile.unmanaged-devices or the per-
      connection property ethernet.mac-address. Probably, we should allow
      using fake addresses there in general.
      
      However, that leads to problems because NetworkManager itself changes
      the current MAC address of such devices. For example when
      configuing
      
        keyfile.unmanaged-device=22:33:44:55:66:77
      
      and later activating a connection with
      
        ethernet.cloned-mac-address=22:33:44:55:66:77
      
      we have a strange situation after restart and the device becomes
      unmanaged.
      
      We are going to avoid that, by remembering the fake permanent address
      in the device state file.
      
      This only matters:
      
        - for devices that don't have a real permanent address (veth)
      
        - if the user or NetworkManager itself changed the MAC address
          of the device
      
        - after a restart of NetworkManager, without reboot. A reboot
          clears the device state for /var/run/NetworkManager.
      5912b2f9
    • 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.
      e5fe5a4c
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      shared: add nm_assert_se() macro · ba950ced
      Thomas Haller authored
      We usually don't build NM with g_assert() disabled (G_DISABLE_ASSERT).
      But even if we would, there is no assertion macro that always evaluates
      the condition for possible side effects.
      
      I think that is a useful thing to have.
      ba950ced
    • Beniamino Galvani's avatar
      manager: allow slave connection to auto-connect its slaves · 632dd262
      Beniamino Galvani authored
      Since connection.autoconnect-slaves was introduced, we only allowed it
      to autoactivate slaves for connections that were not slave themselves.
      
      It seems useful to remove such limitation, but we must prevent an
      infinite loop if there is a circular dependency between connections.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1360386
      632dd262
  6. 27 Oct, 2016 5 commits