Hi Jaikumar, On Mon, May 17, 2010, jaikumar Ganesh wrote: > Is there any use case for this that we are trying to solve i.e why are we > maintaining the list at the baseband level itself rather than reject it > somewhere in the upper layers or in the app that uses Bluez? E.g. in the case that some device keeps spamming us with pairing requests it's good to be able block them on a low level. Also this way there doesn't need to be duplicate code in each application to handle misbehaving devices. Furthermore, applications would probably want to keep serving legitimate devices while dealing with rogue devices at the same time. This feature allows the applications to simply shut out the misbehaving device on a low level and not worry about it after that (which in turn should hopefully simplify the application logic). End user and application concerns aside, what I'm personally looking forward to using this feature for is at the UPF's. It has happened quite often that platforms (particularly car kits and headsets) forget to delete our bdaddr after the test session and keep spamming us with connect requests throughout the rest of the event. This kind of behavior makes testing more difficult and messes up HCI traces, so having a simple switch to block out a device will be nice. Johan -- 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
