Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp522757pxa; Wed, 12 Aug 2020 07:47:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwh9VQHc/LQLlaScT/tzjOUiilSyqnC7+2fXPApethQ2td4h3LauwK/r1r9mMQv0FZXKf2T X-Received: by 2002:a17:906:57cc:: with SMTP id u12mr143684ejr.422.1597243665344; Wed, 12 Aug 2020 07:47:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597243665; cv=none; d=google.com; s=arc-20160816; b=eMHOeL5wYtzzlAbQnpX/Eo+5+vJBTlE1f8sXVOpS/9NnWQaU194vCFknryHjIlQedH /9CcgG/AUy4sAU9eXQtc4Ze73vwCZDimIY9lT62L87ax2c78qQJHsWCCAlLTrix8avJn 9hTWJjm7l9Yq3Lfj4Q20P2zvoJdqYCYJDzT3ZmJhowxBRDGL0BL7buQKm6hiDlpjc2Nz 4lYRCAIjaiPppXrKg3w0N3nWwOUYx+FkuCncirtTiPOVIb4s3DbYcOw1qv/VRxWIDwzF O8vOwXoTBhWGrEM0E76phQ3H0h5UNttCmUq4mHroVuKqGk9+JiueyRo5TP5aZwusKZef 3i5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:to:subject :from:dkim-signature; bh=3TUNuBdim+yf0joN6jjEhoSW+MvkgsZv/98nSy8u6zg=; b=FHd2PAORnCS7lSAso2zzkq4vi4TP5ExT1vJtu39jVt1D4TWE2QpQYJovfTZmJtzv7m +h55EEpxpmmitVfucbpUXIg+029vp6B9JqJzJKyuHwh9FmHodM+PgkXwtYL/qpeOJO4C 6gWDJBOh1BSs6y4Iydu29ovjRb5Q77XBayyCseZaKbSoY0ihrVTKWpU8xCmoH13H//pb j8rq+EjqC6R7MaJ4a7DMnjUgpd8Az1tJRl9VlC4VJiYCVaRo0bz5vdZMJKuV24CyPMNJ HMoq7v6s13vVAV+mvu44sxhAW7ZVOu1prp5POI5arfP6htK8ZnpJrvKoZPlA7UXX3Nxw faIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mnmoran.org header.s=dkim header.b="aa0/V+SI"; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y20si1300044ejj.325.2020.08.12.07.47.02; Wed, 12 Aug 2020 07:47:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mnmoran.org header.s=dkim header.b="aa0/V+SI"; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726609AbgHLOot (ORCPT + 99 others); Wed, 12 Aug 2020 10:44:49 -0400 Received: from hoster906.com ([192.252.156.27]:49204 "EHLO hoster906.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726434AbgHLOot (ORCPT ); Wed, 12 Aug 2020 10:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=mnmoran.org; h=from :subject:to:message-id:date:mime-version:content-type :content-transfer-encoding; s=dkim; bh=1BGXvAlqAjky12gnZjIc2GpJL aEX4ldCWFrER7CRVyc=; b=aa0/V+SIL1b+ug9XOhNFKxjiedeVBl2lTeV38OYT/ 7B1fmE5/1nGrklnCayOOXYHlxKeNsfDkxySIk8r28s3Bqqbw3LI+Yi/XyFNl9b2K XERS3e4R/RXyezrH3b3VBa4J5pGA7bwLhffAFphlg4zHfD46v5CDo7hhvEkQxG72 P0= Received: (qmail 3067 invoked by uid 503); 12 Aug 2020 14:44:48 -0000 Received: from unknown (HELO ?192.168.254.79?) (mike@mnmoran.org@162.39.210.203) by hoster906.com with ESMTPA; 12 Aug 2020 14:44:48 -0000 From: "Michael N. Moran" Subject: Single-Segment Segmented Mesh Messages To: "linux-bluetooth@vger.kernel.org" Message-ID: Date: Wed, 12 Aug 2020 10:44:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org I've been trying to wrap my head around the mesh d-bus api as described in "doc/mesh-api.txt". In particular, I'm looking at the org.bluez.mesh.Node1 interface Send() and DevKeySend() operations. I don't see any way for a client application (Access Layer) to specify that a message that would fit into a single lower transport pdu should be sent as a single-segment message. The motivation for this is to be able to test the reassembly capability of an actual mesh node/device. For example, I would like to add an option to the test/test-mesh application to be able to send on/off messages using a single-segment message (if the destination element address is unicast). As it is, it appears that the bluetooth-meshd makes the decision on its own based on the length of the upper transport layer pdu. From the Mesh Profile v1.0 spec: > 3.5.3.1 Segmentation > > [...] If the Upper Transport PDU can fit into a single Lower Transport PDU using a Segmented Message format, then the lower transport layer can use a single segmented message to transmit this Upper Transport PDU. > > [...] A single-segment segmented message should be used when delivery of an Upper Transport PDU can be more efficiently transmitted using a segmented message than an unsegmented message. > > [...] A single-segment segmented message should be used when delivery of an Upper Transport PDU can be more efficiently transmitted using a segmented message than an unsegmented message.