* [Bluez-devel] sdptool segfaults @ 2005-03-03 15:33 Dimitry Andric 2005-03-03 15:54 ` Stephen Crane 0 siblings, 1 reply; 4+ messages in thread From: Dimitry Andric @ 2005-03-03 15:33 UTC (permalink / raw) To: bluez-devel [-- Attachment #1: Type: text/plain, Size: 4426 bytes --] Hi, I'm getting a weird segfault in sdptool, when I'm browsing the DUN service of a Samsung D500. It crashes in sdp_get_profile_descs: (gdb) run search --bdaddr 00:12:47:11:0B:06 DUN Starting program: /bin/sdptool search --bdaddr 00:12:47:11:0B:06 DUN Searching for DUN on 00:12:47:11:0B:06 ... Service Name: Dial-up networking Service RecHandle: 0x10002 Service Class ID List: "Dialup Networking" (0x00001103) Protocol Descriptor List: "L2CAP" (0x00000100) "RFCOMM" (0x00000003) Channel: 4 Program received signal SIGSEGV, Segmentation fault. sdp_get_profile_descs (rec=0x28a58, profDescSeq=0xbefffcec) at /home/dim/src/bluez/bluez-libs/src/sdp.c:1528 1528 sdp_data_t *pVnum = seq->val.dataseq->next; (gdb) bt #0 sdp_get_profile_descs (rec=0x28a58, profDescSeq=0xbefffcec) at /home/dim/src/bluez/bluez-libs/src/sdp.c:1528 #1 0x0000a6a4 in print_service_attr (rec=0x2aab0) at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:904 #2 0x0000cde0 in do_search (bdaddr=0xbefffd6c, context=0xbefffd74) at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:1999 #3 0x0000d094 in cmd_search (argc=94880, argv=0x18050) at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:2150 #4 0x0000d55c in main (argc=4, argv=0xbefffe08) at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:2319 (gdb) p seq->val.dataseq->next Cannot access memory at address 0x32 (gdb) p seq->val.dataseq $1 = (sdp_data_t *) 0x1a I've got no idea why val.dataseq turns out to be invalid here... It looks more like a UUID, it's certainly not a pointer. I attached a HCI dump of the discovery; sdptool seems to crash on the following part: > ACL data: handle 42 flags 0x02 dlen 14 L2CAP(d): cid 0x0040 len 10 [psm 1] SDP SSA Rsp: tid 0x2 len 0x5 count 2 record #0 aid 0x0000 (SrvRecHndl) uint 0x10002 aid 0x0001 (SrvClassIDList) < uuid-32 0x1103 (DUN) > aid 0x0004 (ProtocolDescList) < < uuid-32 0x0100 (L2CAP) > < uuid-32 0x0003 (RFCOMM) uint 0x4 > > aid 0x0100 (SrvName) str "Dial-up networking" aid 0x0009 (BTProfileDescList) < uuid-32 0x1103 (DUN) > cont 00 You can compare this to some DUN searches that do not cause a crash. For example, a SE K700 gives: > ACL data: handle 42 flags 0x02 dlen 101 L2CAP(d): cid 0x0040 len 97 [psm 1] SDP SSA Rsp: tid 0x0 len 0x5c count 89 record #0 aid 0x0000 (SrvRecHndl) uint 0x10000 aid 0x0001 (SrvClassIDList) < uuid-16 0x1103 (DUN) uuid-16 0x1201 (Networking) > aid 0x0004 (ProtocolDescList) < < uuid-16 0x0100 (L2CAP) > < uuid-16 0x0003 (RFCOMM) uint 0x1 > > aid 0x0005 (BrwGrpList) < uuid-16 0x1002 (PubBrwsGrp) > aid 0x0009 (BTProfileDescList) < < uuid-16 0x1103 (DUN) uint 0x100 > > aid 0x0100 (SrvName) str "Dial-up Networking" aid 0x0305 (unknown) bool 0x0 cont 00 And a Nokia 6310i gives: > ACL data: handle 43 flags 0x01 dlen 16 L2CAP(d): cid 0x0040 len 108 [psm 1] SDP SSA Rsp: tid 0x0 len 0x67 count 100 record #0 aid 0x0000 (SrvRecHndl) uint 0x10002 aid 0x0001 (SrvClassIDList) < uuid-16 0x1103 (DUN) uuid-16 0x1201 (Networking) > aid 0x0004 (ProtocolDescList) < < uuid-16 0x0100 (L2CAP) > < uuid-16 0x0003 (RFCOMM) uint 0x1 > > aid 0x0005 (BrwGrpList) < uuid-16 0x1002 (PubBrwsGrp) > aid 0x0006 (LangBaseAttrIDList) < uint 0x656e uint 0x6a uint 0x100 > aid 0x0009 (BTProfileDescList) < < uuid-16 0x1103 (DUN) uint 0x100 > > aid 0x0100 (SrvName) str "Dial-up networking" cont 00 So AFAICS, the difference is that most (?) phones use a uuid-16 for BTProfileDescList (at least for the DUN item), while the Samsung uses a uuid-32. Does anyone know if this is actually allowed? I'd guess the specific integer type shouldn't matter, so if it doesn't, sdptool probably shouldn't crash on it. [-- Attachment #2: sdpsearch.hcidump --] [-- Type: application/octet-stream, Size: 925 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bluez-devel] sdptool segfaults 2005-03-03 15:33 [Bluez-devel] sdptool segfaults Dimitry Andric @ 2005-03-03 15:54 ` Stephen Crane 2005-03-03 21:17 ` Marcel Holtmann 2005-03-18 19:47 ` Steven Singer 0 siblings, 2 replies; 4+ messages in thread From: Stephen Crane @ 2005-03-03 15:54 UTC (permalink / raw) To: bluez-devel This looks to me like the Samsung is formatting the profile descriptor list incorrectly. I guess it should be a sequence of sequences of { UUID, version } whereas the Samsung just formats it as a sequence. On Thu, 2005-03-03 at 16:33 +0100, Dimitry Andric wrote: > Hi, > > I'm getting a weird segfault in sdptool, when I'm browsing the DUN > service of a Samsung D500. It crashes in sdp_get_profile_descs: > > (gdb) run search --bdaddr 00:12:47:11:0B:06 DUN > Starting program: /bin/sdptool search --bdaddr 00:12:47:11:0B:06 DUN > Searching for DUN on 00:12:47:11:0B:06 ... > Service Name: Dial-up networking > Service RecHandle: 0x10002 > Service Class ID List: > "Dialup Networking" (0x00001103) > Protocol Descriptor List: > "L2CAP" (0x00000100) > "RFCOMM" (0x00000003) > Channel: 4 > > Program received signal SIGSEGV, Segmentation fault. > sdp_get_profile_descs (rec=0x28a58, profDescSeq=0xbefffcec) > at /home/dim/src/bluez/bluez-libs/src/sdp.c:1528 > 1528 sdp_data_t *pVnum = seq->val.dataseq->next; > (gdb) bt > #0 sdp_get_profile_descs (rec=0x28a58, profDescSeq=0xbefffcec) > at /home/dim/src/bluez/bluez-libs/src/sdp.c:1528 > #1 0x0000a6a4 in print_service_attr (rec=0x2aab0) > at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:904 > #2 0x0000cde0 in do_search (bdaddr=0xbefffd6c, context=0xbefffd74) > at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:1999 > #3 0x0000d094 in cmd_search (argc=94880, argv=0x18050) > at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:2150 > #4 0x0000d55c in main (argc=4, argv=0xbefffe08) > at /home/dim/src/bluez/bluez-utils/tools/sdptool.c:2319 > (gdb) p seq->val.dataseq->next > Cannot access memory at address 0x32 > (gdb) p seq->val.dataseq $1 = (sdp_data_t *) 0x1a > > I've got no idea why val.dataseq turns out to be invalid here... It > looks more like a UUID, it's certainly not a pointer. > > I attached a HCI dump of the discovery; sdptool seems to crash on the > following part: > > > ACL data: handle 42 flags 0x02 dlen 14 > L2CAP(d): cid 0x0040 len 10 [psm 1] > SDP SSA Rsp: tid 0x2 len 0x5 > count 2 > record #0 > aid 0x0000 (SrvRecHndl) > uint 0x10002 > aid 0x0001 (SrvClassIDList) > < uuid-32 0x1103 (DUN) > > aid 0x0004 (ProtocolDescList) > < < uuid-32 0x0100 (L2CAP) > < > uuid-32 0x0003 (RFCOMM) uint 0x4 > > > aid 0x0100 (SrvName) > str "Dial-up networking" > aid 0x0009 (BTProfileDescList) > < uuid-32 0x1103 (DUN) > > cont 00 > > You can compare this to some DUN searches that do not cause a crash. > For example, a SE K700 gives: > > > ACL data: handle 42 flags 0x02 dlen 101 > L2CAP(d): cid 0x0040 len 97 [psm 1] > SDP SSA Rsp: tid 0x0 len 0x5c > count 89 > record #0 > aid 0x0000 (SrvRecHndl) > uint 0x10000 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1103 (DUN) uuid-16 0x1201 (Networking) > > aid 0x0004 (ProtocolDescList) > < < uuid-16 0x0100 (L2CAP) > < > uuid-16 0x0003 (RFCOMM) uint 0x1 > > > aid 0x0005 (BrwGrpList) > < uuid-16 0x1002 (PubBrwsGrp) > > aid 0x0009 (BTProfileDescList) > < < uuid-16 0x1103 (DUN) uint 0x100 > > > aid 0x0100 (SrvName) > str "Dial-up Networking" > aid 0x0305 (unknown) > bool 0x0 > cont 00 > > And a Nokia 6310i gives: > > > ACL data: handle 43 flags 0x01 dlen 16 > L2CAP(d): cid 0x0040 len 108 [psm 1] > SDP SSA Rsp: tid 0x0 len 0x67 > count 100 > record #0 > aid 0x0000 (SrvRecHndl) > uint 0x10002 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1103 (DUN) uuid-16 0x1201 (Networking) > > aid 0x0004 (ProtocolDescList) > < < uuid-16 0x0100 (L2CAP) > < > uuid-16 0x0003 (RFCOMM) uint 0x1 > > > aid 0x0005 (BrwGrpList) > < uuid-16 0x1002 (PubBrwsGrp) > > aid 0x0006 (LangBaseAttrIDList) > < uint 0x656e uint 0x6a uint 0x100 > > aid 0x0009 (BTProfileDescList) > < < uuid-16 0x1103 (DUN) uint 0x100 > > > aid 0x0100 (SrvName) > str "Dial-up networking" > cont 00 > > So AFAICS, the difference is that most (?) phones use a uuid-16 for > BTProfileDescList (at least for the DUN item), while the Samsung uses > a uuid-32. Does anyone know if this is actually allowed? I'd guess > the specific integer type shouldn't matter, so if it doesn't, sdptool > probably shouldn't crash on it. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bluez-devel] sdptool segfaults 2005-03-03 15:54 ` Stephen Crane @ 2005-03-03 21:17 ` Marcel Holtmann 2005-03-18 19:47 ` Steven Singer 1 sibling, 0 replies; 4+ messages in thread From: Marcel Holtmann @ 2005-03-03 21:17 UTC (permalink / raw) To: BlueZ Mailing List Hi Steve, > This looks to me like the Samsung is formatting the profile descriptor > list incorrectly. I guess it should be a sequence of sequences of > { UUID, version } whereas the Samsung just formats it as a sequence. any idea on how to deal with these wrong profile descriptors? Regards Marcel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bluez-devel] sdptool segfaults 2005-03-03 15:54 ` Stephen Crane 2005-03-03 21:17 ` Marcel Holtmann @ 2005-03-18 19:47 ` Steven Singer 1 sibling, 0 replies; 4+ messages in thread From: Steven Singer @ 2005-03-18 19:47 UTC (permalink / raw) To: bluez-devel Stephen Crane wrote: > This looks to me like the Samsung is formatting the profile descriptor > list incorrectly. I guess it should be a sequence of sequences of > { UUID, version } whereas the Samsung just formats it as a sequence. I've been looking at this. Whereas the BT 1.1 SDP specification (BT 1.1 core spec, part E, section 5.1.10, pages 371 to 372) says: The BluetoothProfileDescriptorList attribute consists of a data element sequence in which each element is a profile descriptor that contains information about a Bluetooth profile to which the service represented by this service record conforms. Each profile descriptor is a data element sequence whose first element is the UUID assigned to the profile and whose second element is a 16-bit profile version number. The DUN profile spec (BT 1.1 profile spec, part K:7, section 5.3, table 5.1, page 244) says, for the attribute BluetoothProfileDescriptorList that the attribute is mandatory and its value is: Item Definition Type Value Status Default Profile #0 UUID Dial-up Networking M Parameter for Profile #0 Version UInt16 0x0100 O 0x100 Which marks the version parameter as optional and gives a default to be used if it's omitted (which might suggest that omitting it is not only allowed, but should be expected). It looks like there's an inconsistency in the spec. A profile author reading the profile spec may well conclude that the version is optional, whereas someone reading the protocol spec may just as easily conclude that it's mandatory for all profiles. A casual reading might suggest that the core spec states that each element of the attribute is a sequence with exactly two elements. In fact, it never quite gets round to stating the length of each sub-sequence, just the meaning of the first two elements (however, this does imply that it's mandatory to have at least two elements). It may be worth making sure that BlueZ is future proof against the addition of any further elements to each sub-sequence (though I suspect that, in practice, this extension would never be used as it would break too many current SDP client implementations). Looking at the other profiles in the BT 1.1 core spec, the version is optional for CTP, DUN and Fax and mandatory for Intercom and Headset. For the LAN access, object push, FTP and Synchronization profiles, the version number isn't separately marked as mandatory or optional, but the whole attribute is optional. It looks like all new profiles are marking the version as mandatory. What's clear is that if you are including the version number, then the correct format for the attribute is: SEQ{ ..., SEQ{ UUID, UINT16 }, ... } what's less clear is what the correct format is if you choose to omit the optional version. Should it be: SEQ{ ..., SEQ{ UUID }, ... } or simply: SEQ{ ..., UUID, ... } An analogy with the attribute ProtocolDescriptorList suggests the former, but it's probably prudent for BlueZ to cope with both. As a historical note, the profile version number was added between version 0.9 (10 May 1999) and the first draft of version 1.0 (5 Jul 1999) of the BT spec. At the same time, the attribute's name was changed from BluetoothProfileList to BluetoothProfileDescriptorList. Version 0.9 said in part E, section 5.1.10, page 323: The BluetoothProfileList attribute consists of a data element sequence in which each element is a UUID that represents a Bluetooth profile to which the service represented by this service record conforms. No products should ever have been released based on the 0.9 spec, and certainly nowadays no one is coding to that spec, but it's possible that the optional status of the profile version, and hence the inconsistency between the core and profile specs, dates back this far. Maybe it was intended that someone go through and mark all the version numbers as mandatory, or to state in the core spec that the second element in each sub-sequence was optional, but neither of these has happened. - Steven -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-18 19:47 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-03-03 15:33 [Bluez-devel] sdptool segfaults Dimitry Andric 2005-03-03 15:54 ` Stephen Crane 2005-03-03 21:17 ` Marcel Holtmann 2005-03-18 19:47 ` Steven Singer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.