(win) Bluetooth stack cached a GATT Notification packet larger than default MTU

[ranbochen]

MTU auto-negotiated to 247, but stack always cache a packet lager than 20 bytes.

Observed Behavior:

. on recv the first notification larger than 20 bytes, it is cached and no event is triggered.
. on recv the second packet larger than the default MTU, the second packet is cached, and the first packet reception event is received simultaneously.
. on recv a packet smaller than the default MTU, two events are immediately received: one for the previously cached packet and one for the new, shorter packet.

[stoprocent]

Thanks for the detailed write-up — the step-by-step repro is really helpful.

I traced the Windows notification path and I don't think the one-packet lag is coming from noble itself:

• On connect we hold a GattSession and track MaxPduSize / MaxPduSizeChanged, so the 247 you see is the value Windows reports.
• Notify() just registers GattCharacteristic.ValueChanged and writes the CCCD.
• OnValueChanged reads the buffer synchronously and in full and emits it immediately — there's no queue and no size check anywhere in the binding (or in noble core).

So each notification is forwarded verbatim, as soon as WinRT hands it to us. There's no code path that would hold a packet back until the next one arrives.

The tell is your threshold: 20 bytes = the default ATT payload (23 − 3). Even though MaxPduSize reports 247, the notification data path is behaving as if it's still at the default MTU — anything larger than the default gets deferred, and a sub-default packet flushes it. That points at the Windows BLE stack applying the negotiated MTU to MaxPduSize but not to the actual notification delivery, rather than a bug in how noble reads the value.

This lines up with other WinRT BLE projects seeing MTU behave inconsistently on Windows (e.g. bleak #1497, #1227), and it tends to be Windows-build / adapter dependent.

To confirm and give us something testable, could you share:

1. A BLE sniff (btvs / PktMon or a Wireshark BLE capture) around a couple of >20-byte notifications — specifically whether they arrive on-air as a single ATT PDU, and what ATT_MTU was actually exchanged on the link.
2. Your Windows build number and the Bluetooth adapter/driver in use.
3. Whether doing a normal characteristic read once after subscribing (to force a GATT round-trip) changes the behavior at all.

If the capture shows the MTU exchange isn't actually being applied to the connection, this is a stack-level issue and we can look at whether nudging the exchange earlier from noble helps. Thanks!

---

Generated by Claude Code