Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1322265226-6404-1-git-send-email-andre.guedes@openbossa.org> <1322265226-6404-8-git-send-email-andre.guedes@openbossa.org> Date: Mon, 28 Nov 2011 07:08:43 -0400 Message-ID: Subject: Re: [PATCH v2 7/9] Bluetooth: Add 'eir_len' param to mgmt_device_found() From: Anderson Lizardo To: "Ganir, Chen" Cc: Andre Guedes , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=US-ASCII Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Chen, On Sun, Nov 27, 2011 at 2:37 AM, Ganir, Chen wrote: > Why do we really need this ? The GAP Spec clearly defines a fixed advertising size of 31 octets (Vol3, Part C, Section 11). Instead of reporting how much we got (may be other than 31 if the peer device does not conform to the spec as required), we should make sure that BlueZ will always report 31 octets, and make sure that the device found event always sends a buffer of 31 octets. These functions are also used for BR/EDR, where EIR data is 240 bytes. If I remember correctly, it has already been discussed on this list about dropping this length, and the decision was against dropping it, otherwise we would send always 240 bytes containing mostly zeroes (for LE case). Also note these items from the AD section: "If the Length field is set to zero, then the Data field has zero octets. This shall only occur to allow an early termination of the Advertising or Scan Response data." and: "Only the significant part of the Advertising or Scan Response data needs to be sent over the air." So a device sending less than 31 bytes of AD is compliant as long as the last AD length field is zero. The receiving controller is not required to fill the remaining AD with zeroes before sending it to the host. Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil