- 13 Oct, 2013 21 commits
-
-
Marcel Holtmann authored
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> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
The SMP source code has a few coding style violations. Fix them up all at once. No actual code has changed. Signed-off-by:
-
Marcel Holtmann authored
The smp_c1() so far always assumed public addresses as input for its operation. However it should provide actually the source address type of the actual connection. Finally the source address type is tracked in hci_conn->src_type and so use that one as input. Signed-off-by:
-
Marcel Holtmann authored
The source address is now stored in hci_conn->src and so use that one for L2CAP functions. Signed-off-by:
-
Marcel Holtmann authored
The source address is now stored in hci_conn->src and so use that one for SMP functions. Signed-off-by:
-
Marcel Holtmann authored
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 authored
The source addressed was based on the public address of the HCI device, but with LE connections this not always the case. For example single mode LE-only controllers would use a static random address. And this address is configured by userspace. To not complicate the lookup of what kind of address is in use, store the correct source address for each HCI connection. Signed-off-by:
-
Marcel Holtmann authored
When establishing LE connections, it is possible to use a public address (if available) or a random address. The type of address is only known when creating connections, so make sure it is stored in hci_conn structure. Signed-off-by:
-
Marcel Holtmann authored
The bdaddr_to_le() function tries to convert the internal address type to one that matches the HCI address type for LE. It does not handle any address types not used by LE and in the end just make the code a lot harder to read. So instead of just hiding behind a magic function, just convert the internal address type where it needs to be converted. And it turns out that these are only two cases anyway. One when creating new LE connections and the other when loading the long term keys. In both cases this makes it more clear on what it going on. Signed-off-by:
-
Marcel Holtmann authored
The l2cap_conn->src and l2cap_conn->dst pointers are no longer in use and so just remove them. Signed-off-by:
-
Marcel Holtmann authored
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointers to hci_conn structure. Use hci_conn->hdev->bdaddr and hci_conn->dst directly instead. Signed-off-by:
-
Marcel Holtmann authored
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointer to hci_conn->hdev->bdaddr and hci_conn->dst structures. Use the data provided by hci_conn directly. This is done for hci_conn->dst_type already anyway and with this change it makes it a lot clearer were the address information comes from. Signed-off-by:
-
Marcel Holtmann authored
The l2cap_conn->dst address is just a pointer into the hci_conn->dst structure. Use hci_conn->dst directly instead. Signed-off-by:
-
- 12 Oct, 2013 7 commits
-
-
Marcel Holtmann authored
The unicast connectionless data reception feature is actually support and has been supported all along. Mark it as supported in the L2CAP features bitmask. Signed-off-by:
-
Marcel Holtmann authored
The implementation actually supports the L2CAP connectionless data channel. So set it as supported in the fixed channels bitmask. Signed-off-by:
-
Marcel Holtmann authored
The PSM 0x0021 is dedicated to the 3D profile and has permission to use security mode 4 level 0 for L2CAP connectionless unicast data transfers. When establishing a L2CAP connectionless channel on PSM 0x0021, it will no longer force Secure Simple Pairing. Signed-off-by:
-
Marcel Holtmann authored
The exception for certain PSM channels when it comes to security mode 4 level 0 should only be checked when actually a connection oriented channel is established. Signed-off-by:
-
Marcel Holtmann authored
The put_unaligned() for setting the PSM is missing the (__le16 *) cast. Without this, the PSM information transmitted over the air are bogus. In addition, print the used PSM value in the debug message so this becomes easier to debug in the future. Signed-off-by:
-
Marcel Holtmann authored
The 1st generation of BlueFRITZ! devices from AVM Berlin pretend to be HCI version 1.2 controllers, but they are not. They are simple Bluetooth 1.1 devices. Since this company never created any newer controllers, it is safe to use the manufacturer ID instead of an USB quirk. < HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 > HCI Event: Command Complete (0x0e) plen 8 Read Page Scan Activity (0x03|0x001b) ncmd 1 Status: Success (0x00) Interval: 1280.000 msec (0x0800) Window: 21.250 msec (0x0022) < HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 > HCI Event: Command Status (0x0f) plen 4 Read Page Scan Type (0x03|0x0046) ncmd 1 Status: Unknown HCI Command (0x01) Signed-off-by: -
Marcel Holtmann authored
When adding support for MGMT_OP_SET_SCAN_PARAMS command the addition to the supported commands list has been forgotten. This is needed for userspace to detect if the command is supported or not. Signed-off-by:
-
- 11 Oct, 2013 12 commits
-
-
Marcel Holtmann authored
It is not allowed to enable high speed support when Secure Simple Pairing is not available or disabled. However the support for high speed gets advertised on a controller that does not even support Secure Simple Pairing. Since there is no way to enable high speed support on such a controller, do not even advertise its support. Signed-off-by:
-
Marcel Holtmann authored
Really early versions of the Bluetooth specification were unclear with the behavior of HCI Reset for USB devices. They assumed that also an USB reset needs to be issued. Later Bluetooth specifications cleared this out and it is safe to call HCI Reset without affecting the transport. For old devices that misbehave, the HCI_QUIRK_RESET_ON_CLOSE quirk was introduced to postpone the HCI Reset until the device was no longer in use. One of these devices is the Digianswer BPA-105 Bluetooth Protocol Analyzer. The only problem now is that with the quirk set, the HCI Reset is also executed at the end of the setup phase. So the controller gets configured and then it disconnects from the USB bus, connects again, gets configured and of course disconnects again. This game goes on forever. For devices that need HCI_QUIRK_RESET_ON_CLOSE it is important that the HCI Reset is not executed after the setup phase. In specific when HCI_AUTO_OFF is set, do not call HCI Reset when closing the device. Signed-off-by:
-
Marcel Holtmann authored
The scan interval and window parameters are used for LE passive background scanning and connection establishment. This allows userspace to change the values. These two values should be kept in sync with whatever is used for the scan parameters service on remote devices. And it puts the controlling daemon (for example bluetoothd) in charge of setting the values. Main use case would be to switch between two sets of values. One for foreground applications and one for background applications. At this moment, the values are only used for manual connection establishment, but soon that should be extended to background scanning and automatic connection establishment. Signed-off-by:
-
Marcel Holtmann authored
The scan interval and window for LE passive scanning and connection establishment should be configurable on a per controller basis. So introduce a setting that later on will allow modifying it. This setting does not affect LE active scanning during device discovery phase. As long as that phase uses interleaved discovery, it will continuously scan. Signed-off-by:
-
Marcel Holtmann authored
The ath3k_table[] and ath3k_blist_tbl[] USB device tables can be declared as const. Signed-off-by:
-
Marcel Holtmann authored
The bpa10x_table[] device table can be declared as const Signed-off-by:
-
Marcel Holtmann authored
The bfusb_table[] device table can be declared as const Signed-off-by:
-
Marcel Holtmann authored
The btusb_table[] and blacklist_table[] USB device tables can be declared as const. Signed-off-by:
-
Marcel Holtmann authored
The hdev parameter of vhci_send_frame() is always valid. If it were not valid, then it would have crashed earlier in the call chain. Signed-off-by:
-
Marcel Holtmann authored
The hdev parameter of hci_uart_send_frame() is always valid. If it were not valid, then it would have crashed earlier in the call chain. Signed-off-by:
-
Marcel Holtmann authored
The hdev parameter of dtl1_hci_send_frame() is always valid. If it were not valid, then it would have crashed earlier in the call chain. Signed-off-by:
-
Marcel Holtmann authored
The hdev parameter of btuart_hci_send_frame() is always valid. If it were not valid, then it would have crashed earlier in the call chain. Signed-off-by:
-
