gh-129288: Add optional l2_cid and l2_bdaddr_type in BTPROTO_L2CAP socket address tuple #129293
Conversation
…ress tuple To be able to connect L2CAP sockets to Bluetooth LE devices, the l2_bdaddr_type must be set to BDADDR_LE_PUBLIC or BDADDR_LE_RANDOM. This change adds support for providing the l2_bdaddr_type as an optional, traliing element in the address tuple passed to connect()
|
All commit authors signed the Contributor License Agreement. |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
… socket.BDADDR_RANDOM only if defined for target Add check that BDADDR_BREDR is defined as Windows build may set USE_BLUETOOTH but not BDADDR_*
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
…ss tuple This change adds support for the CID field in the socket address tuple. This allows e.g raw LE ATT connections.
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
themadinventor
changed the title
…address fields Update documentation to mention the new cid and bdaddr_type fields for BTPROTO_L2CAP connections.
There was a problem hiding this comment.
Thank you!
I guess we don't have active Bluetooth experts, so I'll look at this mostly as a generic C dev.
Are you aware of some official docs that would explain what, for example, what a cid is? man l2cap doesn't help much.
Are there any tests you could add to Lib/test/test_socket.py?
I'm afraid the best reference is the Bluetooth Core specification itself. Basically, a CID (Channel Identifier) is a port number; each L2CAP connection has one CID for each end. Some fundamental services (like security and discovery things) are defined in the spec to use fixed/hardcoded CID on both ends. This is the use case for passing Normal applications will however open L2CAP connections using PSM (Protocol/Service Multiplexer), which is kind of an abstract port number, to specify a specific service. (The L2CAP connection handshake is described in Vol 3 Part 4 Chapter 4 in the Core spec.) So, while it's not possible to provide both
I'll look at it! 👍 |
Thanks! That looks like what I was looking for, it explains the terms and even clarifies the boundary between BlueZ & Bluetooth itself.
Thanks! Why I'm asking: for backwards compatibility where a tuple-based API needs to be extended, we can use StructSequence. Here we could define a 2-tuple-like object with additional named (but not numbered) fields. |
|
Right! I don't think the case with Overall, I don't think I can add a comment that we're discarding the |
BTPROTO_L2CAP extenstion: Expand the docs & provide link targets for the constants
|
For the tests, could you set |
encukou
added
the
🔨 test-with-buildbots
|
!buildbot .* |
|
🤖 New build scheduled with the buildbot fleet by @encukou for commit 5a1eaa3 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F129293%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
|
I've started the buildbots, which usually run after a change is merged, and check all the platforms & configurations. Don't be alarmed if some fail and mark the PR red; not all of them are stable. |
encukou
removed
the
🔨 test-with-buildbots
|
Great! Thank you for the review and all the help! 🌟 |
To be able to connect L2CAP sockets to Bluetooth LE devices, the
l2_bdaddr_typefield insockaddr_l2must be set toBDADDR_LE_PUBLICorBDADDR_LE_RANDOM.Likewise, when opening a raw LE L2CAP socket to the ATT service,
l2_cidmust be set instead ofl2_psm.This change adds support for providing l2_cid and l2_bdaddr_type as optional, traliing elements in the address tuple passed to
connect()