* [PATCH 1/2] android: Add initial Android Bluetooth HAL protocol API doc
From: Szymon Janc @ 2013-10-14 8:05 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
This IPC is used to communicate Android BlueZ daemon and HAL.
Currently specified are BT HAL "bluetooth" (BT_HARDWARE_MODULE_ID)
and following profile HALs:
"socket" (BT_PROFILE_SOCKETS_ID)
"hidhost" (BT_PROFILE_HIDHOST_ID)
"pan" (BT_PROFILE_PAN_ID)
"handsfree" (BT_PROFILE_HANDSFREE_ID)
"ad2p" (BT_PROFILE_ADVANCED_AUDIO_ID)
"health" (BT_PROFILE_HEALTH_ID)
---
android/hal-ipc-api.txt | 1247 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 1247 insertions(+)
create mode 100644 android/hal-ipc-api.txt
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
new file mode 100644
index 0000000..9a8b770
--- /dev/null
+++ b/android/hal-ipc-api.txt
@@ -0,0 +1,1247 @@
+Android HAL protocol for Bluetooth
+==================================
+
+The Android HAL daemon for Bluetooth functionality implements the Unix socket
+server protocol around /run/bluetooth/daemon (tentative location) or Linux
+abstract sockets (tentative name).
+
+The daemon is single threaded and uses a mainloop for scheduling and general
+operation.
+
+The protocol is SOCK_SEQPACKET based and follows a strict PDU specification
+with a generic header and initial registration exchange. The communication
+is driven from the HAL with command/response exchanges. The daemon will use
+notification to signal events. The protocol is single PDU exchanged based,
+meaning every command requires a response. Notification does not require
+any confirmation. Not handling this PDU exchange leads to a disconnection of
+the socket.
+
+Command/response and notification use separate sockets. First connected socket
+is used for command/response, second for notification. All services are
+multi-plexed over same pair of sockets. Separation is done to ease
+implementation of simple HAL library with dedicated thread for handling
+notification.
+
+This strict protocol requirement is done to match C based callbacks and
+callout functions that are running in a thread inside the HAL and might
+block.
+
+ .--Android--. .--Android--.
+ | daemon | | HAL |
+ | | Command | |
+ | | <-------------------------- | |
+ | | | |
+ | | --------------------------> | |
+ | | Response | |
+ | | | |
+ | | | |
+ | | Notification | |
+ | | --------------------------> | |
+ | | | |
+ '-----------' '-----------'
+
+Every packet will follow the basic header to support simple multi-plexing
+over the same socket. It will also support a basic control channel with service
+id 0.
+
+ 0 8 16 24 31
+ +--------------+--------------+--------------+--------------+
+ | Service ID | Opcode | Data Length |
+ +--------------+--------------+-----------------------------+
+ | |
+
+The unique service ID is assigned by this specification for each HAL.
+
+As general rule of thumb, the opcode for command matches the opcode for a
+response. Or the opcode 0x00 for an error is returned.
+
+Notification opcodes start from 0x80.
+
+All command/response opcodes have the least significant bit not set. And all
+notifications have the least significant bit set.
+
+The HAL modules only have the job to map the callback and event functions
+to the protocol. They do not need to do anything else. Below is an example
+of a sample transaction for the Bluetooth Core HAL and enabling of an
+adapter.
+
+ HAL Daemon
+ ----------------------------------------------------
+
+ call enable() --> command 0x01
+ return enable() <-- response 0x01
+
+ call adapter_state_changed() <-- notification 0x81
+ return adapter_state_changed()
+
+When the Android hardware framework calls into the Bluetooth Core HAL
+and executes the enable() callback, the HAL module sends the enable
+command with opcode 0x01 to the daemon. As soon as the daemon responds,
+the callback will return with the appropriate result.
+
+After the daemon switched on the adapter, it will send a notification
+with opcode 0x81 to the HAL module.
+
+The Bluetooth Core HAL and Bluetooth Socket HAL are guaranteed to be
+available from the daemon. All other HAL modules are optional.
+
+When the Bluetooth Core HAL init() function is called, it should open
+the socket and register both "bluetooth" and "socket" service modules. It is
+required to register "socket" service at the same time since the HAL module
+does not have its own init() function.
+
+When new profiles are initiated, the get_profile_interface() callback
+will load the profile and during init() of the profile, it should register the
+specific service.
+
+ Bluetooth main thread Daemon
+ -------------------------------------------------------
+
+ init() --> open command socket
+ --> open notification socket
+ --> register module "bluetooth"
+ --> register module "socket"
+
+ get_profile_interface() --> return profile struct
+ --> continue on Handsfree thread
+
+
+ Handsfree thread Daemon
+ --------------------------------------------------------
+
+ init() --> register module handsfree
+
+
+Core Service (ID 0)
+===================
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Error (1 octet)
+
+ Opcode 0x01 - Register module command/response
+
+ Command parameters: Service id (1 octet)
+ Response parameters: <none>
+
+ In case a command is sent for an undeclared service ID, it will
+ be rejected. Also there will be no notifications for undeclared
+ service ID.
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Unregister module command/response
+
+ Command parameters: Service id (1 octet)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+
+Bluetooth Core HAL (ID 1)
+=========================
+
+Android HAL name: "bluetooth" (BT_HARDWARE_MODULE_ID)
+
+Commands and responses:
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Opcode 0x01 - Enable command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Disable command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x03 - Get Adapter Properties command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x04 - Get Adapter Property command/response
+
+ Command parameters: Property type (1 octet)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x05 - Set Adapter Property command/response
+
+ Command parameters: Property type (1 octet)
+ Property length (2 octets)
+ Property value (variable)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x06 - Get Remote Device Properties command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x07 - Get Remote Device Property command/response
+
+ Command parameters: Remote address (6 octets)
+ Property type (1 octet)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x08 - Set Remote Device Property command/response
+
+ Command parameters: Remote address (6 octets)
+ Property type (1 octet)
+ Property length (2 octets)
+ Property value (variable)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x09 - Get Remote Service Record command/response
+
+ Command parameters: Remote address (6 octets)
+ UUID (16 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0a - Get Remote Services command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0b - Start Discovery command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0c - Cancel Discovery command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0d - Create Bond command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0e - Remove Bond command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0f - Cancel Bond command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x10 - PIN Reply command/response
+
+ Command parameters: Remote address (6 octets)
+ Accept (1 octet)
+ PIN length (1 octet)
+ PIN code (16 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x11 - SSP Reply command/response
+
+ Command parameters: Remote address (6 octets)
+ SSP variant (1 octet)
+ Accept (1 octet)
+ Passkey (4 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x12 - DUT Mode Configure command/response
+
+ Command parameters: Enable (1 octet)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x13 - DUT Mode Send command/response
+
+ Command parameters: Opcode (2 octets)
+ Length (1 octet)
+ Data (variable)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x14 - LE Test Mode command/response
+
+ Command parameters: Opcode (2 octets)
+ Length (1 octet)
+ Data (variable)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Adapter State Changed notification
+
+ Notifications parameters: State (1 octect)
+
+ Opcode 0x82 - Adapter Properties Changed notification
+
+ Notification parameters: Status (1 octect)
+ Num properties (1 octet)
+ Type[i] (1 octect)
+ Length[i] (2 octets)
+ Value[i] (variable)
+
+ Opcode 0x83 - Remote Device Properties notification
+
+ Notification parameters: Status (1 octect)
+ Remote address (6 octets)
+ Num properties (1 octet)
+ Type[i] (1 octect)
+ Length[i] (2 octets)
+ Value[i] (variable)
+
+ Opcode 0x84 - Device Found notification
+
+ Notification parameters: Num properties (1 octet)
+ Type[i] (1 octect)
+ Length[i] (2 octets)
+ Value[i] (variable)
+
+ Opcode 0x85 - Discovery State Changed notification
+
+ Notifications parameters: State (1 octect)
+
+ Opcode 0x86 - PIN Request notification
+
+ Notification parameters: Remote address (6 octets)
+ Remote name (249 octets)
+ Class of device (3 octets)
+
+ Opcode 0x87 - SSP Request notification
+
+ Notification parameters: Remote address (6 octets)
+ Remote name (249 octets)
+ Class of device (3 octets)
+ Pairing variant (1 octet)
+ Passkey (4 octets)
+
+ Opcode 0x88 - Bond State Changed notification
+
+ Notification parameters: Status (1 octect)
+ Remote address (6 octets)
+ Bond state (1 octet)
+
+ Opcode 0x89 - ACL State Changed notification
+
+ Notification parameters: Status (1 octect)
+ Remote address (6 octets)
+ ACL state (1 octet)
+
+ Opcode 0x8a - DUT Mode Receive notification
+
+ Notification parameters: Opcode (2 octects)
+ Length (1 octet)
+ Data (variable)
+
+ Opcode 0x8b - LE Test Mode notification
+
+ Notification parameters: Status (1 octect)
+ Num packets (2 octets)
+
+
+Bluetooth Socket HAL (ID 2)
+===========================
+
+Android HAL name:: "socket" (BT_PROFILE_SOCKETS_ID)
+
+Commands and responses:
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Listen command/response
+
+ Command parameters: Socket type (1 octet)
+ Service name (256 octets)
+ Service UUID (16 octets)
+ Channel (2 octets)
+ Socket flags (1 octet)
+ Response parameters: File descriptor (inline)
+
+ Valid socket types: 0x01 = RFCOMM
+ 0x02 = SCO
+ 0x03 = L2CAP
+
+ Valid socket flags: 0x01 = Encrypt
+ 0x02 = Auth
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Connect command/response
+
+ Command parameters: Remote address (6 octets)
+ Socket type (1 octet)
+ Service UUID (16 octets)
+ Channel (2 octets)
+ Socket flags (1 octet)
+ Response parameters: File descriptor (inline)
+
+ Valid socket types: 0x01 = RFCOMM
+ 0x02 = SCO
+ 0x03 = L2CAP
+
+ Valid socket flags: 0x01 = Encrypt
+ 0x02 = Auth
+
+ In case of an error, the error response will be returned.
+
+
+Bluetooth HID Host HAL (ID 3)
+============================
+
+Android HAL name: "hidhost" (BT_PROFILE_HIDHOST_ID)
+
+Commands and responses:
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Connect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Disconnect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x03 - Virtual Unplug command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x04 - Set Info command/response
+
+ Command parameters: Remote address (6 octets)
+ Attribute mask (2 octets)
+ Subclass (1 octet)
+ Application ID (1 octet)
+ Vendor ID (2 octets)
+ Product ID (2 octets)
+ Version (2 octets)
+ Country code (1 octet)
+ Descriptor length (2 octet)
+ Descriptor value (884 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x05 - Get Protocol command/response
+
+ Command parameters: Remote address (6 octets)
+ Protocol mode (1 octet)
+ Response parameters: <none>
+
+ Valid protocol modes: 0x00 = Report
+ 0x01 = Boot
+ 0xff = Unsupported
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x06 - Set Protocol command/response
+
+ Command parameters: Remote address (6 octets)
+ Protocol mode (1 octet)
+ Response parameters: <none>
+
+ Valid protocol modes: 0x00 = Report
+ 0x01 = Boot
+ 0xff = Unsupported
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x07 - Get Report command/response
+
+ Command parameters: Remote address (6 octets)
+ Report type (1 octet)
+ Report ID (1 octet)
+ Buffer size (2 octet)
+ Response parameters: <none>
+
+ Valid report types: 0x01 = Input
+ 0x02 = Output
+ 0x03 = Feature
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x08 - Set Report command/response
+
+ Command parameters: Remote address (6 octets)
+ Report type (1 octet)
+ ...
+ Response parameters: <none>
+
+ Valid report types: 0x01 = Input
+ 0x02 = Output
+ 0x03 = Feature
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x09 - Send Data command/response
+
+ Command parameters: Remote address (6 octets)
+ ...
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Connection State notification
+
+ Notification parameters: Remote address (6 octets)
+
+ Valid connection states: 0x00 = Connected
+ 0x01 = Connecting
+ 0x02 = Disconnected
+ 0x03 = Disconnecting
+ 0x04 = Failed - Mouse from host
+ 0x05 = Failed - Keyboard from host
+ 0x06 = Failed - Too many devices
+ 0x07 = Failed - No HID driver
+ 0x08 = Failed - generic
+ 0x09 = Unknown
+
+ Opcode 0x82 - HID Info notification
+
+ Notification parameters: Remote address (6 octets)
+ Attribute mask (2 octets)
+ Subclass (1 octet)
+ Application ID (1 octet)
+ Vendor ID (2 octets)
+ Product ID (2 octets)
+ Version (2 octets)
+ Country code (1 octet)
+ Descriptor length (2 octet)
+ Descriptor value (884 octets)
+
+ Opcode 0x83 - Protocol Mode notification
+
+ Notification parameters: Remote address (6 octets)
+ Status (1 octet)
+ Protocol mode (1 octet)
+
+ Valid protocol modes: 0x00 = Report
+ 0x01 = Boot
+ 0xff = Unsupported
+
+ Opcode 0x84 - Idle Time notification
+
+ Notification parameters: Remote address (6 octets)
+ Status (1 octet)
+ Idle time (2 octets)
+
+ Opcode 0x85 - Get Report notification
+
+ Notification parameters: Remote address (6 octets)
+ Status (1 octet)
+ Report length (2 octets)
+ Report data (variable)
+
+ Opcode 0x86 - Virtual Unplug notification
+
+ Notification parameters: Remote address (6 octets)
+ Status (1 octet)
+
+ Valid status values: 0x00 = Ok
+ 0x01 = Handshake - Device not ready
+ 0x02 = Handshake - Invalid report ID
+ 0x03 = Handshake - Transaction not SPT
+ 0x04 = Handshake - Invalid parameter
+ 0x05 = Handshake - Generic error
+ 0x06 = General error
+ 0x07 = SDP error
+ 0x08 = Set protocol error
+ 0x09 = Device database full
+ 0x0a = Device type not supported
+ 0x0b = No resources
+ 0x0c = Authentication failed
+ 0x0d = HDL
+
+
+Bluetooth PAN HAL (ID 4)
+========================
+
+Android HAL name: "pan" (BT_PROFILE_PAN_ID)
+
+Commands and responses:
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Enable command/response
+
+ Command parameters: Local role (1 octet)
+ Response parameters: <none>
+
+ Valid role values: 0x00 = None
+ 0x01 = NAP
+ 0x02 = PANU
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Get Local Role command/response
+
+ Command parameters: <none>
+ Response parameters: Local role (1 octet)
+
+ Valid role values: 0x00 = None
+ 0x01 = NAP
+ 0x02 = PANU
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x03 - Connect command/response
+
+ Command parameters: Remote address (6 octets)
+ Local role (1 octet)
+ Remote role (1 octet)
+ Response parameters: <none>
+
+ Valid role values: 0x01 = NAP
+ 0x02 = PANU
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x04 - Disconnect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Control State notification
+
+ Notification parameters: Control state (1 octect)
+ Status (1 octet)
+ Local role (1 octet)
+ Interface name (17 octet)
+
+ Valid control states: 0x00 = Enabled
+ 0x01 = Disabled
+
+ Valid role values: 0x00 = None
+ 0x01 = NAP
+ 0x02 = PANU
+
+ Opcode 0x82 - Connection State notification
+
+ Notification parameters: Connection state (1 octect)
+ Status (1 octet)
+ Remote address (6 octets)
+ Local role (1 octet)
+ Remote role (1 octet)
+
+ Valid connection states: 0x00 = Connected
+ 0x01 = Connecting
+ 0x02 = Disconnected
+ 0x03 = Disconnecting
+
+ Valid role values: 0x01 = NAP
+ 0x02 = PANU
+
+
+Bluetooth Handsfree HAL (ID 5)
+==============================
+
+Android HAL name: "handsfree" (BT_PROFILE_HANDSFREE_ID)
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Connect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Disconnect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x03 - Connect Audio command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x04 - Disconnect Audio command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x05 - Start Voice Recognition command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x06 - Stop Voice Recognition command/response
+
+ Command parameters: <none>
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x07 - Volume Control command/response
+
+ Command parameters: Volume type (1 octet)
+ Volume (1 octet)
+ Response parameters: <none>
+
+ Valid volume types: 0x00 = Speaker
+ 0x01 = Microphone
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x08 - Device Status Notification command/response
+
+ Command parameters: Network state (1 octet)
+ Service type (1 octet)
+ Signal strength (1 octet)
+ Battery level (1 octet)
+ Response parameters: <none>
+
+ Valid network states: 0x00 = Not available
+ 0x01 = Available
+
+ Valid service types: 0x00 = Home network
+ 0x01 = Roaming network
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x09 - COPS Response command/response
+
+ Command parameters: COPS command response (string)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0a - CIND Response command/response
+
+ Command parameters: Service (1 octet)
+ Number of active calls (1 octet)
+ Number of held calls (1 octet)
+ Call setup state (1 octet)
+ Signal strength (1 octet)
+ Roaming indicator (1 octet)
+ Battery level (1 octet)
+ Response parameters: <none>
+
+ Valid call setup states: 0x00 = Active
+ 0x01 = Held
+ 0x02 = Dialing
+ 0x03 = Alerting
+ 0x04 = Incoming
+ 0x05 = Waiting
+ 0x06 = Idle
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0b - Formatted AT Response command/response
+
+ Command parameters: Pre-formatted AT response (string)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0c - AT Response command/response
+
+ Command parameters: Response code (1 octet)
+ Error code (1 octet)
+ Response parameters: <none>
+
+ Valid response codes: 0x00 = ERROR
+ 0x01 = OK
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0d - CLCC Response command/response
+
+ Command parameters: Call index (1 octet)
+ Call direction (1 octet)
+ Call state (1 octet)
+ Call mode (1 octet)
+ Call multiparty type (1 octet)
+ Call number type (1 octet)
+ Call number (variable)
+ Response parameters: <none>
+
+ Valid call directions: 0x00 = Outgoing
+ 0x01 = Incoming
+
+ Valid call states: 0x00 = Active
+ 0x01 = Held
+ 0x02 = Dialing
+ 0x03 = Alerting
+ 0x04 = Incoming
+ 0x05 = Waiting
+ 0x06 = Idle
+
+ Valid call modes: 0x00 = Voice
+ 0x01 = Data
+ 0x02 = Fax
+
+ Valid multiparty types: 0x00 = Single call
+ 0x01 = Multiparty call
+
+ Valid number types: 0x81 = Unknown
+ 0x91 = International
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x0e - Phone Status Change command/response
+
+ Command parameters: Number of active calls (1 octet)
+ Number of held calls (1 octet)
+ Call setup state (1 octet)
+ Call number type (1 octet)
+ Call number (variable)
+ Response parameters: <none>
+
+ Valid call setup states: 0x00 = Active
+ 0x01 = Held
+ 0x02 = Dialing
+ 0x03 = Alerting
+ 0x04 = Incoming
+ 0x05 = Waiting
+ 0x06 = Idle
+
+ Valid number types: 0x81 = Unknown
+ 0x91 = International
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Connection State notification
+
+ Notification parameters: Connection state (1 octect)
+ Remote address (6 octets)
+
+ Valid connection states: 0x00 = Disconnected
+ 0x01 = Connecting
+ 0x02 = Connected
+ 0x03 = SLC connected
+ 0x04 = Disconnecting
+
+ Opcode 0x82 - Audio State notification
+
+ Notification parameters: Audio state (1 octect)
+ Remote address (6 octets)
+
+ Valid audio states: 0x00 = Disconnected
+ 0x01 = Connecting
+ 0x02 = Connected
+ 0x03 = Disconnecting
+
+ Opcode 0x83 - Voice Recognition Command notification
+
+ Notification parameters: Voice recognition state (1 octet)
+
+ Valid voice recognition states: 0x00 = Stopped
+ 0x01 = Started
+
+ Opcode 0x84 - Answer Call Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x85 - Hangup Call Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x86 - Volume Command notification
+
+ Notification parameters: Volume type (1 octet)
+
+ Valid volume types: 0x00 = Speaker
+ 0x01 = Microphone
+
+ Opcode 0x87 - Dial Call Command notification
+
+ Notification parameters: Number (string)
+
+ Opcode 0x88 - DTMF Command notification
+
+ Notification parameters: Tone (1 octet)
+
+ Opcode 0x89 - NREC Command notification
+
+ Notification parameters: NREC types (1 octet)
+
+ Valid NREC types: 0x00 = Stop
+ 0x01 = Start
+
+ Opcode 0x8a - CHLD Command notification
+
+ Notification parameters: NREC types (1 octet)
+
+ Valid CHLD types: 0x00 = Release and hold
+ 0x01 = Release active and accept held
+ 0x02 = Hold active and accept held
+ 0x03 = Add held call to conference
+
+ Opcode 0x8b - CNUM Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x8c - CIND Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x8d - COPS Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x8e - CLCC Command notification
+
+ Notification parameters: <none>
+
+ Opcode 0x8f - Unknown AT Command notification
+
+ Notification parameters: AT command (string)
+
+ Opcode 0x90 - Key Pressed Command notification
+
+ Notification parameters: <none>
+
+
+Bluetooth Advanced Audio HAL (ID 6)
+===================================
+
+Android HAL name: "ad2p" (BT_PROFILE_ADVANCED_AUDIO_ID)
+
+Commands and responses:
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Connect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Disconnect command/response
+
+ Command parameters: Remote address (6 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Connection State notification
+
+ Notification parameters: Connection state (1 octect)
+ Remote address (6 octets)
+
+ Valid connection states: 0x00 = Disconnected
+ 0x01 = Connecting
+ 0x02 = Connected
+ 0x03 = Disconnecting
+
+ Opcode 0x82 - Audio State notification
+
+ Notification parameters: Audio state (1 octect)
+ Remote address (6 octets)
+
+ Valid connection states: 0x00 = Remote suspend
+ 0x01 = Stopped
+ 0x02 = Started
+
+
+Bluetooth Health HAL (ID 7)
+===========================
+
+Android HAL name: "health" (BT_PROFILE_HEALTH_ID)
+
+ Opcode 0x00 - Error response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Register Application command/response
+
+ Command parameters: Application name (string)
+ Provider name (string)
+ Service name (string)
+ Service description (string)
+ Number of MDEP (1 octet)
+ MDEP Role[i] (1 octet)
+ Data type[i] (1 octet)
+ Channel type[i] (1 octet)
+ MDEP description (string)
+ Response parameters: Application ID (2 octets)
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x02 - Unregister Application command/response
+
+ Command parameters: Application ID (2 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x03 - Connect Channel command/response
+
+ Command parameters: Application ID (2 octets)
+ Remote address (6 octets)
+ MDEP index (1 octet)
+ Response parameters: Channel ID (2 octets)
+
+ In case of an error, the error response will be returned.
+
+ Opcode 0x04 - Destroy Channel command/response
+
+ Command parameters: Channel ID (2 octets)
+ Response parameters: <none>
+
+ In case of an error, the error response will be returned.
+
+Notifications:
+
+ Opcode 0x81 - Application Registration State notification
+
+ Notification parameters: Application ID (2 octects)
+ Application state (1 octet)
+
+ Valid application states: 0x00 = Registration success
+ 0x01 = Registration failed
+ 0x02 = Deregistration success
+ 0x03 = Deregistration failed
+
+ Opcode 0x82 - Channel State notification
+
+ Notification parameters: Application ID (2 octects)
+ Remote address (6 octets)
+ MDEP index (1 octet)
+ Channel ID (2 octets)
+ Channel state (1 octet)
+ File descriptor (inline)
+
+ Valid channel states: 0x00 = Connecting
+ 0x01 = Connected
+ 0x02 = Disconnecting
+ 0x03 = Disconnected
+ 0x04 = Destroyed
+
+
+Bluetooth Remote Control HAL (ID 8)
+===================================
+
+Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
+
+ Opcode 0x00 - Error response
+ Opcode 0x01 - Get Play Status command/response
+ Opcode 0x02 - List Player Application Attributes command/response
+ Opcode 0x03 - List Player Application Values command/response
+ Opcode 0x04 - Get Player Application Values command/response
+ Opcode 0x05 - Get Player Application Attributes Text command/response
+ Opcode 0x06 - Get Player Application Values Text command/response
+ Opcode 0x07 - Get Element Attributes Text command/response
+ Opcode 0x08 - Set Player Attributes Value command/response
+ Opcode 0x09 - Register Notification command/response
+
+ Opcode 0x81 - Get Play Status notification
+ Opcode 0x82 - List Player Application Attributes notification
+ ...
+
+
+Bluetooth GATT HAL (ID 9)
+=========================
+
+Android HAL name: "gatt" (BT_PROFILE_GATT_ID)
+
+ Opcode 0x00 - Error response
+ Opcode 0x01 - Register Client command/response
+ Opcode 0x02 - Unregister Client command/response
+ Opcode 0x03 - Scan command/response
+ Opcode 0x04 - Connect Device command/response
+ Opcode 0x05 - Disconnect Device command/response
+ Opcode 0x06 - Refresh command/response
+ Opcode 0x07 - Search Service command/response
+ Opcode 0x08 - Get Included Service command/response
+ Opcode 0x09 - Get Characteristic command/response
+ Opcode 0x0a - Get Descriptor command/response
+ Opcode 0x0b - Read Characteristic command/response
+ Opcode 0x0c - Write Characteristic command/response
+ Opcode 0x0d - Read Descriptor command/response
+ Opcode 0x0e - Write Descriptor command/response
+ Opcode 0x0f - Execute Write command/response
+ Opcode 0x10 - Register For Notification command/response
+ Opcode 0x11 - Deregister For Notification command/response
+ Opcode 0x12 - Read Remote RSSI command/response
+ Opcode 0x13 - Get Device Type command/response
+ Opcode 0x14 - Test Command command/response
+ Opcode 0x15 - Register Server command/response
+ Opcode 0x16 - Unregister Server command/response
+ Opcode 0x17 - Connect Peripheral command/response
+ Opcode 0x18 - Disconnect Peripheral command/response
+ Opcode 0x19 - Add Service command/response
+ Opcode 0x1a - Add Included Service command/response
+ Opcode 0x1b - Add Characteristic command/response
+ Opcode 0x1c - Add Descriptor command/response
+ Opcode 0x1d - Start Service command/response
+ Opcode 0x1e - Stop Service command/response
+ Opcode 0x1f - Delete Service command/response
+ Opcode 0x20 - Send Indication command/response
+ Opcode 0x21 - Send Response command/response
+
+ Opcode 0x81 - Register Client notification
+ Opcode 0x82 - Scan Result notification
+ Opcode 0x83 - Connect Device notification
+ Opcode 0x84 - Disconnect Device notification
+ Opcode 0x85 - Search Complete notification
+ Opcode 0x86 - Search Result notification
+ Opcode 0x87 - Get Characteristic notification
+ Opcode 0x88 - Get Descriptor notification
+ Opcode 0x89 - Get Included Service notification
+ Opcode 0x8a - Register For Notification notification
+ Opcode 0x8b - Notify notification
+ Opcode 0x8c - Read Characteristic notification
+ Opcode 0x8d - Write Characteristic notification
+ Opcode 0x8e - Execute Write notification
+ Opcode 0x8f - Read Descriptor notification
+ Opcode 0x90 - Write Descriptor notification
+ Opcode 0x91 - Read Remote RSSI notification
+ Opcode 0x92 - Register Server notification
+ Opcode 0x93 - Connection notification
+ Opcode 0x94 - Service Added notification
+ Opcode 0x95 - Included Service Added notification
+ Opcode 0x96 - Characteristic Added notification
+ Opcode 0x97 - Descriptor Added notification
+ Opcode 0x98 - Service Started notification
+ Opcode 0x99 - Service Stopped notification
+ Opcode 0x9a - Service Deleted notification
+ Opcode 0x9b - Request Read notification
+ Opcode 0x9c - Request Write notification
+ Opcode 0x9d - Request Execute Write notification
+ Opcode 0x9e - Response Confirmation notification
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Increase minor version of core module
From: Johan Hedberg @ 2013-10-13 20:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381694942-59440-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> There have been a lot of changes in the core Bluetooth handling
> lately. So it is a good idea to increase the module version.
>
> The module version is not used anywhere, but it makes debugging
> a little bit simpler if versions can be distinguished.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/af_bluetooth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Add support for per socket msg_name callback
From: Johan Hedberg @ 2013-10-13 20:15 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381694129-51112-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> This allows to add a per socket msg_name callback that can be used
> for updating the msg_name information for recvmsg() system calls.
>
> This feature is used by another patch to support address information
> on L2CAP connectionless channels.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/bluetooth.h | 1 +
> net/bluetooth/af_bluetooth.c | 15 +++++++++++----
> 2 files changed, 12 insertions(+), 4 deletions(-)
Both patches have been applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH] Bluetooth: Increase minor version of core module
From: Marcel Holtmann @ 2013-10-13 20:09 UTC (permalink / raw)
To: linux-bluetooth
There have been a lot of changes in the core Bluetooth handling
lately. So it is a good idea to increase the module version.
The module version is not used anywhere, but it makes debugging
a little bit simpler if versions can be distinguished.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/af_bluetooth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index f0aadea..61501c9 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -30,7 +30,7 @@
#include <net/bluetooth/bluetooth.h>
#include <linux/proc_fs.h>
-#define VERSION "2.16"
+#define VERSION "2.17"
/* Bluetooth sockets */
#define BT_MAX_PROTO 8
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Provide msg_name callback for L2CAP connectionless channels
From: Marcel Holtmann @ 2013-10-13 19:55 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need
to receive the remote BD_ADDR and PSM information via msg_name from
the recvmsg() system call.
So in case the L2CAP socket is for connectionless channels, provide
a msg_name callback that can update the data. Also store the remote
BD_ADDR and PSM in the SKB so it can be extracted later on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/bluetooth.h | 2 ++
net/bluetooth/l2cap_core.c | 4 ++++
net/bluetooth/l2cap_sock.c | 15 ++++++++++++++-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 896aad8..bf2ddff 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -284,6 +284,8 @@ struct bt_skb_cb {
__u8 force_active;
struct l2cap_ctrl control;
struct hci_req_ctrl req;
+ bdaddr_t bdaddr;
+ __le16 psm;
};
#define bt_cb(skb) ((struct bt_skb_cb *)((skb)->cb))
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 769c379..f6b5f94 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -6459,6 +6459,10 @@ static void l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm,
if (chan->imtu < skb->len)
goto drop;
+ /* Store remote BD_ADDR and PSM for msg_name */
+ bacpy(&bt_cb(skb)->bdaddr, &conn->hcon->dst);
+ bt_cb(skb)->psm = psm;
+
if (!chan->ops->recv(chan, skb))
return;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 8fe9f49..f1b462f 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1137,6 +1137,19 @@ static void l2cap_sock_destruct(struct sock *sk)
skb_queue_purge(&sk->sk_write_queue);
}
+static void l2cap_skb_msg_name(struct sk_buff *skb, void *msg_name,
+ int *msg_namelen)
+{
+ struct sockaddr_l2 *la = (struct sockaddr_l2 *) msg_name;
+
+ memset(la, 0, sizeof(struct sockaddr_l2));
+ la->l2_family = AF_BLUETOOTH;
+ la->l2_psm = bt_cb(skb)->psm;
+ bacpy(&la->l2_bdaddr, &bt_cb(skb)->bdaddr);
+
+ *msg_namelen = sizeof(struct sockaddr_l2);
+}
+
static void l2cap_sock_init(struct sock *sk, struct sock *parent)
{
struct l2cap_chan *chan = l2cap_pi(sk)->chan;
@@ -1163,13 +1176,13 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
security_sk_clone(parent, sk);
} else {
-
switch (sk->sk_type) {
case SOCK_RAW:
chan->chan_type = L2CAP_CHAN_RAW;
break;
case SOCK_DGRAM:
chan->chan_type = L2CAP_CHAN_CONN_LESS;
+ bt_sk(sk)->skb_msg_name = l2cap_skb_msg_name;
break;
case SOCK_SEQPACKET:
case SOCK_STREAM:
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Add support for per socket msg_name callback
From: Marcel Holtmann @ 2013-10-13 19:55 UTC (permalink / raw)
To: linux-bluetooth
This allows to add a per socket msg_name callback that can be used
for updating the msg_name information for recvmsg() system calls.
This feature is used by another patch to support address information
on L2CAP connectionless channels.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/bluetooth.h | 1 +
net/bluetooth/af_bluetooth.c | 15 +++++++++++----
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 1d6e484..896aad8 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -221,6 +221,7 @@ struct bt_sock {
struct list_head accept_q;
struct sock *parent;
unsigned long flags;
+ void (*skb_msg_name)(struct sk_buff *, void *, int *);
};
enum {
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 9c7e4ed..f0aadea 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -221,12 +221,12 @@ int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
if (flags & (MSG_OOB))
return -EOPNOTSUPP;
- msg->msg_namelen = 0;
-
skb = skb_recv_datagram(sk, flags, noblock, &err);
if (!skb) {
- if (sk->sk_shutdown & RCV_SHUTDOWN)
+ if (sk->sk_shutdown & RCV_SHUTDOWN) {
+ msg->msg_namelen = 0;
return 0;
+ }
return err;
}
@@ -238,9 +238,16 @@ int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
skb_reset_transport_header(skb);
err = skb_copy_datagram_iovec(skb, 0, msg->msg_iov, copied);
- if (err == 0)
+ if (err == 0) {
sock_recv_ts_and_drops(msg, sk, skb);
+ if (bt_sk(sk)->skb_msg_name)
+ bt_sk(sk)->skb_msg_name(skb, msg->msg_name,
+ &msg->msg_namelen);
+ else
+ msg->msg_namelen = 0;
+ }
+
skb_free_datagram(sk, skb);
return err ? : copied;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Use l2cap_pi(sk) directly where possible
From: Johan Hedberg @ 2013-10-13 19:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381689367-7104-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> There are few places where it makes sense to use l2cap_pi(sk) directly
> instead of assigning it to temporary structure.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/l2cap_sock.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: Store SCO address information in its own socket structure
From: Johan Hedberg @ 2013-10-13 19:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381685643-57066-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> The address information of SCO sockets should be stored in its own
> socket structure. Trying to generalize them is not helpful since
> different transports have different address types.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/sco.h | 2 ++
> net/bluetooth/sco.c | 36 ++++++++++++++++++------------------
> 2 files changed, 20 insertions(+), 18 deletions(-)
All three patches have been applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use SCO addresses from HCI connection directly
From: Johan Hedberg @ 2013-10-13 19:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381684522-35575-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> Instead of storing a pointer to the addresses for the HCI device
> and HCI connection, use them directly. With the recent changes
> to address tracking of HCI connections, this becomes simple.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/sco.h | 3 ---
> net/bluetooth/sco.c | 20 ++++++++------------
> 2 files changed, 8 insertions(+), 15 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH] Bluetooth: Use l2cap_pi(sk) directly where possible
From: Marcel Holtmann @ 2013-10-13 18:36 UTC (permalink / raw)
To: linux-bluetooth
There are few places where it makes sense to use l2cap_pi(sk) directly
instead of assigning it to temporary structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/l2cap_sock.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 6262e23..8fe9f49 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -976,13 +976,12 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
{
- int err;
struct sock *sk = chan->data;
- struct l2cap_pinfo *pi = l2cap_pi(sk);
+ int err;
lock_sock(sk);
- if (pi->rx_busy_skb) {
+ if (l2cap_pi(sk)->rx_busy_skb) {
err = -ENOMEM;
goto done;
}
@@ -998,9 +997,9 @@ static int l2cap_sock_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb)
* acked and reassembled until there is buffer space
* available.
*/
- if (err < 0 && pi->chan->mode == L2CAP_MODE_ERTM) {
- pi->rx_busy_skb = skb;
- l2cap_chan_busy(pi->chan, 1);
+ if (err < 0 && chan->mode == L2CAP_MODE_ERTM) {
+ l2cap_pi(sk)->rx_busy_skb = skb;
+ l2cap_chan_busy(chan, 1);
err = 0;
}
@@ -1128,6 +1127,7 @@ static void l2cap_sock_destruct(struct sock *sk)
if (l2cap_pi(sk)->chan)
l2cap_chan_put(l2cap_pi(sk)->chan);
+
if (l2cap_pi(sk)->rx_busy_skb) {
kfree_skb(l2cap_pi(sk)->rx_busy_skb);
l2cap_pi(sk)->rx_busy_skb = NULL;
@@ -1139,8 +1139,7 @@ static void l2cap_sock_destruct(struct sock *sk)
static void l2cap_sock_init(struct sock *sk, struct sock *parent)
{
- struct l2cap_pinfo *pi = l2cap_pi(sk);
- struct l2cap_chan *chan = pi->chan;
+ struct l2cap_chan *chan = l2cap_pi(sk)->chan;
BT_DBG("sk %p", sk);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/3] Bluetooth: Remove src and dst fields from bt_sock structure
From: Marcel Holtmann @ 2013-10-13 17:34 UTC (permalink / raw)
To: linux-bluetooth
Every socket protocol now stores its own address information. So
just remove the generic src and dst fields since they are no longer
needed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/bluetooth.h | 2 --
net/bluetooth/af_bluetooth.c | 4 +---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 5fd5106..1d6e484 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -218,8 +218,6 @@ void baswap(bdaddr_t *dst, bdaddr_t *src);
struct bt_sock {
struct sock sk;
- bdaddr_t src;
- bdaddr_t dst;
struct list_head accept_q;
struct sock *parent;
unsigned long flags;
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index e6e1278..9c7e4ed 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -617,15 +617,13 @@ static int bt_seq_show(struct seq_file *seq, void *v)
struct bt_sock *bt = bt_sk(sk);
seq_printf(seq,
- "%pK %-6d %-6u %-6u %-6u %-6lu %pMR %pMR %-6lu",
+ "%pK %-6d %-6u %-6u %-6u %-6lu %-6lu",
sk,
atomic_read(&sk->sk_refcnt),
sk_rmem_alloc_get(sk),
sk_wmem_alloc_get(sk),
from_kuid(seq_user_ns(seq), sock_i_uid(sk)),
sock_i_ino(sk),
- &bt->src,
- &bt->dst,
bt->parent? sock_i_ino(bt->parent): 0LU);
if (l->custom_seq_show) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: Store RFCOMM address information in its own socket structure
From: Marcel Holtmann @ 2013-10-13 17:34 UTC (permalink / raw)
To: linux-bluetooth
The address information of RFCOMM sockets should be stored in its
own socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/rfcomm.h | 2 ++
net/bluetooth/rfcomm/sock.c | 28 +++++++++++++++-------------
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 7afd419..3588f48 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -300,6 +300,8 @@ struct rfcomm_conninfo {
struct rfcomm_pinfo {
struct bt_sock bt;
+ bdaddr_t src;
+ bdaddr_t dst;
struct rfcomm_dlc *dlc;
u8 channel;
u8 sec_level;
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 072938d..df17276 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -87,7 +87,8 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
parent->sk_data_ready(parent, 0);
} else {
if (d->state == BT_CONNECTED)
- rfcomm_session_getaddr(d->session, &bt_sk(sk)->src, NULL);
+ rfcomm_session_getaddr(d->session,
+ &rfcomm_pi(sk)->src, NULL);
sk->sk_state_change(sk);
}
@@ -110,7 +111,7 @@ static struct sock *__rfcomm_get_sock_by_addr(u8 channel, bdaddr_t *src)
sk_for_each(sk, &rfcomm_sk_list.head) {
if (rfcomm_pi(sk)->channel == channel &&
- !bacmp(&bt_sk(sk)->src, src))
+ !bacmp(&rfcomm_pi(sk)->src, src))
break;
}
@@ -132,11 +133,11 @@ static struct sock *rfcomm_get_sock_by_channel(int state, u8 channel, bdaddr_t *
if (rfcomm_pi(sk)->channel == channel) {
/* Exact match. */
- if (!bacmp(&bt_sk(sk)->src, src))
+ if (!bacmp(&rfcomm_pi(sk)->src, src))
break;
/* Closest match */
- if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY))
+ if (!bacmp(&rfcomm_pi(sk)->src, BDADDR_ANY))
sk1 = sk;
}
}
@@ -355,7 +356,7 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
err = -EADDRINUSE;
} else {
/* Save source address */
- bacpy(&bt_sk(sk)->src, &sa->rc_bdaddr);
+ bacpy(&rfcomm_pi(sk)->src, &sa->rc_bdaddr);
rfcomm_pi(sk)->channel = sa->rc_channel;
sk->sk_state = BT_BOUND;
}
@@ -393,13 +394,14 @@ static int rfcomm_sock_connect(struct socket *sock, struct sockaddr *addr, int a
}
sk->sk_state = BT_CONNECT;
- bacpy(&bt_sk(sk)->dst, &sa->rc_bdaddr);
+ bacpy(&rfcomm_pi(sk)->dst, &sa->rc_bdaddr);
rfcomm_pi(sk)->channel = sa->rc_channel;
d->sec_level = rfcomm_pi(sk)->sec_level;
d->role_switch = rfcomm_pi(sk)->role_switch;
- err = rfcomm_dlc_open(d, &bt_sk(sk)->src, &sa->rc_bdaddr, sa->rc_channel);
+ err = rfcomm_dlc_open(d, &rfcomm_pi(sk)->src, &sa->rc_bdaddr,
+ sa->rc_channel);
if (!err)
err = bt_sock_wait_state(sk, BT_CONNECTED,
sock_sndtimeo(sk, flags & O_NONBLOCK));
@@ -429,7 +431,7 @@ static int rfcomm_sock_listen(struct socket *sock, int backlog)
}
if (!rfcomm_pi(sk)->channel) {
- bdaddr_t *src = &bt_sk(sk)->src;
+ bdaddr_t *src = &rfcomm_pi(sk)->src;
u8 channel;
err = -EINVAL;
@@ -530,9 +532,9 @@ static int rfcomm_sock_getname(struct socket *sock, struct sockaddr *addr, int *
sa->rc_family = AF_BLUETOOTH;
sa->rc_channel = rfcomm_pi(sk)->channel;
if (peer)
- bacpy(&sa->rc_bdaddr, &bt_sk(sk)->dst);
+ bacpy(&sa->rc_bdaddr, &rfcomm_pi(sk)->dst);
else
- bacpy(&sa->rc_bdaddr, &bt_sk(sk)->src);
+ bacpy(&sa->rc_bdaddr, &rfcomm_pi(sk)->src);
*len = sizeof(struct sockaddr_rc);
return 0;
@@ -951,8 +953,8 @@ int rfcomm_connect_ind(struct rfcomm_session *s, u8 channel, struct rfcomm_dlc *
bt_sock_reclassify_lock(sk, BTPROTO_RFCOMM);
rfcomm_sock_init(sk, parent);
- bacpy(&bt_sk(sk)->src, &src);
- bacpy(&bt_sk(sk)->dst, &dst);
+ bacpy(&rfcomm_pi(sk)->src, &src);
+ bacpy(&rfcomm_pi(sk)->dst, &dst);
rfcomm_pi(sk)->channel = channel;
sk->sk_state = BT_CONFIG;
@@ -979,7 +981,7 @@ static int rfcomm_sock_debugfs_show(struct seq_file *f, void *p)
sk_for_each(sk, &rfcomm_sk_list.head) {
seq_printf(f, "%pMR %pMR %d %d\n",
- &bt_sk(sk)->src, &bt_sk(sk)->dst,
+ &rfcomm_pi(sk)->src, &rfcomm_pi(sk)->dst,
sk->sk_state, rfcomm_pi(sk)->channel);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/3] Bluetooth: Store SCO address information in its own socket structure
From: Marcel Holtmann @ 2013-10-13 17:34 UTC (permalink / raw)
To: linux-bluetooth
The address information of SCO sockets should be stored in its own
socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/sco.h | 2 ++
net/bluetooth/sco.c | 36 ++++++++++++++++++------------------
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
index 94703a2..2019d1a 100644
--- a/include/net/bluetooth/sco.h
+++ b/include/net/bluetooth/sco.h
@@ -69,6 +69,8 @@ struct sco_conn {
struct sco_pinfo {
struct bt_sock bt;
+ bdaddr_t src;
+ bdaddr_t dst;
__u32 flags;
__u16 setting;
struct sco_conn *conn;
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 2cc8f42..a92aeba 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -158,9 +158,9 @@ static int sco_connect(struct sock *sk)
struct hci_dev *hdev;
int err, type;
- BT_DBG("%pMR -> %pMR", &bt_sk(sk)->src, &bt_sk(sk)->dst);
+ BT_DBG("%pMR -> %pMR", &sco_pi(sk)->src, &sco_pi(sk)->dst);
- hdev = hci_get_route(&bt_sk(sk)->dst, &bt_sk(sk)->src);
+ hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src);
if (!hdev)
return -EHOSTUNREACH;
@@ -177,7 +177,7 @@ static int sco_connect(struct sock *sk)
goto done;
}
- hcon = hci_connect_sco(hdev, type, &bt_sk(sk)->dst,
+ hcon = hci_connect_sco(hdev, type, &sco_pi(sk)->dst,
sco_pi(sk)->setting);
if (IS_ERR(hcon)) {
err = PTR_ERR(hcon);
@@ -192,7 +192,7 @@ static int sco_connect(struct sock *sk)
}
/* Update source addr of the socket */
- bacpy(&bt_sk(sk)->src, &hcon->src);
+ bacpy(&sco_pi(sk)->src, &hcon->src);
err = sco_chan_add(conn, sk, NULL);
if (err)
@@ -266,7 +266,7 @@ static struct sock *__sco_get_sock_listen_by_addr(bdaddr_t *ba)
if (sk->sk_state != BT_LISTEN)
continue;
- if (!bacmp(&bt_sk(sk)->src, ba))
+ if (!bacmp(&sco_pi(sk)->src, ba))
return sk;
}
@@ -287,11 +287,11 @@ static struct sock *sco_get_sock_listen(bdaddr_t *src)
continue;
/* Exact match. */
- if (!bacmp(&bt_sk(sk)->src, src))
+ if (!bacmp(&sco_pi(sk)->src, src))
break;
/* Closest match */
- if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY))
+ if (!bacmp(&sco_pi(sk)->src, BDADDR_ANY))
sk1 = sk;
}
@@ -471,7 +471,7 @@ static int sco_sock_bind(struct socket *sock, struct sockaddr *addr, int addr_le
goto done;
}
- bacpy(&bt_sk(sk)->src, &sa->sco_bdaddr);
+ bacpy(&sco_pi(sk)->src, &sa->sco_bdaddr);
sk->sk_state = BT_BOUND;
@@ -501,7 +501,7 @@ static int sco_sock_connect(struct socket *sock, struct sockaddr *addr, int alen
lock_sock(sk);
/* Set destination address and psm */
- bacpy(&bt_sk(sk)->dst, &sa->sco_bdaddr);
+ bacpy(&sco_pi(sk)->dst, &sa->sco_bdaddr);
err = sco_connect(sk);
if (err)
@@ -518,7 +518,7 @@ done:
static int sco_sock_listen(struct socket *sock, int backlog)
{
struct sock *sk = sock->sk;
- bdaddr_t *src = &bt_sk(sk)->src;
+ bdaddr_t *src = &sco_pi(sk)->src;
int err = 0;
BT_DBG("sk %p backlog %d", sk, backlog);
@@ -622,9 +622,9 @@ static int sco_sock_getname(struct socket *sock, struct sockaddr *addr, int *len
*len = sizeof(struct sockaddr_sco);
if (peer)
- bacpy(&sa->sco_bdaddr, &bt_sk(sk)->dst);
+ bacpy(&sa->sco_bdaddr, &sco_pi(sk)->dst);
else
- bacpy(&sa->sco_bdaddr, &bt_sk(sk)->src);
+ bacpy(&sa->sco_bdaddr, &sco_pi(sk)->src);
return 0;
}
@@ -1013,8 +1013,8 @@ static void sco_conn_ready(struct sco_conn *conn)
sco_sock_init(sk, parent);
- bacpy(&bt_sk(sk)->src, &conn->hcon->src);
- bacpy(&bt_sk(sk)->dst, &conn->hcon->dst);
+ bacpy(&sco_pi(sk)->src, &conn->hcon->src);
+ bacpy(&sco_pi(sk)->dst, &conn->hcon->dst);
hci_conn_hold(conn->hcon);
__sco_chan_add(conn, sk, parent);
@@ -1047,8 +1047,8 @@ int sco_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr, __u8 *flags)
if (sk->sk_state != BT_LISTEN)
continue;
- if (!bacmp(&bt_sk(sk)->src, &hdev->bdaddr) ||
- !bacmp(&bt_sk(sk)->src, BDADDR_ANY)) {
+ if (!bacmp(&sco_pi(sk)->src, &hdev->bdaddr) ||
+ !bacmp(&sco_pi(sk)->src, BDADDR_ANY)) {
lm |= HCI_LM_ACCEPT;
if (test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags))
@@ -1107,8 +1107,8 @@ static int sco_debugfs_show(struct seq_file *f, void *p)
read_lock(&sco_sk_list.lock);
sk_for_each(sk, &sco_sk_list.head) {
- seq_printf(f, "%pMR %pMR %d\n", &bt_sk(sk)->src,
- &bt_sk(sk)->dst, sk->sk_state);
+ seq_printf(f, "%pMR %pMR %d\n", &sco_pi(sk)->src,
+ &sco_pi(sk)->dst, sk->sk_state);
}
read_unlock(&sco_sk_list.lock);
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Use SCO addresses from HCI connection directly
From: Marcel Holtmann @ 2013-10-13 17:15 UTC (permalink / raw)
To: linux-bluetooth
Instead of storing a pointer to the addresses for the HCI device
and HCI connection, use them directly. With the recent changes
to address tracking of HCI connections, this becomes simple.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/sco.h | 3 ---
net/bluetooth/sco.c | 20 ++++++++------------
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
index e252a31..94703a2 100644
--- a/include/net/bluetooth/sco.h
+++ b/include/net/bluetooth/sco.h
@@ -55,9 +55,6 @@ struct sco_conninfo {
struct sco_conn {
struct hci_conn *hcon;
- bdaddr_t *dst;
- bdaddr_t *src;
-
spinlock_t lock;
struct sock *sk;
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 96bd388..2cc8f42 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -92,9 +92,6 @@ static struct sco_conn *sco_conn_add(struct hci_conn *hcon)
hcon->sco_data = conn;
conn->hcon = hcon;
- conn->src = &hdev->bdaddr;
- conn->dst = &hcon->dst;
-
if (hdev->sco_mtu > 0)
conn->mtu = hdev->sco_mtu;
else
@@ -156,16 +153,14 @@ static int sco_chan_add(struct sco_conn *conn, struct sock *sk,
static int sco_connect(struct sock *sk)
{
- bdaddr_t *src = &bt_sk(sk)->src;
- bdaddr_t *dst = &bt_sk(sk)->dst;
struct sco_conn *conn;
struct hci_conn *hcon;
struct hci_dev *hdev;
int err, type;
- BT_DBG("%pMR -> %pMR", src, dst);
+ BT_DBG("%pMR -> %pMR", &bt_sk(sk)->src, &bt_sk(sk)->dst);
- hdev = hci_get_route(dst, src);
+ hdev = hci_get_route(&bt_sk(sk)->dst, &bt_sk(sk)->src);
if (!hdev)
return -EHOSTUNREACH;
@@ -182,7 +177,8 @@ static int sco_connect(struct sock *sk)
goto done;
}
- hcon = hci_connect_sco(hdev, type, dst, sco_pi(sk)->setting);
+ hcon = hci_connect_sco(hdev, type, &bt_sk(sk)->dst,
+ sco_pi(sk)->setting);
if (IS_ERR(hcon)) {
err = PTR_ERR(hcon);
goto done;
@@ -196,7 +192,7 @@ static int sco_connect(struct sock *sk)
}
/* Update source addr of the socket */
- bacpy(src, conn->src);
+ bacpy(&bt_sk(sk)->src, &hcon->src);
err = sco_chan_add(conn, sk, NULL);
if (err)
@@ -999,7 +995,7 @@ static void sco_conn_ready(struct sco_conn *conn)
} else {
sco_conn_lock(conn);
- parent = sco_get_sock_listen(conn->src);
+ parent = sco_get_sock_listen(&conn->hcon->src);
if (!parent) {
sco_conn_unlock(conn);
return;
@@ -1017,8 +1013,8 @@ static void sco_conn_ready(struct sco_conn *conn)
sco_sock_init(sk, parent);
- bacpy(&bt_sk(sk)->src, conn->src);
- bacpy(&bt_sk(sk)->dst, conn->dst);
+ bacpy(&bt_sk(sk)->src, &conn->hcon->src);
+ bacpy(&bt_sk(sk)->dst, &conn->hcon->dst);
hci_conn_hold(conn->hcon);
__sco_chan_add(conn, sk, parent);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/4] Bluetooth: Access RFCOMM session addresses through L2CAP channel
From: Johan Hedberg @ 2013-10-13 17:03 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381682997-26437-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> The L2CAP socket structure does not contain the address information
> anymore. They need to be accessed through the L2CAP channel.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/rfcomm/core.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
All four patches have been applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Return the correct address type for L2CAP sockets
From: Johan Hedberg @ 2013-10-13 17:02 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381679441-57025-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> The L2CAP sockets can use BR/EDR public, LE public and LE random
> addresses for various combinations of source and destination
> devices. So make sure that getsockname(), getpeername() and
> accept() return the correct address type.
>
> For this the address type of the source and destination is stored
> with the L2CAP channel information. The stored address type is
> not the one specific for the HCI protocol. It is the address
> type used for the L2CAP sockets and the management interface.
>
> The underlying HCI connections store the HCI address type. If
> needed, it gets converted to the socket address type.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/l2cap.h | 5 +++--
> net/bluetooth/l2cap_core.c | 18 ++++++++++++++++++
> net/bluetooth/l2cap_sock.c | 3 +++
> 3 files changed, 24 insertions(+), 2 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Store address information in L2CAP channel structure
From: Johan Hedberg @ 2013-10-13 17:02 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381677167-41315-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> With the effort of abstracting the L2CAP socket from the underlying
> L2CAP channel it is important to store the source and destination
> address information directly in the L2CAP channel structure.
>
> Direct access to the HCI connection address information is not
> possible since they might not be avaiable at L2CAP channel
> creation time. The address information will be updated when
> the underlying BR/EDR or LE connection status changes.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/l2cap.h | 2 ++
> net/bluetooth/l2cap_core.c | 61 +++++++++++++++++--------------------------
> net/bluetooth/l2cap_sock.c | 6 ++---
> 3 files changed, 29 insertions(+), 40 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH 4/4] Bluetooth: Access BNEP session addresses through L2CAP channel
From: Marcel Holtmann @ 2013-10-13 16:49 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/bnep/core.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
index e430b1a..a841d3e 100644
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -32,6 +32,7 @@
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/l2cap.h>
#include <net/bluetooth/hci_core.h>
#include "bnep.h"
@@ -510,20 +511,13 @@ static int bnep_session(void *arg)
static struct device *bnep_get_device(struct bnep_session *session)
{
- bdaddr_t *src = &bt_sk(session->sock->sk)->src;
- bdaddr_t *dst = &bt_sk(session->sock->sk)->dst;
- struct hci_dev *hdev;
struct hci_conn *conn;
- hdev = hci_get_route(dst, src);
- if (!hdev)
+ conn = l2cap_pi(session->sock->sk)->chan->conn->hcon;
+ if (!conn)
return NULL;
- conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, dst);
-
- hci_dev_put(hdev);
-
- return conn ? &conn->dev : NULL;
+ return &conn->dev;
}
static struct device_type bnep_type = {
@@ -539,8 +533,8 @@ int bnep_add_connection(struct bnep_connadd_req *req, struct socket *sock)
BT_DBG("");
- baswap((void *) dst, &bt_sk(sock->sk)->dst);
- baswap((void *) src, &bt_sk(sock->sk)->src);
+ baswap((void *) dst, &l2cap_pi(sock->sk)->chan->dst);
+ baswap((void *) src, &l2cap_pi(sock->sk)->chan->src);
/* session struct allocated as private part of net_device */
dev = alloc_netdev(sizeof(struct bnep_session),
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/4] Bluetooth: Access HIDP session addresses through L2CAP channel
From: Marcel Holtmann @ 2013-10-13 16:49 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hidp/core.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index bdc35a7..292e619 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -767,10 +767,10 @@ static int hidp_setup_hid(struct hidp_session *session,
strncpy(hid->name, req->name, sizeof(req->name) - 1);
snprintf(hid->phys, sizeof(hid->phys), "%pMR",
- &bt_sk(session->ctrl_sock->sk)->src);
+ &l2cap_pi(session->ctrl_sock->sk)->chan->src);
snprintf(hid->uniq, sizeof(hid->uniq), "%pMR",
- &bt_sk(session->ctrl_sock->sk)->dst);
+ &l2cap_pi(session->ctrl_sock->sk)->chan->dst);
hid->dev.parent = &session->conn->hcon->dev;
hid->ll_driver = &hidp_hid_driver;
@@ -1283,23 +1283,29 @@ static int hidp_session_thread(void *arg)
static int hidp_verify_sockets(struct socket *ctrl_sock,
struct socket *intr_sock)
{
+ struct l2cap_chan *ctrl_chan, *intr_chan;
struct bt_sock *ctrl, *intr;
struct hidp_session *session;
if (!l2cap_is_socket(ctrl_sock) || !l2cap_is_socket(intr_sock))
return -EINVAL;
+ ctrl_chan = l2cap_pi(ctrl_sock->sk)->chan;
+ intr_chan = l2cap_pi(intr_sock->sk)->chan;
+
+ if (bacmp(&ctrl_chan->src, &intr_chan->src) ||
+ bacmp(&ctrl_chan->dst, &intr_chan->dst))
+ return -ENOTUNIQ;
+
ctrl = bt_sk(ctrl_sock->sk);
intr = bt_sk(intr_sock->sk);
- if (bacmp(&ctrl->src, &intr->src) || bacmp(&ctrl->dst, &intr->dst))
- return -ENOTUNIQ;
if (ctrl->sk.sk_state != BT_CONNECTED ||
intr->sk.sk_state != BT_CONNECTED)
return -EBADFD;
/* early session check, we check again during session registration */
- session = hidp_session_find(&ctrl->dst);
+ session = hidp_session_find(&ctrl_chan->dst);
if (session) {
hidp_session_put(session);
return -EEXIST;
@@ -1332,7 +1338,7 @@ int hidp_connection_add(struct hidp_connadd_req *req,
if (!conn)
return -EBADFD;
- ret = hidp_session_new(&session, &bt_sk(ctrl_sock->sk)->dst, ctrl_sock,
+ ret = hidp_session_new(&session, &chan->dst, ctrl_sock,
intr_sock, req, conn);
if (ret)
goto out_conn;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/4] Bluetooth: Access CMTP session addresses through L2CAP channel
From: Marcel Holtmann @ 2013-10-13 16:49 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/cmtp/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/cmtp/core.c b/net/bluetooth/cmtp/core.c
index e0a6ebf..67fe5e8 100644
--- a/net/bluetooth/cmtp/core.c
+++ b/net/bluetooth/cmtp/core.c
@@ -340,20 +340,20 @@ int cmtp_add_connection(struct cmtp_connadd_req *req, struct socket *sock)
down_write(&cmtp_session_sem);
- s = __cmtp_get_session(&bt_sk(sock->sk)->dst);
+ s = __cmtp_get_session(&l2cap_pi(sock->sk)->chan->dst);
if (s && s->state == BT_CONNECTED) {
err = -EEXIST;
goto failed;
}
- bacpy(&session->bdaddr, &bt_sk(sock->sk)->dst);
+ bacpy(&session->bdaddr, &l2cap_pi(sock->sk)->chan->dst);
session->mtu = min_t(uint, l2cap_pi(sock->sk)->chan->omtu,
l2cap_pi(sock->sk)->chan->imtu);
BT_DBG("mtu %d", session->mtu);
- sprintf(session->name, "%pMR", &bt_sk(sock->sk)->dst);
+ sprintf(session->name, "%pMR", &session->bdaddr);
session->sock = sock;
session->state = BT_CONFIG;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/4] Bluetooth: Access RFCOMM session addresses through L2CAP channel
From: Marcel Holtmann @ 2013-10-13 16:49 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/rfcomm/core.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index ca957d3..27e936a 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -641,13 +641,13 @@ static struct rfcomm_session *rfcomm_session_get(bdaddr_t *src, bdaddr_t *dst)
{
struct rfcomm_session *s;
struct list_head *p, *n;
- struct bt_sock *sk;
+ struct l2cap_chan *chan;
list_for_each_safe(p, n, &session_list) {
s = list_entry(p, struct rfcomm_session, list);
- sk = bt_sk(s->sock->sk);
+ chan = l2cap_pi(s->sock->sk)->chan;
- if ((!bacmp(src, BDADDR_ANY) || !bacmp(&sk->src, src)) &&
- !bacmp(&sk->dst, dst))
+ if ((!bacmp(src, BDADDR_ANY) || !bacmp(&chan->src, src)) &&
+ !bacmp(&chan->dst, dst))
return s;
}
return NULL;
@@ -732,11 +732,11 @@ failed:
void rfcomm_session_getaddr(struct rfcomm_session *s, bdaddr_t *src, bdaddr_t *dst)
{
- struct sock *sk = s->sock->sk;
+ struct l2cap_chan *chan = l2cap_pi(s->sock->sk)->chan;
if (src)
- bacpy(src, &bt_sk(sk)->src);
+ bacpy(src, &chan->src);
if (dst)
- bacpy(dst, &bt_sk(sk)->dst);
+ bacpy(dst, &chan->dst);
}
/* ---- RFCOMM frame sending ---- */
@@ -2112,12 +2112,11 @@ static int rfcomm_dlc_debugfs_show(struct seq_file *f, void *x)
rfcomm_lock();
list_for_each_entry(s, &session_list, list) {
+ struct l2cap_chan *chan = l2cap_pi(s->sock->sk)->chan;
struct rfcomm_dlc *d;
list_for_each_entry(d, &s->dlcs, list) {
- struct sock *sk = s->sock->sk;
-
seq_printf(f, "%pMR %pMR %ld %d %d %d %d\n",
- &bt_sk(sk)->src, &bt_sk(sk)->dst,
+ &chan->src, &chan->dst,
d->state, d->dlci, d->mtu,
d->rx_credits, d->tx_credits);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Return the correct address type for L2CAP sockets
From: Marcel Holtmann @ 2013-10-13 15:50 UTC (permalink / raw)
To: linux-bluetooth
The L2CAP sockets can use BR/EDR public, LE public and LE random
addresses for various combinations of source and destination
devices. So make sure that getsockname(), getpeername() and
accept() return the correct address type.
For this the address type of the source and destination is stored
with the L2CAP channel information. The stored address type is
not the one specific for the HCI protocol. It is the address
type used for the L2CAP sockets and the management interface.
The underlying HCI connections store the HCI address type. If
needed, it gets converted to the socket address type.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/l2cap.h | 5 +++--
net/bluetooth/l2cap_core.c | 18 ++++++++++++++++++
net/bluetooth/l2cap_sock.c | 3 +++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 26b5066..a27d51d 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -445,8 +445,11 @@ struct l2cap_chan {
__u8 state;
bdaddr_t dst;
+ __u8 dst_type;
bdaddr_t src;
+ __u8 src_type;
__le16 psm;
+ __le16 sport;
__u16 dcid;
__u16 scid;
@@ -457,8 +460,6 @@ struct l2cap_chan {
__u8 chan_type;
__u8 chan_policy;
- __le16 sport;
-
__u8 sec_level;
__u8 ident;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index be3e0f8..769c379 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -59,6 +59,18 @@ static void l2cap_send_disconn_req(struct l2cap_chan *chan, int err);
static void l2cap_tx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
struct sk_buff_head *skbs, u8 event);
+static inline __u8 bdaddr_type(struct hci_conn *hcon, __u8 type)
+{
+ if (hcon->type == LE_LINK) {
+ if (type == ADDR_LE_DEV_PUBLIC)
+ return BDADDR_LE_PUBLIC;
+ else
+ return BDADDR_LE_RANDOM;
+ }
+
+ return BDADDR_BREDR;
+}
+
/* ---- L2CAP channels ---- */
static struct l2cap_chan *__l2cap_get_chan_by_dcid(struct l2cap_conn *conn,
@@ -1398,6 +1410,8 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
bacpy(&chan->src, &conn->hcon->src);
bacpy(&chan->dst, &conn->hcon->dst);
+ chan->src_type = bdaddr_type(conn->hcon, conn->hcon->src_type);
+ chan->dst_type = bdaddr_type(conn->hcon, conn->hcon->dst_type);
__l2cap_chan_add(conn, chan);
@@ -1818,6 +1832,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
/* Set destination address and psm */
bacpy(&chan->dst, dst);
+ chan->dst_type = dst_type;
chan->psm = psm;
chan->dcid = cid;
@@ -1851,6 +1866,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
/* Update source addr of the socket */
bacpy(&chan->src, &hcon->src);
+ chan->src_type = bdaddr_type(hcon, hcon->src_type);
l2cap_chan_unlock(chan);
l2cap_chan_add(conn, chan);
@@ -3791,6 +3807,8 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
bacpy(&chan->src, &conn->hcon->src);
bacpy(&chan->dst, &conn->hcon->dst);
+ chan->src_type = bdaddr_type(conn->hcon, conn->hcon->src_type);
+ chan->dst_type = bdaddr_type(conn->hcon, conn->hcon->dst_type);
chan->psm = psm;
chan->dcid = scid;
chan->local_amp_id = amp_id;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 9fe80d2..6262e23 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -113,6 +113,7 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
}
bacpy(&chan->src, &la.l2_bdaddr);
+ chan->src_type = la.l2_bdaddr_type;
chan->state = BT_BOUND;
sk->sk_state = BT_BOUND;
@@ -276,10 +277,12 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr,
la->l2_psm = chan->psm;
bacpy(&la->l2_bdaddr, &chan->dst);
la->l2_cid = cpu_to_le16(chan->dcid);
+ la->l2_bdaddr_type = chan->dst_type;
} else {
la->l2_psm = chan->sport;
bacpy(&la->l2_bdaddr, &chan->src);
la->l2_cid = cpu_to_le16(chan->scid);
+ la->l2_bdaddr_type = chan->src_type;
}
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Store address information in L2CAP channel structure
From: Marcel Holtmann @ 2013-10-13 15:12 UTC (permalink / raw)
To: linux-bluetooth
With the effort of abstracting the L2CAP socket from the underlying
L2CAP channel it is important to store the source and destination
address information directly in the L2CAP channel structure.
Direct access to the HCI connection address information is not
possible since they might not be avaiable at L2CAP channel
creation time. The address information will be updated when
the underlying BR/EDR or LE connection status changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/l2cap.h | 2 ++
net/bluetooth/l2cap_core.c | 61 +++++++++++++++++--------------------------
net/bluetooth/l2cap_sock.c | 6 ++---
3 files changed, 29 insertions(+), 40 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 1a929af..26b5066 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -444,6 +444,8 @@ struct l2cap_chan {
__u8 state;
+ bdaddr_t dst;
+ bdaddr_t src;
__le16 psm;
__u16 dcid;
__u16 scid;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 062e28e..be3e0f8 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -149,7 +149,7 @@ static struct l2cap_chan *__l2cap_global_chan_by_addr(__le16 psm, bdaddr_t *src)
struct l2cap_chan *c;
list_for_each_entry(c, &chan_list, global_l) {
- if (c->sport == psm && !bacmp(&bt_sk(c->sk)->src, src))
+ if (c->sport == psm && !bacmp(&c->src, src))
return c;
}
return NULL;
@@ -621,10 +621,8 @@ void l2cap_chan_del(struct l2cap_chan *chan, int err)
void l2cap_chan_close(struct l2cap_chan *chan, int reason)
{
struct l2cap_conn *conn = chan->conn;
- struct sock *sk = chan->sk;
- BT_DBG("chan %p state %s sk %p", chan, state_to_string(chan->state),
- sk);
+ BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
switch (chan->state) {
case BT_LISTEN:
@@ -635,6 +633,7 @@ void l2cap_chan_close(struct l2cap_chan *chan, int reason)
case BT_CONFIG:
if (chan->chan_type == L2CAP_CHAN_CONN_ORIENTED &&
conn->hcon->type == ACL_LINK) {
+ struct sock *sk = chan->sk;
__set_chan_timer(chan, sk->sk_sndtimeo);
l2cap_send_disconn_req(chan, reason);
} else
@@ -644,6 +643,7 @@ void l2cap_chan_close(struct l2cap_chan *chan, int reason)
case BT_CONNECT2:
if (chan->chan_type == L2CAP_CHAN_CONN_ORIENTED &&
conn->hcon->type == ACL_LINK) {
+ struct sock *sk = chan->sk;
struct l2cap_conn_rsp rsp;
__u16 result;
@@ -1257,8 +1257,6 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
mutex_lock(&conn->chan_lock);
list_for_each_entry_safe(chan, tmp, &conn->chan_l, list) {
- struct sock *sk = chan->sk;
-
l2cap_chan_lock(chan);
if (chan->chan_type != L2CAP_CHAN_CONN_ORIENTED) {
@@ -1284,6 +1282,7 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
l2cap_start_connection(chan);
} else if (chan->state == BT_CONNECT2) {
+ struct sock *sk = chan->sk;
struct l2cap_conn_rsp rsp;
char buf[128];
rsp.scid = cpu_to_le16(chan->dcid);
@@ -1341,8 +1340,6 @@ static struct l2cap_chan *l2cap_global_chan_by_scid(int state, u16 cid,
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
-
if (state && c->state != state)
continue;
@@ -1351,16 +1348,16 @@ static struct l2cap_chan *l2cap_global_chan_by_scid(int state, u16 cid,
int src_any, dst_any;
/* Exact match. */
- src_match = !bacmp(&bt_sk(sk)->src, src);
- dst_match = !bacmp(&bt_sk(sk)->dst, dst);
+ src_match = !bacmp(&c->src, src);
+ dst_match = !bacmp(&c->dst, dst);
if (src_match && dst_match) {
read_unlock(&chan_list_lock);
return c;
}
/* Closest match */
- src_any = !bacmp(&bt_sk(sk)->src, BDADDR_ANY);
- dst_any = !bacmp(&bt_sk(sk)->dst, BDADDR_ANY);
+ src_any = !bacmp(&c->src, BDADDR_ANY);
+ dst_any = !bacmp(&c->dst, BDADDR_ANY);
if ((src_match && dst_any) || (src_any && dst_match) ||
(src_any && dst_any))
c1 = c;
@@ -1399,8 +1396,8 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
chan->dcid = L2CAP_CID_ATT;
- bacpy(&bt_sk(chan->sk)->src, &conn->hcon->src);
- bacpy(&bt_sk(chan->sk)->dst, &conn->hcon->dst);
+ bacpy(&chan->src, &conn->hcon->src);
+ bacpy(&chan->dst, &conn->hcon->dst);
__l2cap_chan_add(conn, chan);
@@ -1721,8 +1718,6 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
-
if (state && c->state != state)
continue;
@@ -1731,16 +1726,16 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
int src_any, dst_any;
/* Exact match. */
- src_match = !bacmp(&bt_sk(sk)->src, src);
- dst_match = !bacmp(&bt_sk(sk)->dst, dst);
+ src_match = !bacmp(&c->src, src);
+ dst_match = !bacmp(&c->dst, dst);
if (src_match && dst_match) {
read_unlock(&chan_list_lock);
return c;
}
/* Closest match */
- src_any = !bacmp(&bt_sk(sk)->src, BDADDR_ANY);
- dst_any = !bacmp(&bt_sk(sk)->dst, BDADDR_ANY);
+ src_any = !bacmp(&c->src, BDADDR_ANY);
+ dst_any = !bacmp(&c->dst, BDADDR_ANY);
if ((src_match && dst_any) || (src_any && dst_match) ||
(src_any && dst_any))
c1 = c;
@@ -1762,10 +1757,10 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
__u8 auth_type;
int err;
- BT_DBG("%pMR -> %pMR (type %u) psm 0x%2.2x", &bt_sk(sk)->src, dst,
+ BT_DBG("%pMR -> %pMR (type %u) psm 0x%2.2x", &chan->src, dst,
dst_type, __le16_to_cpu(psm));
- hdev = hci_get_route(dst, &bt_sk(sk)->src);
+ hdev = hci_get_route(dst, &chan->src);
if (!hdev)
return -EHOSTUNREACH;
@@ -1822,9 +1817,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
}
/* Set destination address and psm */
- lock_sock(sk);
- bacpy(&bt_sk(sk)->dst, dst);
- release_sock(sk);
+ bacpy(&chan->dst, dst);
chan->psm = psm;
chan->dcid = cid;
@@ -1857,9 +1850,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
}
/* Update source addr of the socket */
- lock_sock(sk);
- bacpy(&bt_sk(sk)->src, &hcon->src);
- release_sock(sk);
+ bacpy(&chan->src, &hcon->src);
l2cap_chan_unlock(chan);
l2cap_chan_add(conn, chan);
@@ -3798,8 +3789,8 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
*/
conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
- bacpy(&bt_sk(sk)->src, &conn->hcon->src);
- bacpy(&bt_sk(sk)->dst, &conn->hcon->dst);
+ bacpy(&chan->src, &conn->hcon->src);
+ bacpy(&chan->dst, &conn->hcon->dst);
chan->psm = psm;
chan->dcid = scid;
chan->local_amp_id = amp_id;
@@ -6542,17 +6533,15 @@ int l2cap_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr)
/* Find listening sockets and check their link_mode */
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
-
if (c->state != BT_LISTEN)
continue;
- if (!bacmp(&bt_sk(sk)->src, &hdev->bdaddr)) {
+ if (!bacmp(&c->src, &hdev->bdaddr)) {
lm1 |= HCI_LM_ACCEPT;
if (test_bit(FLAG_ROLE_SWITCH, &c->flags))
lm1 |= HCI_LM_MASTER;
exact++;
- } else if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY)) {
+ } else if (!bacmp(&c->src, BDADDR_ANY)) {
lm2 |= HCI_LM_ACCEPT;
if (test_bit(FLAG_ROLE_SWITCH, &c->flags))
lm2 |= HCI_LM_MASTER;
@@ -6840,10 +6829,8 @@ static int l2cap_debugfs_show(struct seq_file *f, void *p)
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
-
seq_printf(f, "%pMR %pMR %d %d 0x%4.4x 0x%4.4x %d %d %d %d\n",
- &bt_sk(sk)->src, &bt_sk(sk)->dst,
+ &c->src, &c->dst,
c->state, __le16_to_cpu(c->psm),
c->scid, c->dcid, c->imtu, c->omtu,
c->sec_level, c->mode);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index bd6fe7f..9fe80d2 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -112,7 +112,7 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
break;
}
- bacpy(&bt_sk(sk)->src, &la.l2_bdaddr);
+ bacpy(&chan->src, &la.l2_bdaddr);
chan->state = BT_BOUND;
sk->sk_state = BT_BOUND;
@@ -274,11 +274,11 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr,
if (peer) {
la->l2_psm = chan->psm;
- bacpy(&la->l2_bdaddr, &bt_sk(sk)->dst);
+ bacpy(&la->l2_bdaddr, &chan->dst);
la->l2_cid = cpu_to_le16(chan->dcid);
} else {
la->l2_psm = chan->sport;
- bacpy(&la->l2_bdaddr, &bt_sk(sk)->src);
+ bacpy(&la->l2_bdaddr, &chan->src);
la->l2_cid = cpu_to_le16(chan->scid);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Update source address and type for incoming LE connections
From: Johan Hedberg @ 2013-10-13 14:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381674318-6590-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> The incoming LE connections do not have a proper source address and
> address type set. The connection needs to be set with the same values
> as used for advertising parameters.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_event.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Update L2CAP socket source address from HCI connection
From: Johan Hedberg @ 2013-10-13 14:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381668997-1240-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Oct 13, 2013, Marcel Holtmann wrote:
> When having LE connections, the source address is not always the
> public address of the controller. So update the socket address
> based on the actual used source address of the HCI connection.
>
> This also remove the pointless source address pointer and adds
> a proper lock around the socket structure.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/l2cap_core.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox