# DigiMesh 900HP: leaf→sink unicast routes through a relay fine, but sink→leaf unicast fails \`0x01\` (MAC ACK fail) — sink attempts direct delivery instead of routing through the same relay. Why?
**URL:** https://forums.digi.com/t/digimesh-900hp-leaf-sink-unicast-routes-through-a-relay-fine-but-sink-leaf-unicast-fails-0x01-mac-ack-fail-sink-attempts-direct-delivery-instead-of-routing-through-the-same-relay-why/38492
**Category:** XBee - DigiMesh
**Created:** [May 27, 2026, 8:15pm UTC](https://forums.digi.com/t/digimesh-900hp-leaf-sink-unicast-routes-through-a-relay-fine-but-sink-leaf-unicast-fails-0x01-mac-ack-fail-sink-attempts-direct-delivery-instead-of-routing-through-the-same-relay-why/38492 "2026-05-27T20:15:58Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@hlyu-coencorp.com](https://forums.digi.com/u/hlyu-coencorp.com)
#### Post date: [May 27, 2026, 8:15pm UTC](https://forums.digi.com/t/digimesh-900hp-leaf-sink-unicast-routes-through-a-relay-fine-but-sink-leaf-unicast-fails-0x01-mac-ack-fail-sink-attempts-direct-delivery-instead-of-routing-through-the-same-relay-why/38492/1 "2026-05-27T20:15:58Z")
Hi all,
I have a 3-node DigiMesh network where the **forward** direction routes through an intermediate correctly, but the **reverse** direction will not — the sink keeps attempting a direct (single-hop) delivery to an out-of-range leaf and fails with Delivery Status `0x01`, instead of routing the reply through the relay that demonstrably works in the other direction.
### Hardware
- 3 × XBee-PRO 900HP (S3B), `ATVR = 0x8075`.
- API mode (`AP=1`), driven by an MCU over UART.
### Nodes
- **Sink** — fixed; all traffic targets it; connected to a host PC.
- **Leaf** — a roaming handheld; sends a short unicast to the sink, expects a
short unicast reply. **Important:** to conserve a 2×AAA supply, the leaf’s MCU
**powers the XBee completely off between transactions and cold-boots it
(hardware reset + re-init) at the start of each scan.** So the leaf’s radio is
only present in the mesh for the few seconds around a tag scan, and **rejoins
fresh every time**. It does _not_ use XBee sleep modes (`SM=0`); the MCU gates
power via the reset/regulator lines, not `SM`/`SP`/`ST`.
- **Relay** — fixed, higher-power module between leaf and sink.
All three are configured identically for DigiMesh and verified in XCTU:
`SM=0`, `CE=0`, `TO=0xC0`, `NH=7`, `BH=0`, `MR=7`, identical `ID`/`CH`/`HP`.
### What works
- **Leaf → sink (forward) routes through the relay.** Confirmed: with the leaf out of the sink’s direct range, forward delivery works; **unplug the relay and forward stops; restore the relay (leaf unmoved) and forward resumes.** So the relay is genuinely bridging multi-hop in this direction.
- **All individual links are good.** From the relay (on an XCTU dev board), a Remote AT (0x17) to the leaf’s 64-bit address returns Delivery Status `0x00`; XCTU network discovery shows the leaf at ~ −87 dBm. The relay reaches both the sink and the leaf.
### What fails
- **Sink → leaf (reply) fails 100%** when the leaf is out of the sink’s direct range (but in the relay’s range). Delivery Status = **`0x01` (MAC ACK failure)**, returned ~300 ms after the request.
The `0x01` is the puzzle: if the sink were routing the reply via the relay, the next hop would be the relay (which ACKs fine — forward proves it), so we’d never see a MAC-ACK failure. `0x01` means the sink is attempting a **direct** transmit to the leaf (next hop = the out-of-range leaf, no ACK) and **not routing through the relay** — and not recovering via route repair despite `MR=7`.
It looks like the sink has cached the leaf as a _direct_ neighbor (presumably from occasionally hearing the leaf’s relayed forward packets at a marginal level) and keeps retrying direct delivery rather than using the known-good multi-hop path.
### What we’ve tried
- Swept the per-packet Transmit Options byte (`0x40` works for forward; `0x00`/`0x80`/`0xC0` broke all delivery — so we’re on `0x40`).
- `TO=0xC0` confirmed on all three; network-reset / power-cycled all three.
- Aggregator: issued `ATAG` from the sink (returns `OK`) — no effect on the reverse path.
- Verified every node’s `SM`/`CE`/`TO`/`NH`/`ID`/`CH`/`HP`, `MR=7`, and all links.
### Questions
1. In a correctly-configured DigiMesh network, why would the sink attempt a **direct** unicast to a leaf (failing `0x01` MAC-ACK) instead of **routing the reply through a relay** that is actively bridging the forward direction? What makes a node choose direct delivery and _not_ fall back to route discovery/repair for an out-of-range destination?
2. How do I force the sink to route the reply through the relay — e.g. clear/expire a stale direct neighbor entry, force a route discovery (`DN`/explicit route) before the reply, or a Transmit Options / `CE` / `MR` / `NO` setting that changes this?
3. Does DigiMesh treat a node that **frequently resets/rejoins** (our leaf power-cycles its radio between transactions) differently for _inbound_ routing — i.e. routes _to_ it don’t establish/persist even though routes _from_ it do?
4. Confirm `ATVR=0x8075` is the DigiMesh function set for the 900HP (the function-set name from XCTU is `[FILL IN]`).
Happy to post raw API frame captures (the 0x10 request + 0x8B `0x01` status, and the relay’s successful Remote AT) if useful.
Thanks!
Hongwei
---
### Author:  [@mvut](https://forums.digi.com/u/mvut)
#### Post date: [May 28, 2026, 12:12pm UTC](https://forums.digi.com/t/digimesh-900hp-leaf-sink-unicast-routes-through-a-relay-fine-but-sink-leaf-unicast-fails-0x01-mac-ack-fail-sink-attempts-direct-delivery-instead-of-routing-through-the-same-relay-why/38492/2 "2026-05-28T12:12:32Z")
In your situation, the node that you are calling the “Leaf” is in the parents neighbor table. This is why it fails when going through a hop instead. You can force a rout discovery by doing an ATND to the NI value of the “leaf”.
---
### Author:  [@hlyu-coencorp.com](https://forums.digi.com/u/hlyu-coencorp.com)
#### Post date: [May 29, 2026, 5:56pm UTC](https://forums.digi.com/t/digimesh-900hp-leaf-sink-unicast-routes-through-a-relay-fine-but-sink-leaf-unicast-fails-0x01-mac-ack-fail-sink-attempts-direct-delivery-instead-of-routing-through-the-same-relay-why/38492/3 "2026-05-29T17:56:09Z")
thanks. The forced discovery works