When the lower transport layer receives an Upper Transport PDU that is too large for a single packet, it slices it into chunks of up to 8 bytes each and wraps each chunk in a Lower Transport header.

Every segment carries three critical fields in its header:

• SeqZero — which transaction does this segment belong to?
• SegO — which chunk number is this? (starts at 0)
• SegN — what is the last chunk’s number? (tells receiver total count)

Carrying SegN in every single segment is intentional. Even if you receive segment #3 first, you immediately know the full message spans SegN+1 chunks and can allocate the right buffer size before any other segments arrive.

The mesh network needs a way to identify each unique segmented transaction so it can detect retransmissions and discarded messages. That identifier is SeqAuth.

Why SeqZero instead of the full SEQ? Segment headers have limited space. SeqZero is a 13-bit slice of SEQ that fits in the header. The receiver reconstructs the full SeqAuth by combining SeqZero with the known IV Index and the most recently seen SEQ value — this works reliably as long as the receiver hasn’t moved 8192 sequence numbers ahead of the sender.

Sender behaviour after segmenting a message depends entirely on the destination address type:

If the ack timer fires before all segments arrive, a partial BlockAck is sent. The sender reads which bits are still 0 and retransmits only those segments, not the entire message.

BlockAck is a 32-bit field. Each bit position N represents segment N. Bit = 1 means received. Bit = 0 means missing. One 4-byte field can cover up to 32 segments, which is the maximum for a single segmented message.

Three timers govern the whole segmentation protocol. If you ever debug mesh transport issues in BlueZ, these are the first numbers to check.

Here is exactly what happens on the receiving node when a segmented message comes in:

A Low Power node (LPN) turns off its radio most of the time to conserve battery. It cannot receive segments directly or acknowledge them — it’s asleep during transmission. The Friend node handles everything on its behalf.

In BlueZ, Bluetooth Mesh support is handled by bluetooth-meshd. The lower transport segmentation logic — timers, BlockAck tracking, retransmission — lives in mesh/transport.c inside the BlueZ source tree. The timer values you’ve learned (200+50×TTL, 150+50×TTL, 10 s) are implemented there.

Step 1: Confirm meshd is present on your system

# Check BlueZ version
bluetoothd --version

# Find the mesh daemon binary
ls /usr/libexec/bluetooth/bluetooth-meshd

# Or if installed via package manager
which bluetooth-meshd

Step 2: Start meshd with debug output

# Run with debug logging — lets you see transport events in real time
sudo bluetooth-meshd --nodetach --debug 2>&1 | tee meshd.log

# In another terminal, filter for segmentation-related output
tail -f meshd.log | grep -iE "seg|block.?ack|transport|seqauth"

Step 3: Use meshctl to provision a device and attach to the mesh

# Launch the BlueZ mesh control CLI
meshctl

# Scan for unprovisioned devices nearby
[meshctl]# discover-unprovisioned on

# Provision a device (replace UUID with what appears in scan output)
[meshctl]# provision 00112233445566778899aabbccddeeff

# Once provisioned, switch to the main mesh menu
[meshctl]# menu main

Step 4: Send a payload large enough to trigger segmentation

A payload larger than 11 bytes forces the lower transport layer to segment. In meshctl, the send command takes a destination unicast address, app key index, and hex-encoded payload:

# Send to unicast 0x0005 using app key index 0
# This 16-byte payload (>11 bytes) will be segmented into 2 segments
[meshctl]# send 0005 0 0102030405060708090a0b0c0d0e0f10

# Expected debug log output from bluetooth-meshd:
# transport: Tx SegO=0 SegN=1 SeqAuth=0x00000001000100 dst=0x0005
# transport: Tx SegO=1 SegN=1 SeqAuth=0x00000001000100 dst=0x0005
# transport: Seg ACK src=0x0005 BlockAck=0x00000001  (partial)
# transport: Seg ACK src=0x0005 BlockAck=0x00000003  (all bits set, done)

Step 5: Check timer constants in BlueZ source

# Clone BlueZ source to inspect the implementation
git clone https://git.kernel.org/pub/scm/bluetooth/bluez.git
cd bluez

# Find where timer values are set in the mesh transport code
grep -n "200\|150\|incomplete\|seg_tx\|ack_timer" mesh/transport.c | head -30

What you’ll find in mesh/transport.c (illustrative structure — exact symbol names vary by BlueZ version):

/*
 * Segment transmission timer — used by sender (unicast only)
 * Started each time Lower Transport PDUs are sent
 * Minimum: 200 + 50 * TTL  milliseconds
 */
static uint32_t seg_tx_time_ms(uint8_t ttl)
{
    return (200 + (50 * ttl));
}

/*
 * Acknowledgment timer — used by receiver (unicast destination only)
 * Fires to send a BlockAck even if not all segments arrived yet
 * Minimum: 150 + 50 * TTL  milliseconds
 */
static uint32_t ack_delay_ms(uint8_t ttl)
{
    return (150 + (50 * ttl));
}

/*
 * Incomplete timer — receiver side
 * Maximum gap allowed between arriving segments of the same transaction
 * If this fires, the partial message is discarded
 */
#define INCOMPLETE_TIMEOUT_SEC  10

Note: The function and macro names above are simplified for clarity. The exact naming in your installed BlueZ version may differ slightly. The timer formulas match the Mesh Profile specification exactly.

Tip: Watch for BlockAck=0x0 in logs

# This line in meshd output means the remote node rejected the message
# (it was busy or out of reassembly resources)
# transport: Seg ACK src=0x0005 BlockAck=0x00000000 — cancelling Upper Transport PDU

# When you see this, the sender immediately gives up.
# No retransmission happens. Higher layer is notified of the cancellation.