Hi Gustavo, > > > -i hciX option will show only data from the specified device > > > --- > > > monitor/main.c | 12 ++++++++++-- > > > monitor/packet.c | 10 +++++++++- > > > monitor/packet.h | 2 +- > > > 3 files changed, 20 insertions(+), 4 deletions(-) > > > > so what is this option actually good for? I think it is the wrong > > approach for dealing with this. > > I only want to see the output for one device. We one my test use case is two > devices in the machine communicating with each other. so btmon is designed to really get everything at once. Including adapters coming and going. More important it can tell if at one point an adapter was hci0 and next time it becomes hci1. Keep in mind that btmon is suppose to be run even with no adapters attached. So you can start it before doing anything. Filtering on index numbers becomes kinda funky then since you do not yet know the index of an adapter. You are just wildly guessing. > > We better have some generic filtering mechanism, then trying to just > > duplicate options from hcidump into btmon. > > > > btmon is different in the fact that it is actually able to record all > > packets from all devices. You also do not wanna filter based on index > > number. You wanna filter based on BD_ADDR and BR/EDR vs AMP. > > Filter based on BD_ADDR would work too, but is more painful to the user > however. I actually think having some sort of -f <filter> file where you can store BD_ADDR and potentially other filter options makes way more sense. Keep in mind that even for BD_ADDR filtering, you need to first inspect a few HCI packets on a newly added controller. Since a new controller has no BD_ADDR until Read_BD_Addr command has successfully. Only already added controllers have the BD_ADDR read. Regards Marcel -- 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
