Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMP Data: first fragments are truncated #92

Open
XavierBoniface opened this issue Jul 12, 2021 · 4 comments
Open

SMP Data: first fragments are truncated #92

XavierBoniface opened this issue Jul 12, 2021 · 4 comments

Comments

@XavierBoniface
Copy link

XavierBoniface commented Jul 12, 2021

The first L2CAP fragments of SMP packets are truncated when capturing HCI logs using WPR or BTVS.

Log 1 (btvs) = DellLatitudeE7240.zip
Captured with Windows 11 on a Dell Latitude E7240 laptop with intel 7260 Bluetooth chip (see report_2021-7-12_19-2-48.txt)
See red and green markers in the HCI overview (Note: because of a sniffer issue they only appear in the Instant Timing view, then one can double click from there on the packet to make them appear in the HCI Injection Overview) : first fragments are truncated, others are not.
Here the air log was captured at the same time and we can map those HCI packets to the L2CAP packets exchanged over the air (yellow markers). Pairing was successful, what was exchanged on HCI was correct, it must be just btvs that truncates the data.

Log 2 (etl) = etl: BthTracing.zip and extracted cfa: BthTracing.btt.zip
Captured with Windows 10 PRO 21H1 on a Dell Vostro 3591 with Qualcomm 11ac QCA 9377 Bluetooth chip, driver version 10.0.0.953
Here we don't have the air logs and this is the problem: we cannot see what the SMP problem was :-(

Note: this is somewhat similar to #85.

@erikpe-msft
Copy link
Contributor

I left a comment on #85. This should be the same issue.

@XavierBoniface
Copy link
Author

XavierBoniface commented Jul 15, 2021

Thank you @erikpe-msft, clicking "Full Packet Logging" indeed fixed the issue.
Leaving this issue open still for now, as a reminder for you to document this feature.

Also, how can a user enable this directly in WPR?

@erikpe-msft
Copy link
Contributor

@XavierBoniface : btvs is currently the only way to enable full packet logging. In order to capture sensitive data with wpr, you'll need to run btvs and click Full Packet Logging, once, on that test system. Then you can close btvs. After that, wpr should capture the sensitive data just like btvs.

@XavierBoniface
Copy link
Author

Thank you. Yes, I had inferred that method already. It's just a bit cumbersome for a user that will only use wpr to have to install and run another tool (btvs) to change a configuration that affects also wpr. I had expected that there was an option in wpr to achieve the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants