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

[XenoKovah]

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.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

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%)	:arrow_up:

... and 57 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[antoniovazquezblanco]

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]

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]

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