Before we talk about IV Update, let us finish the Key Refresh story. The Key Refresh procedure has three phases. By the time we reach Phase 3, every non-blacklisted node already has the new keys installed. Phase 3 is purely about telling everyone to stop using the old keys.

How Phase 3 works:

Key Refresh state after each phase:

Important notes:

• After revocation, the node ignores any beacon still using the new NetKey with flag=1
• Low Power nodes may lag behind because they depend on Friend nodes. The Configuration Client must account for this
• A newly provisioned node that never had the old keys simply skips the revocation step

BlueZ: Trigger Phase 3 via mesh-cfgclient

# Connect to the mesh daemon
mesh-cfgclient

# Inside mesh-cfgclient: send Key Refresh Phase Set with transition 0x03
# This tells the target node to move to Phase 3 and revoke old keys
# Syntax: kr-phase-set <node_unicast_addr> <net_index> <transition>
kr-phase-set 0x0005 0x0000 3

# Confirm the current phase on the node
kr-phase-get 0x0005 0x0000

The kr-phase-set command maps to the Config Key Refresh Phase Set message in the spec. Transition value 3 = move to Phase 3.

Bluetooth Mesh uses AES-CCM encryption at both the application and network layers. AES-CCM requires a unique value called a nonce for every single encrypted packet. If the same nonce is ever used twice with the same key, an attacker can break the encryption.

What makes up a Mesh nonce?

The SEQ number is only 3 bytes = about 16 million possible values. A busy node sending many messages per second will eventually exhaust this range. When that happens, the IV Index must be incremented so SEQ can safely reset to zero without reusing a nonce combination.

The IV Update procedure uses two operating states. The transition between them is controlled by the IV Update Flag carried in Secure Network beacons and Friend Update messages.

Summary Table (Table 3.57 from spec):

The key design insight: During the “In Progress” state the node still transmits using the OLD index (m−1). This gives every other node in the network time to catch up and learn the new IV Index before the transmitting node actually switches over.

The IV Update procedure has strict time constraints to prevent rapid cycling and ensure all nodes get enough time to synchronise.

IV Update timeline for a single cycle:

Let us trace through a complete IV Update cycle using the example values from the specification.

Notice at step 2: even though the stored IV Index is 0x00101848, the node still sends using the old 0x00101847. This ensures nodes that are still in Normal Operation (using the old index) can still receive packets from this node.

BlueZ: Observe IV Index in mesh daemon logs

# Run bluetoothd with mesh daemon in verbose mode
sudo bluetoothd -n -d &

# Watch syslog for IV Update events
sudo journalctl -u bluetooth -f | grep -i "iv\|mesh"

# Or check the mesh node storage file (BlueZ stores mesh state in JSON)
cat /var/lib/bluetooth/<adapter_addr>/<node_uuid>/node.json | python3 -m json.tool | grep -i "iv"

# Example node.json excerpt showing IV Index
{
  "IVIndex": 1053767,        /* 0x00101847 in decimal */
  "IVUpdate": false,         /* false = Normal Operation */
  "SequenceNumber": 4096
}

Imagine a sensor node that has been sleeping for several months. When it wakes up, the mesh network may have already completed multiple IV Update cycles. The node’s stored IV Index is now stale — it cannot communicate until it learns the current IV Index.

Recovery flow:

Sometimes you need to permanently remove a node — it was stolen, it failed, or it belongs to an employee who left. Simply powering it off is not enough. The other nodes still trust its credentials.

The correct removal flow:

BlueZ: Remove a node from a mesh network

# In mesh-cfgclient, reset the node (sends Config Node Reset message)
# This instructs the node to remove itself; works only if node is reachable
node-reset 0x0005

# If node is unreachable (lost/stolen), remove it locally from Provisioner DB
# BlueZ stores provisioner data in /var/lib/bluetooth/<addr>/
# Edit or delete the node entry from the mesh network JSON config
# Then run Key Refresh manually for remaining nodes

# Verify it's gone from the provisioner's known nodes list
list-nodes

In production, you must wait 96 hours between IV Update state changes. That makes automated testing painful. The spec defines an IV Update test mode specifically for the Bluetooth Qualification Process.

Test mode is activated locally — via a hardware pin or software interface on the device under test. All other mesh behaviour stays exactly the same; only the 96-hour gate is removed.

BlueZ: Enable IV Update test mode

# BlueZ exposes IV Update test mode via the D-Bus mesh network interface
# This is typically done programmatically using gdbus or a Python script

# Using gdbus command line:
gdbus call --system \
  --dest org.bluez.mesh \
  --object-path /org/bluez/mesh \
  --method org.bluez.mesh.Network1.SetIVUpdateTestMode \
  true

# To trigger IV Update in Progress immediately (test mode active):
gdbus call --system \
  --dest org.bluez.mesh \
  --object-path /org/bluez/mesh/node/<node_path> \
  --method org.bluez.mesh.Node1.SetIVUpdateTestMode \
  true

# Python3 snippet using dbus module (for automated test scripts)
import dbus

bus = dbus.SystemBus()
mesh_mgr = bus.get_object('org.bluez.mesh', '/org/bluez/mesh')
iface = dbus.Interface(mesh_mgr, 'org.bluez.mesh.Network1')

# Enable test mode
iface.SetIVUpdateTestMode(dbus.Boolean(True))
print("IV Update test mode enabled — 96h limits removed")