NetworkManager-1.48.10

[Bruce Dubbs]

New point version.

[Rahul Chandra]

News file seems to have not been updated

[Rahul Chandra]

Fixed @
b48b457dda33bc97c766d419591d349be0733260 - nss-3.104
0ee4bb60ee19169489b46249443458b2119049e7 - cmake-3.30.3
49f6186744f62dca6d31699b0ba789f13e2bf819 - samba-4.21.0
656007f11ad4bcafeed1e8cdcda27cad23266996 - FreeRDP-3.8.0
105e194c31675117ba8bc566f27fcad5e6100ffe - wayland-protocols-1.37
73fd14d78c3b0a476d2cd7071e0d5272dce98f60 - json-glib-1.10.0
a6ed4673cbf8be72483cc8604cfc2ee5da1fd49a - sudo-1.9.16
a3c24abd8747c17722bc0e83b065cc0d073cce9f - NetworkManager-1.48.10
e80ea8bf0c945ac8fe2ced0155c3423d968c1f95 - power-profiles-daemon-0.22
5a7a4a1759875405091ab7ef117cb5c67ab14285 - xterm-394
af091eb6ee6d494b81e3aab251e8e09d4e368efa - dhcpcd-10.0.10

[Douglas R. Reno]

The only way to get release notes for NetworkManager point versions seems to be from git logs :(

Here's the one for 1.48.10:

policy: unblock the autoconnect for children when parent is available 
  When parent is available and in the process of activation, we should
  unblock the autoconnect and schedule an auto activate for the children.
  Notice that when the parent is the ovs-interface, the kernel link is
  only created in stage3, if we only unblock the children in the stage1,
  then the children device and connection will be blocked again due
  to the fact the kernel link for the parent ovs-interface is not
  existed yet, thus, we have to separately unblock the children
  when the parent ovs-interface is in the activated state.
lldp: fix crash dereferencing NULL pointer during debug logging 
  During nm_lldp_neighbor_parse(), the NMLldpNeighbor is not yet added to
  the NMLldpRX instance. Consequently, n->lldp_rx is NULL.
  Note how we use lldp_x for logging, because we need it for the context
  for which interface the logging statement is.
  Thus, those debug logging statements will follow a NULL pointer and lead
  to a crash.
lldp: fix multiple access to argument in logging macro 
merge: branch 'th/lldp-fix-crash' 
platform: add define for IFLA_BOND_SLAVE_PRIO 
  The enum value was added in kernel 5.19; add a define for it so that
  the compilation doesn't fail with earlier kernels.
bridge: change the signature for nm_platform_link_set_bridge_vlans() 
  Currently, nm_platform_link_set_bridge_vlans() accepts an array of
  pointers to vlan objects; to avoid multiple allocations,
  setting_vlans_to_platform() creates the array by piggybacking the
  actual data after the pointers array.
  In the next commits, the array will need to be manipulated and
  extended, which is difficult with the current structure. Instead, pass
  separately an array of objects and its size.
device: support reapplying bridge-port VLANs 
  For now, always reapply the VLANs unconditionally, even if they didn't
  change in kernel.
  To set again the VLANs on the port we need to clear all the existing
  one before. However, this deletes also the VLAN for the default-pvid
  on the bridge. Therefore, we need some additional logic to inject the
  default-pvid in the list of VLANs.
platform: support reading bridge VLANs 
  Add a function to read the list of bridge VLANs on an interface.
platform: add nmp_utils_bridge_normalized_vlans_equal() 
  Add a function to compare two arrays of NMPlatformBridgeVlan. It will
  be used in the next commit to compare the VLANs from platform to the
  ones we want to set.
  To compare in a performant way, the vlans need to be normalized (no
  duplicated VLANS, ranges into their minimal expression...). Add the
  function nmp_utils_bridge_vlan_normalize.
bridge: reapply port VLANs only when necessary 
  Don't touch the bridge VLANs if they are already set.
merge: branch 'bg/bridge-vlan-reapply' 
platform: add small backoff time before resync 
  If the socket's RX buffer is full it's probably because other
  process is doing lot of changes very quickly, faster than we
  can process them. Let's give the writer a small time to finish:
  1. Avoid contending the kernel's RTNL lock, so we don't make
     the whole situation even worse and it can finish earlier.
  2. Avoid having to resync again and again due to trying to
     resync while the writer is still doing quick changes, so
     we are unable to catch up yet.
  This won't help if this situation takes a long time or is
  continuous, but that's unlikely to happen, and if it does,
  it's the writer's fault for starving the whole system.
  There is no need to progresively increase the backoff time
  for the same reason: if this situation takes lot of time,
  it's the writer's fault. It's neither a good idea because the whole NM
  process will end being sleeping long times, not doing anything at all,
  without being able to react when the Netlink messages burst stops.
policy: retry hostname resolution when it fails 
  Currently if the system hostname can't be determined, NetworkManager
  only retries when something changes: a new address is added, the DHCP
  lease changes, etc.
  However, it might happen that the current failure in looking up the
  hostname is caused by an external factor, like a temporary outage of
  the DNS server.
  Add a mechanism to retry the resolution with an increasing timeout.
CI: fix Debian not including policykit-1 and remove EOL'd C8S 
format: run nm-code-format 
autotools: fix filename that was renamed 
CI: update the imported templates_sha 
gitlab: fix helper scripts to support DNF5 
autotools: fix another filename that was renamed 
nmcli/edit: fix memory leak in extract_setting_and_property 
  In case the user selects a setting/property with "goto" command, and
  then attempts to tab-complete a setting/property pair, the original sett
  and prop strings are overriden without freeing:
  nmcli > goto 802-1x.pac-file
  nmcli 802-1x.pac-file> set 802-1.lal<TAB>
release: bump version to 1.48.10