From: Archie Pusaka
There is a possibility where HCI_INQUIRY flag is set but we still
send HCI_OP_INQUIRY anyway.
Such a case can be reproduced by connecting to an LE device while
active scanning. When the device is discovered, we initiate a
connection, stop LE Scan, and send Discovery MGMT
h/l2cap_core.c:598
> > l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756
> > l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429
> > process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064
> > worker_thread+0x5a5/0x773 kernel/workqueue.c:2196
> > kthread+
From: Archie Pusaka
There is a possibility of receiving a zapped sock on
l2cap_sock_connect(). This could lead to interesting crashes, one
such case is tearing down an already tore l2cap_sock as is happened
with this call trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118
From: Archie Pusaka
hci_chan can be created in 2 places: hci_loglink_complete_evt() if
it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory,
Only AMP hci_chan should be removed by a call to
hci_disconn_loglink_complete_evt(). However, the controller might mess
up, call that function
From: Archie Pusaka
Currently l2cap_chan_set_defaults() reset chan->conf_state to zero.
However, there is a flag CONF_NOT_COMPLETE which is set when
creating the l2cap_chan. It is suggested that the flag should be
cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults()
is cal
From: Archie Pusaka
There is a possibility of receiving a zapped sock on
l2cap_sock_connect(). This could lead to interesting crashes, one
such case is tearing down an already tore l2cap_sock as is happened
with this call trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
Reported-by: kernel test robot
Reported
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
From: Archie Pusaka
When MSFT extension is supported, we don't have to interleave the scan
as we could just do allowlist scan.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
---
Changes in v6:
* New patch "advmon offload MSFT interleave scanning integration"
net
From: Howard Chung
This adds logic to disable and reenable advertisement filters during
suspend and resume. After this patch, we would only receive packets from
devices in allow list during suspend.
Signed-off-by: Howard Chung
Reviewed-by: Abhishek Pandit-Subedi
---
Changes in v6:
* New
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
Hi maintainers,
Gentle ping to review this patch, thanks~!
Regards,
Archie
On Tue, 22 Dec 2020 at 18:26, Archie Pusaka wrote:
>
> From: Archie Pusaka
>
>
> Hi linux-bluetooth,
>
> This series of patches manages the hardware offloading part of MSFT
> extension API. Th
roller. This patch handles the re-registration
> >>> of those monitors when the power is on.
> >>>
> >>> Signed-off-by: Archie Pusaka
> >>> Reviewed-by: Miao-chen Chou
> >>> Reviewed-by: Yun-Hao C
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
Reported-by: kernel test robot
Reported
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
Reported-by: kernel test robot
Reported
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands
r is on.
> >
> > Signed-off-by: Archie Pusaka
> > Reviewed-by: Miao-chen Chou
> > Reviewed-by: Yun-Hao Chung
> >
> > ---
> >
> > (no changes since v1)
> >
> > net/bluetooth/msft.c | 79 +---
> >
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
Reported-by: kernel test robot
Reported
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands
Hi Dan,
On Wed, 16 Dec 2020 at 03:06, Dan Carpenter wrote:
>
> Hi Archie,
>
> url:
> https://github.com/0day-ci/linux/commits/Archie-Pusaka/MSFT-offloading-support-for-advertisement-monitor/20201215-163858
> base:
> https://git.kernel.org/pub/scm/linux/kernel/gi
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
(no changes since v1)
include/net
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands
Hi Marcel,
On Mon, 7 Dec 2020 at 17:57, Marcel Holtmann wrote:
>
> Hi Archie,
>
> >>>>> MSFT needs rssi parameter for monitoring advertisement packet,
> >>>>> therefore we should supply them from mgmt.
> >>>>>
> >&
Hi Marcel,
On Fri, 4 Dec 2020 at 17:51, Marcel Holtmann wrote:
>
> Hi Archie,
>
> >>> MSFT needs rssi parameter for monitoring advertisement packet,
> >>> therefore we should supply them from mgmt.
> >>>
> >>> Signed-off-by: Archie
Hi Marcel,
On Thu, 3 Dec 2020 at 22:03, Marcel Holtmann wrote:
>
> Hi Archie,
>
> > MSFT needs rssi parameter for monitoring advertisement packet,
> > therefore we should supply them from mgmt.
> >
> > Signed-off-by: Archie Pusaka
> > Reviewed-by: Miao-ch
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, whe
From: Archie Pusaka
Enables advertising monitor offloading to the controller, if MSFT
extension is supported. The kernel won't adjust the monitor parameters
to match what the controller supports - that is the user space's
responsibility.
This patch only manages the addition of monitors. Monitor
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
From: Archie Pusaka
Implements the monitor removal functionality for advertising monitor
offloading to MSFT controllers. Supply handle = 0 to remove all
monitors.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
include/net/bluetooth/hci_core.h | 8
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
include/net/bluetooth/hci_core.h | 9 +
include/net/bluetooth
From: Archie Pusaka
Hi linux-bluetooth,
This series of patches manages the hardware offloading part of MSFT
extension API. The full documentation can be accessed by this link:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events
From: Archie Pusaka
According to the spec Ver 5.2, Vol 3, Part C, Sec 5.2.2.8:
Device in security mode 4 level 4 shall enforce:
128-bit equivalent strength for link and encryption keys required
using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed,
and P-192 not allowed; encryption
>>>>>>>>> L2CAP: Connection Request (0x02) ident 3 len 4
> >>>>>>>>>PSM: 4097 (0x1001)
> >>>>>>>>>Source CID: 64
> >>>>>>>>> < ACL Data TX: Handle 256 flags 0x00 dlen 16
gt; Source CID: 64
> >>>>>>> < ACL Data TX: Handle 256 flags 0x00 dlen 16#43 [hci0]
> >>>>>>> 5.895213
> >>>>>>> L2CAP: Connection Response (0x03) ident 3 len 8
> >>>>>>> Destinatio
t;>>>> Result: Connection successful (0x0000)
> >>>>> Status: No further information available (0x)
> >>>>>
> >>>>> // WITH PATCH //
> >>>>>> ACL Data RX: Handle 256 flags 0x02 dlen 12
>>> Source CID: 64
> >>> Result: Connection successful (0x)
> >>> Status: No further information available (0x)
> >>>
> >>> // WITH PATCH //
> >>>> ACL Data RX: Handle 256 flags 0x02 dlen
#42 [hci0] 4.887024
> > L2CAP: Connection Request (0x02) ident 3 len 4
> >PSM: 4097 (0x1001)
> >Source CID: 64
> > < ACL Data TX: Handle 256 flags 0x00 dlen 16 #43 [hci0] 4.887127
> > L2CAP: Connection Resp
From: Archie Pusaka
When receiving an L2CAP_CONFIGURATION_REQ with an unknown config
type, currently we will reply with L2CAP_CONFIGURATION_RSP with
a list of unknown types as the config param. However, this is not
a correct format of config param.
As described in the bluetooth spec v5.2, Vol 3
Hi Luiz,
On Wed, 23 Sep 2020 at 01:03, Luiz Augusto von Dentz
wrote:
>
> Hi Archie,
>
> On Tue, Sep 22, 2020 at 12:48 AM Archie Pusaka wrote:
> >
> > Hi Luiz,
> >
> > On Tue, 22 Sep 2020 at 01:15, Luiz Augusto von Dentz
> > wrote:
> > >
>
From: Archie Pusaka
When receiving an L2CAP_CONFIGURATION_REQ with an unknown config
type, currently we will reply with L2CAP_CONFIGURATION_RSP with
a list of unknown types as the config param. However, this is not
a correct format of config param.
As described in the bluetooth spec v5.2, Vol 3
From: Archie Pusaka
When receiving connection, we only check whether the link has been
encrypted, but not the encryption key size of the link.
This patch adds check for encryption key size, and reject L2CAP
connection which size is below the specified threshold (default 7)
with security block
Hi Luiz,
On Tue, 22 Sep 2020 at 01:15, Luiz Augusto von Dentz
wrote:
>
> Hi Archie,
>
>
> On Mon, Sep 21, 2020 at 12:56 AM Archie Pusaka wrote:
> >
> > From: Archie Pusaka
> >
> > When receiving connection, we only check whether the link has been
> &g
Hi Luiz,
On Tue, 22 Sep 2020 at 01:13, Luiz Augusto von Dentz
wrote:
>
> Hi Archie,
>
> On Mon, Sep 21, 2020 at 1:31 AM Archie Pusaka wrote:
> >
> > From: Archie Pusaka
> >
> > According to the spec Ver 5.2, Vol 3, Part C, Sec 5.2.2.8:
> > Devic
From: Archie Pusaka
According to the spec Ver 5.2, Vol 3, Part C, Sec 5.2.2.8:
Device in security mode 4 level 4 shall enforce:
128-bit equivalent strength for link and encryption keys required
using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed,
and P-192 not allowed; encryption
From: Archie Pusaka
When receiving connection, we only check whether the link has been
encrypted, but not the encryption key size of the link.
This patch adds check for encryption key size, and reject L2CAP
connection which size is below the specified threshold (default 7)
with security block
From: Archie Pusaka
When receiving connection, we only check whether the link has been
encrypted, but not the encryption key size of the link.
This patch adds check for encryption key size, and reject L2CAP
connection which size is below the specified threshold (default 7)
with security block
ned
> > and discard the queued packet.
> >
> > Signed-off-by: Archie Pusaka
> > Reviewed-by: Abhishek Pandit-Subedi
>
> so two things up front. I want to hide this behind a
> HCI_QUIRK_OUT_OF_ORDER_ACL that a transport driver has to set first. Frankly
> if this
From: Archie Pusaka
It is possible to receive an L2CAP conn req for an encrypted
connection, before actually receiving the HCI change encryption
event. If this happened, the received L2CAP packet will be ignored.
This patch queues the L2CAP packet and process them after the
expected HCI event
From: Archie Pusaka
On platforms with USB transport, events and data are transferred via
different endpoints. This could potentially cause ordering problems,
where the order of processed information is different than the actual
order.
One such a case is we receive a ACL packet before receiving
From: Archie Pusaka
There is a possibility that an ACL packet is received before we
receive the HCI connect event for the corresponding handle. If this
happens, we discard the ACL packet.
Rather than just ignoring them, this patch provides a queue for
incoming ACL packet without a handle
70 matches
Mail list logo
