On Tue, Jan 25, 2011 at 3:46 PM, Brian Gix <bgix@xxxxxxxxxxxxxx> wrote: > As far as test case coverage per the qualification test specification, I > do not believe that there is a problem. Any non long "Reads" can be > tested by reading < 22 octet attributes, and long read tests by reading >>= 22 octet attributes. Now that you mentioned this topic, the issue that brought this thread is that there is a specific qualification test where PTS sends a 22 bytes characteristic value, expecting a single Read Request to be sent, and it refuses to answer to any further Read Blob Requests (i.e. it does not send any response PDUs). This makes the client (e.g. igatttool) wait forever for a answer or timeout. Looks like more a PTS bug, but makes me wonder if it is not better for BlueZ to have separate procedures instead of this "automatic" usage of read blob request ? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
