# DF-3328 leaked TTL byte (offset 28 of the 43-byte broadcast PERR,
# elemid 132 at offset 26) extracted from kern.fwm_txlog hex dumps.
# A correct implementation forwards rx_ttl - 1.
#
# boot 1, run.log  (rx TTLs 5, 9, 200, 77, 250 -> correct would be 4, 8, 199, 76, 249)
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
# boot 1, run.2.log (rx TTLs 3, 100, 55, 240, 9, 88, 150, 21, 66, 111 -> correct 2, 99, 54, 239, 8, 87, 149, 20, 65, 110)
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e     x10
# boot 2 (fresh vm.sh reset with-src), run.3.log (rx TTLs 5, 90, 12 -> correct 4, 89, 11)
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
# DF-3327-fixed kernel regression (rx TTL 42 -> correct 41)
fwd-PERR ttl=0xfe (254)  ndests=01 flags=3e
#
# The byte 0xfe == (heap byte 0xff) - 1: the pperr block's offset-2 byte was
# 0xff before the single `pperr->perr_ttl--`. It is identical across boots
# because the M_80211_MESH_PERR 640-byte bucket block consistently carries
# 0xff there on this kernel; it NEVER equals rx_ttl-1 for any of the 16
# distinct rx TTLs used, proving the transmitted TTL is prior kernel heap
# contents, not frame data.