Hi Iain, thanks for you reply! I think you missunderstood a bit. First, yes it is a handsfree kit. But: We don't want to provide our own proprietary SDP Stuff. This makes no sense cause we want to be compatible to other BT-devices supporting interesting BT-profiles like HFP etc. And also I was talking about the SDP-Server side means i want to sent responses. What we want to do is robustness testing, means our test SDP Server listens for a SDP request (which can come from headunit but also from any other sdp capable mobile phone or whatsoever to request the services provided by the communication partner). We have some predefined correct answers for some of the SDP requests, but before sending the one fitting for the received request we fuzz the answer, means we make it invalid regarding length etc. pp. Then we send this answer to the bt device under test and look if it becomes instable cause e.g. of missing checks in SDP implementation. There are thousands of tools like scapy doing such things for tcp/ip stack. We are doing similar tests for Bluetooth communication ( L2CAP, Obex and finally SDP, too). Here a correct and primarily robust implementation needs to be ensured through testing. The best way to do so is to confront the DuT with such invalid packets. I hope this help to understand a bit better. -- 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
