I use btstack in an embedded project, and it works just fine. I was trying to get the sdp server running and I faced this bug. It returns invalid attribute list when MTU is low and server needs to divide response to multiple responses.

For instance btstack returns these responses, for one record with requested MTU is lower than total attribute length:

response packet 1:

sequence sequence uint1 (attribute1 id) uint2 (attribute1 value)

response packet 2:

sequence sequence uint3 (attribute2 id) sequence4 (attribute2 value) uint5

But according to in the standart it says it should be like this:

packet 1:

sequence sequence uint1 (attribute1 id) uint2 (attribute1 value)

packet 2:

uint3 (attribute2 id) sequence4 (attribute2 value) uint5

Pasted from the standart: The AttributeList is a data element sequence containing attribute IDs and attribute values. The first element in the sequence contains the attribute ID of the first attribute to be returned. The second element in the sequence contains the corresponding attribute value. Successive pairs of elements in the list contain additional attribute ID and value pairs. Only attributes that have non-null values within the service record and whose attribute IDs were specified in the SDP_ServiceAttributeRequest are contained in the AttributeList. Neither an attribute ID nor an attribute value is placed in the AttributeList for attributes in the service record that have no value. The attributes are listed in ascending order of attribute ID value.

I discovered it when searching through pybluez in linux (48 MTU). But when I tried another windows computer with high (1021) MTU there was no problem. Because there was one response packet.

What steps will reproduce the problem?

I register this service record and search services with low MTU like 48:

de_create_sequence(service);

// 0x0000 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0000); de_add_number(service, DE_UINT, DE_SIZE_32, 0x10001);

// 0x0001 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0001); serviceClasses = de_push_sequence(service); de_add_number(serviceClasses, DE_UUID, DE_SIZE_16, 0x1101); de_pop_sequence(service, serviceClasses);

// 0x0004 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0004); protocolStack = de_push_sequence(service); l2cpProtocol = de_push_sequence(protocolStack); de_add_number(l2cpProtocol, DE_UUID, DE_SIZE_16, 0x0100); de_pop_sequence(protocolStack, l2cpProtocol); rfcommChannel = de_push_sequence(protocolStack); de_add_number(rfcommChannel, DE_UUID, DE_SIZE_16, 0x0003); de_add_number(rfcommChannel, DE_UINT, DE_SIZE_8, 0x0001); de_pop_sequence(protocolStack, rfcommChannel); de_pop_sequence(service, protocolStack);

// 0x0005 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0005); groupList = de_push_sequence(service); de_add_number(groupList, DE_UUID, DE_SIZE_16, 0x1002); de_pop_sequence(service, groupList);

// 0x0006 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0006); languageAttributes = de_push_sequence(service); de_add_number(languageAttributes, DE_UINT, DE_SIZE_16, 0x656e); de_add_number(languageAttributes, DE_UINT, DE_SIZE_16, 0x006a); de_add_number(languageAttributes, DE_UINT, DE_SIZE_16, 0x0100); de_pop_sequence(service, languageAttributes);

// 0x0100 de_add_number(service, DE_UINT, DE_SIZE_16, 0x0100); de_add_data(service, DE_STRING, 5, (uint8_t *) "COM 1");

I had to remove the lines that changes the record in sdp_register_service_internal function. But the lines above represent the record I use about a SPP(Serial Port Profile) service copied from the example code in btstack that is removed a few days ago that is also the exact record in my Nokia 6300 phone.

What version of the product are you using? On what operating system?

SVN checkout in 2010 August. Embedded platform.

This is also true for ServiceAttribute request with low MTU.

thanks for reporting. I'll read up on the SDP spec again, but I was happy to get the continuation working at all :)

hi. the funny part is that the spec (also the part you pasted) doens't really say anything how the consecutive responses look like. but in the last example they state that there's no Data Element Sequence header. well,... I'll try to change it then.

ok. that's a bigger change if it should be done properly. I had such nice filtering iterators, that worked on a single pass, but now cannot be used. :( ... will get there.

I re-wrote the service_attribute_request code. It might work now.

hi. please update and test if you get correct responses now. The code got a bit ugly, but the code in sdp_test() returns correct ServiceAttribute and ServiceSearchAttribute partial responses.

Hi. I will try it asap. Thanks.

no problem, thanks again for finding the problem. I'm not happy with that code and I think I found a better/cleaner way to implement it and will re-write it when I find some time - it would be more like the previous code, but adapted to the correct output), but it will produce the same output (hopefully..) :)