Huib_o
September 7, 2026, 3:36pm
21
I did the same. All kind of non battery Matter devices like Alpstuga, grillplats and bulbs.
The only conclusion i can make is that the instable devices are (mostly) the once recently added. Even the Alpstuga.
The strange thing is that two Klippboks are coming and going randomly without me interfering as nobody on thar location who can play with the batteries.
i pray its the Hubs. i have both V 3 and V4
I’d wait a couple of months until the updated hardware hits the shelves and replace the offending devices:
Huib_o
September 7, 2026, 3:44pm
23
Will that be for free?
I bought my devices in different countries. Kept the receipts.
Huib_o:
Will that bev for free?
I don’t think so. They are what? About 10 bucks each?
Huib_o
September 7, 2026, 3:54pm
25
I am a poor pensioner…
But more important: How will we recognize the “new” devices.
Maybe we will learn later.
I wonder if this will help
Also this, I wonder if this relates only to myggspray or does it also apply to klippbok and timmerflotte.
opened 06:25PM - 10 Sep 26 UTC
**Describe the bug**
I have been using ChatGPT and Codex in investigating a per… sistent attach failure of a battery-powered Thread end device (IKEA MYGGSPRAY motion sensor, firmware 1.1.4). An independent 802.15.4 capture shows a repeatable mismatch between the Link Layer Frame Counter advertised in the MLE Child ID Request and the MAC security frame counter actually used immediately afterwards.
On the first fully captured attach attempt:
- Child ID Request: Link Layer Frame Counter **1280176180**, MLE Frame Counter 1029, key sequence 15.
- First subsequent secured MAC Data Request: frame counter **4708**, Key ID Mode 1 / Key Index `0x10` (same key sequence).
- The child then polls with counters 4708–4718. Matching ACKs have `Frame Pending = 1`, but no parent-to-child data frame / Child ID Response follows.
The behavior persists across natural retries:
| Time (UTC) | Event | Advertised Link FC | Actual MAC FC | Parent |
|---|---|---:|---:|---|
| 10:45:59 | Child ID Request | **1280176180** | — | Parent A |
| 10:45:59–10:46:01 | Data Request burst | — | **4708–4718** | Parent A |
| 10:56:03–10:56:04 | Data Request burst | — | **4719–4729** | Parent A |
| 11:06:06 | Child ID Request | **1280176180** | — | Parent B |
| 11:06:06–11:06:07 | Data Request burst | — | **4730–4740** | Parent B |
Apart from one normal retransmission reusing its counter, the actual MAC TX counter is continuous from **4708 through 4740**. The two visible Child ID Requests are ~20 minutes apart, target different parents, and both advertise exactly **1280176180**. The MLE frame counter advances (1029 -> 1033), so the whole security state is not simply frozen.
Parent A behavior was checked against the exact OpenThread build in use, `c34311f`:
- `HandleChildIdRequest()` stores the received Link Layer Frame Counter in the child neighbor state.
- `SendChildIdResponse()` queues the response and then calls `SetChildStateToValid()`.
- Receive security for a valid neighbor under the same key sequence rejects a secured MAC frame when its frame counter is below the stored neighbor link counter.
This appears to explain the failure: the parent sets the child's anti-replay threshold to 1280176180, while the child immediately polls using ~4708. Radio source matching can still produce ACKs with Frame Pending set because indirect data is queued, while host-side OpenThread subsequently rejects the secured poll before indirect delivery occurs.
It is not said that the defect is in OpenThread itself. The inconsistent counters may originate in the end-device platform/radio/firmware. I am filing this to verify the protocol/OpenThread interpretation and determine whether this matches a known counter-synchronization failure class. Perhaps someone also has a better way of getting in touch with Ikea developers to verify it.
**To Reproduce**
This is a persistent failure observed on a closed consumer device rather than a source-level reproducer:
1. Affected device: IKEA MYGGSPRAY, firmware 1.1.4, hardware P2.0.
2. Device had previously been operational and later entered a persistent unavailable state.
3. Leave the device/network unchanged and capture natural reattachment attempts with an independent receive-only 802.15.4 sniffer.
4. Observe the counter sequence summarized above.
For the first attach attempt, Parent Response challenge and Child ID Request Response match, and the Child ID Request otherwise decodes normally. No reset, battery removal, recommissioning, or Thread-network change was performed while collecting the evidence.
**Environment / hardware**
- Parent A: Home Assistant OpenThread Border Router, OpenThread **`c34311f`**
- Parent A radio: Home Assistant ZBT-2 / EFR32 RCP
- Parent B: different Thread router in the same network
- Child: IKEA MYGGSPRAY firmware **1.1.4**, hardware **P2.0**; child OpenThread/platform revision unknown
- Separate receive-only IEEE 802.15.4 sniffer
- A second MYGGSPRAY with the same firmware remains healthy in the same network, but this capture contains no healthy Child ID Request for an attachment A/B comparison
**Expected behavior**
For the same active MAC key sequence, one would expect the Link Layer Frame Counter advertised during attachment to be consistent with the MAC security frame-counter state used immediately afterwards, so that the sleepy child can poll and receive the queued Child ID Response.
**Additional context / questions**
The raw PCAP is not public because it contains Thread network material. A sanitized evidence package with derived packet fields and the counter timeline is available.
The normal OpenThread store-ahead mechanism does not seem to explain this: `AppendLinkFrameCounterTlv()` uses the current maximum MAC frame counter; the standard NVM store-ahead value is a separate persistence mechanism and is orders of magnitude smaller than the observed ~1.28 billion delta.
Potentially related history: #7040 / #8607 and #11186 / #11201 describe radio/SubMac vs stack frame-counter synchronization failures. I am not claiming either is the same bug.
Questions:
1. Is there any valid Thread/OpenThread scenario where a child advertises Link Layer Frame Counter **1280176180** and then immediately sends secured MAC Data Requests under the same key sequence with counters around **4708**?
2. Does the parent-side interpretation above match OpenThread behavior, including the coexistence of `Frame Pending = 1` ACKs with later host-side security rejection?
3. If the child behavior is invalid, does this resemble a known platform/radio counter restore or synchronization failure, and what additional passive evidence would be most useful before disturbing the failed state?
swhitney60
September 22, 2026, 5:06pm
28
All of my matter devices, including plug in smartplugs have been going offline every couple days since the firmware update. The only way for me to get them back online is to reboot my smartthings hub. For my implementation, the latest firmware have made things worse.
Huib_o
October 3, 2026, 2:19pm
29
Yep me too. I hope the updates may solve it.
On a location that I cannot reach personally, 3 @#!*! Timmerflottes went offline in just a few days.
On the other hand I have the impression that more Ikea Matter devices, step by step, become more reliable. Keep fingers crossed.
One of my timmerflottes ha just dropped offline again, and also a lafaer moT presence sensor which is also prone to drop, they often drop out together . One is routed via a IKEA Kajplats bulb, the other from an Onvis outlet.
My only Onvis plug shows repeatedly in the various Thread tools (Eve, Thread Doctor etc) as an endpoint, so I don’t know if I’d expect much from it.
Currently thirteen of the extenders on my main mesh are Onvis plugs, the others being Eve plugs and ST hubs. All have sixteen neighbours, of course.
There are a few IKEA Matter buttons around but none of the other sensors.
The path shows it’s definitely routing through it. I powered down the onvis outlet for 5 mins and the timmerflotte came back on a different route (a separate onvis outlet as it happens)
