Re: [PATCH] monitor: Add option to disable SCO packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luiz,

>>> I am confused. I assumed I made SCO off by default.
>>> 
>> 
>> Dumping the contents for SCO packets is OFF by default (enabled by
>> -S), that is, the hex dump part on the output bellow:
>> 
>>  SCO Data RX: Handle 257 flags 0x00 dlen 48
>> 
>>                                                               #3537
>> [hci0] 16.106123
>>        23 00 2b 00 20 00 06 00 0f 00 21 00 15 00 05 00  #.+. .....!.....
>>        1d 00 13 00 ff ff 15 00 1b 00 f8 ff f1 ff 0f 00  ................
>>        0f 00 fc ff f3 ff f8 ff f8 ff fa ff 02 00 00 00  ................
>> 
>> But without -S we still log the header / flags part for each packet:
>> 
>>  SCO Data RX: Handle 258 flags 0x00 dlen 48
>> 
>>                                                               #3541
>> [hci0] 14.128754
>> 
>>> Anyhow, I don’t want to see tons of independent options. Since next thing is you tell me that AVDTP media channel is also something you want to filter out. So then we better find a generic way to apply filters and also notifications about “dropped x packets due to filter” kinda hints.
>>> 
> 
> We might look at doing this kind of filtering using BPF instead which
> perhaps could be loaded from a file.

doing this BPF would be best.

>> My argument behind filtering out SCO is because AFAIU it is only data,
>> not signaling. On a quick look I had assumed there was no easy way to
>> separate AVDTP signaling from data, but on a second look is actually
>> quite obvious, so you are right, that would be an obvious next step
>> :-)
>> 
>> Maybe we could hide the SCO and AVDTP media channels by default? In
>> this case we could print a notification when the program starts that
>> these channels are being suppressed, and / or every time the channel
>> is established. That would be reflected on the package count printed
>> with the timestamp, and I'm not sure if that would be a problem: is
>> that number reflecting how many packets have been exchanged or
>> printed?
>> 
>> As much as I like the idea of a generic configurable filter, I can't
>> look into that atm.
> 
> BPF already works with Bluetooth socket so perhaps we just need a way
> to load the filter from file.
> 
> @Marcel: We never applied the patch below, are you okay with it:
> 
> https://www.spinics.net/lists/linux-bluetooth/msg71245.html

I somehow never saw that patch. Can you re-send it to the mailing list.

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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux