10000 Bluetooth: L2CAP signaling channel: better default id, because 0 is an invalid id per the spec by XenoKovah · Pull Request #4734 · secdev/scapy · GitHub
[go: up one dir, main page]
Skip to content

Bluetooth: L2CAP signaling channel: better default id, because 0 is an invalid id per the spec #4734

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Jul 17, 2025
Merged

Bluetooth: L2CAP signaling channel: better default id, because 0 is an invalid id per the spec #4734

merged 2 commits into from
Jul 17, 2025

Conversation

XenoKovah
Copy link
Contributor

Per the Bluetooth 5.4 spec page 1043: "Signaling identifier 0x00 is an invalid identifier and shall never be used in any command."

The use of an id field of 0 here forces a scapy user to override the field instead of just using it as is for the first packet.

Better default, because 0 is a invalid id per the spec. This makes it…
25c4a44 
… so people don't need to override the default.
@codecov Codecov
Copy link
codecov bot commented May 7, 2025 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.02%. Comparing base (0648c0d) to head (607cf72).
Report is 43 commits behind head on master.

Additional details and impacted files 
@@            Coverage Diff             @@
##           master    #4734      +/-   ##
==========================================
- Coverage   82.20%   81.02%   -1.18%     
==========================================
  Files         361      365       +4     
  Lines       87195    89068    +1873     
==========================================
+ Hits        71679    72170     +491     
- Misses      15516    16898    +1382
Files with missing lines Coverage Δ
scapy/layers/bluetooth.py 90.50% <ø> (+0.03%) ⬆️

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@XenoKovah XenoKovah changed the title Bluetooth: L2CAP signaling channel: better default id, because 0 is a invalid id per the spec Bluetooth: L2CAP signaling channel: better default id, because 0 is an invalid id per the spec May 7, 2025
@antoniovazquezblanco
Copy link
Contributor

There are a set of tests that seem to be dependent of the default value of some packets, for this reason, this PR breaks testing:

failed 34B7B7FD 000.00s Test HCI_PHDR_Hdr
failed 88BBF466 000.00s Basic HCI_ACL_Hdr build & dissect
failed E06C4A06 000.00s Complex HCI - L2CAP build
failed F536B25B 000.00s HCI - L2CAP Echo test
failed 15D30BED 000.00s HCI - L2CAP Create Channel request

I would say that for those tests where a packet is built using the constructors and then the raw values are checked, that all fields should be specified if possible to avoid breakage like this...
Maybe some of those tests could be removed because some of them do not seem to have a very clear intent and purpose...

Let's see what the maintainers have to say...

@gpotter2
Copy link
Member
gpotter2 commented May 28, 2025 •
edited
Loading

You can either set id=0 in the tests or change the tested values, either work

Maybe some of those tests could be removed because some of them do not seem to have a very clear intent and purpose...

At the end of the day, even a stupid unit test makes you wonder "Hm, the behavior changed. Was it correct?".

@gpotter2 gpotter2 removed the broken label Jul 17, 2025
@gpotter2
Copy link
Member
gpotter2 commented Jul 17, 2025 •
edited
Loading

I've fixed the tests. Thanks for the PR.

@gpotter2 gpotter2 merged commit 8ddf371 into secdev:master Jul 17, 2025
23 of 24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@XenoKovah @antoniovazquezblanco @gpotter2
0