v0.48.1

[mqtt5 0.48.1] - 2026-10-15

Breaking

• The broker's maximum packet size counts the whole packet (MQTT 5 §3.1.2.26). On TCP, TLS and the QUIC control stream it counted only the remaining length, so a packet up to 5 bytes over the limit was accepted. Such a packet now closes the connection.

Fixed

• The QUIC broker refuses a client stream it does not support instead of closing the connection (#207). Any client-opened bidirectional stream that was not a flow discard closed the connection with ERROR_PROTOCOL_L0 (0xB4), including user-defined flows (0x14) and client data flows, which MQoQ §9.20 allows on bidirectional streams. A user-defined flow on a unidirectional stream was read as MQTT, so depending on its bytes it closed the connection as a malformed packet or was left open. As §9.10 describes, only the stream is now refused, and the connection stays up:

  • a user-defined flow, or a client data flow on a bidirectional stream, with ERROR_FLOW_REFUSED (0xBE);
  • a server data flow header, or a client data flow whose flow ID has the server bit set, with ERROR_BAD_FLOW_ID (0xB6);
  • a control flow header on any stream but the control stream, or a bidirectional stream without a flow header, with ERROR_STREAM_TYPE (0xB5).

  A refused bidirectional stream gets STOP_SENDING and RESET_STREAM with the code, a unidirectional one STOP_SENDING. Unidirectional streams without a flow header are still read as MQTT.

• Discarding a flow now removes its subscriptions (#207). A discard removed the flow's state but left its flow-bound subscriptions, so the broker kept delivering to a flow the client had discarded. §9.21.2 counts subscriptions as part of the flow state that §9.16 says to discard. The broker now removes them before it answers the discard with FIN.

• Only a flow header followed directly by FIN is a discard (§9.16). A bidirectional stream whose header carried the discard flags was treated as a discard even when MQTT data followed, and the data was dropped. Such a stream is now refused with ERROR_FLOW_REFUSED.

• The QUIC broker enforces its maximum packet size on data streams and datagrams. Only the control stream checked max_packet_size. A packet over the limit on a client data stream or in a datagram was read in full and delivered, whatever the limit, so a client could make the broker buffer up to 256 MB per stream by announcing a large packet. An oversized ack on a stream the broker opened only stopped that stream, so the flow's later acks were never read. The broker now refuses all of these from the fixed header and closes the connection with ERROR_PROTOCOL_L0 (0xB4), as it does on the control stream.

[mqttv5-cli 0.29.8] - 2026-10-15

Changed

• Requires mqtt5 0.48.1, so mqttv5 broker gets its QUIC stream and maximum packet size fixes. See mqtt5 0.48.1.