mqtt-sn — archive

Re: Packet Type Field Change

From: Andy Stanford-Clark
To: [email protected]
Date: Tue, 10 Jan 2023 09:04:00 -0000

On 5... if I've understood what you're saying, then I would say that the original intent of QoS -1 was for devices that don't have a receive capability - only a transmit - hence the "lower than qos 0" - it's literally fire and forget, and even worse, have no idea if it got there or not. So we can't limit it to Active and Asleep states. In my CAN bus project, I'm thinking of it as "drive-by publishing" ð Andy Andy Stanford-Clark Innovation Leader - IBM SPEED team Distinguished Engineer, Master Inventor, IBM Quantum Ambassador, Member IBM Academy of Technology, Fellow BCS Visiting Professor at Newcastle, Southampton and UEA. Tel: +44 (0)7801 787096 twitter: @andysc From: Davide Lenzarini <[email protected]> Sent: 10 January 2023 08:48 To: Simon Johnson <[email protected]> Cc: Ian Craggs <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Andy Stanford-Clark <[email protected]> Subject: [EXTERNAL] RE: Packet Type Field Change Hi Simon, Ok to add a new packet type for v2 PUBLISH-1 and leave 0x0C for v1. 2 PUBLISH. If I have correctly understood, this option may limit the variants of PUBLISH-1 to only 2. This option increases the overhead of PUBLISH-1 by 1 byte and ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Simon, Ok to add a new packet type for v2 PUBLISH-1 and leave 0x0C for v1.2 PUBLISH. If I have correctly understood, this option may limit the variants of PUBLISH-1 to only 2. This option increases the overhead of PUBLISH-1 by 1 byte and I think we should avoid this. . We may limit the usage of PUBLISH-1 only to the Active and Asleep states, so only after a session has been established (eventually lasting for a very long time). In any case for security reasons we need to identify the sender and provide it with a token to authorize the data published as QoS-1. Bye Davide From: Simon Johnson <[email protected]> Sent: Monday, January 9, 2023 4:03 PM To: Andy Stanford-Clark <[email protected]> Cc: Davide Lenzarini <[email protected]>; Ian Craggs <[email protected]>; [email protected]; [email protected] Subject: Re: Packet Type Field Change **** This is an EXTERNAL email. It was sent from outside of u-blox. **** I fear we may have our hand forced actually; the ENCAPSULATED message type sits at 0xFE right at the end of the reserved range in 1.2 which precludes the use of bits 0-1 for any nefarious purposes such as this so the available solutions to this as I see it are as follows: Create a NEW packet type for version 2 which is a new PUBLISH_MINUS_1 specific packet format such that version 1.2 PUBLISH -1's received by a gateway will decode successfully in the old format and can be differentiated Modify the meaning of flags (byte 3) field bit 3 (presently reserved in the current PUBLISH spec) where 0 means "old style PUBLISH" and 1 means "new style -1 PUBLISH" - this mean old style packets will still decode ok since they are forced to send 0 here, and there is no extra byte required - this is important since many old client impls still exist and we will want to be able to accept valid 1.2 traffic on new gateways Use one of those reserved bits above to mean "protocol" version byte follows, which when set to 1 will decode the a protocol byte inserted at Byte 4 Ignore and accept the broken change Other suggestions.... Now we have the packet versions broken out for QoS -1 & 0 in the document anyway, this seems less impactful - but as Andy said, we need to ensure we're good going forward. S On Mon, 9 Jan 2023 at 09:26, Andy Stanford-Clark < [email protected] > wrote: Well spotted, Si