Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
On Tue, Apr 23, 2019 at 1:08 PM Marcel Holtmann wrote:
>
> Hi Andrey,
>
> > Due to:
> >
> > - current implementation of l2cap_config_rsp() dropping BT
> > connection if sender of configuration response replied with unknown
> > option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
> >
> > - current implementation of l2cap_build_conf_req() adding
> > L2CAP_CONF_RFC(0x04) option to initial configure request sent by
> > the Linux host.
> >
> > devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S
> > controllers, will get stuck in endless connect -> configure ->
> > disconnect loop, never connect and be generaly unusable.
> >
> > To avoid this problem add code to do the following:
> >
> > 1. Store a mask of supported conf option types per connection
> >
> > 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust
> >connection's supported conf option types mask
> >
> > 3. Retry configuration step the same way it's done for
> >L2CAP_CONF_UNACCEPT
> >
> > Signed-off-by: Andrey Smirnov
> > Cc: Pierre-Loup A. Griffais
> > Cc: Florian Dollinger
> > Cc: Marcel Holtmann
> > Cc: Johan Hedberg
> > Cc: linux-blueto...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >
> > Everyone:
> >
> > I marked this as an RFC, since I don't have a lot of experience with
> > Bluetooth subsystem and don't have hight degree of confidence about
> > choices made in this patch. I do, however, thins is is good enough to
> > start a discussion about the problem.
> >
> > Thanks,
> > Andrey Smirnov
>
> so it seems that the remote side claims to support Streaming Mode and that is
> why we are trying to set it up.
>
> > ACL Data RX: Handle 12 flags 0x02 dlen 16
> L2CAP: Information Response (0x0b) ident 1 len 8
> Type: Extended features supported (0x0002)
> Result: Success (0x)
> Features: 0x0010
> Streaming Mode
>
> And that is why we do this.
>
> < ACL Data TX: Handle 12 flags 0x00 dlen 23
> L2CAP: Configure Request (0x04) ident 2 len 15
> Destination CID: 64
> Flags: 0x
> Option: Retransmission and Flow Control (0x04) [mandatory]
> Mode: Basic (0x00)
> TX window size: 0
> Max transmit: 0
> Retransmission timeout: 0
> Monitor timeout: 0
> Maximum PDU size: 0
>
> > ACL Data RX: Handle 12 flags 0x02 dlen 15
> L2CAP: Configure Response (0x05) ident 2 len 7
> Source CID: 64
> Flags: 0x
> Result: Failure - unknown options (0x0003)
> 04
>
> So btmon needs a patch to decide the failed option octet here. We really want
> do provide a human description of the failed option.
>
I'll see if that's an easy thing to add. Can't promise anything though.
> >
> > include/net/bluetooth/l2cap.h | 1 +
> > net/bluetooth/l2cap_core.c| 58 ++-
> > 2 files changed, 51 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> > index 093aedebdf0c..6898bba5d9a8 100644
> > --- a/include/net/bluetooth/l2cap.h
> > +++ b/include/net/bluetooth/l2cap.h
> > @@ -632,6 +632,7 @@ struct l2cap_conn {
> > unsigned intmtu;
> >
> > __u32 feat_mask;
> > + __u32 known_options;
> > __u8remote_fixed_chan;
> > __u8local_fixed_chan;
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index f17e393b43b4..49be98b6de72 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -3243,8 +3243,10 @@ static int l2cap_build_conf_req(struct l2cap_chan
> > *chan, void *data, size_t data
> > rfc.monitor_timeout = 0;
> > rfc.max_pdu_size= 0;
> >
> > - l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> > -(unsigned long) , endptr - ptr);
> > + if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
> > + l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> > +(unsigned long), endptr - ptr);
> > + }
> > break;
> >
> > case L2CAP_MODE_ERTM:
> > @@ -3263,8 +3265,10 @@ static int l2cap_build_conf_req(struct l2cap_chan
> > *chan, void *data, size_t data
> > rfc.txwin_size = min_t(u16, chan->tx_win,
> > L2CAP_DEFAULT_TX_WINDOW);
> >
> > - l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> > -(unsigned long) , endptr - ptr);
> > + if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
> > + l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> > +(unsigned long), endptr - ptr);
> > + }
> >
> > if (test_bit(FLAG_EFS_ENABLE, >flags))
> >
Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
Hi Andrey,
> Due to:
>
> - current implementation of l2cap_config_rsp() dropping BT
> connection if sender of configuration response replied with unknown
> option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
>
> - current implementation of l2cap_build_conf_req() adding
> L2CAP_CONF_RFC(0x04) option to initial configure request sent by
> the Linux host.
>
> devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S
> controllers, will get stuck in endless connect -> configure ->
> disconnect loop, never connect and be generaly unusable.
>
> To avoid this problem add code to do the following:
>
> 1. Store a mask of supported conf option types per connection
>
> 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust
>connection's supported conf option types mask
>
> 3. Retry configuration step the same way it's done for
>L2CAP_CONF_UNACCEPT
>
> Signed-off-by: Andrey Smirnov
> Cc: Pierre-Loup A. Griffais
> Cc: Florian Dollinger
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Everyone:
>
> I marked this as an RFC, since I don't have a lot of experience with
> Bluetooth subsystem and don't have hight degree of confidence about
> choices made in this patch. I do, however, thins is is good enough to
> start a discussion about the problem.
>
> Thanks,
> Andrey Smirnov
so it seems that the remote side claims to support Streaming Mode and that is
why we are trying to set it up.
> ACL Data RX: Handle 12 flags 0x02 dlen 16
L2CAP: Information Response (0x0b) ident 1 len 8
Type: Extended features supported (0x0002)
Result: Success (0x)
Features: 0x0010
Streaming Mode
And that is why we do this.
< ACL Data TX: Handle 12 flags 0x00 dlen 23
L2CAP: Configure Request (0x04) ident 2 len 15
Destination CID: 64
Flags: 0x
Option: Retransmission and Flow Control (0x04) [mandatory]
Mode: Basic (0x00)
TX window size: 0
Max transmit: 0
Retransmission timeout: 0
Monitor timeout: 0
Maximum PDU size: 0
> ACL Data RX: Handle 12 flags 0x02 dlen 15
L2CAP: Configure Response (0x05) ident 2 len 7
Source CID: 64
Flags: 0x
Result: Failure - unknown options (0x0003)
04
So btmon needs a patch to decide the failed option octet here. We really want
do provide a human description of the failed option.
>
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/l2cap_core.c| 58 ++-
> 2 files changed, 51 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 093aedebdf0c..6898bba5d9a8 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -632,6 +632,7 @@ struct l2cap_conn {
> unsigned intmtu;
>
> __u32 feat_mask;
> + __u32 known_options;
> __u8remote_fixed_chan;
> __u8local_fixed_chan;
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index f17e393b43b4..49be98b6de72 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3243,8 +3243,10 @@ static int l2cap_build_conf_req(struct l2cap_chan
> *chan, void *data, size_t data
> rfc.monitor_timeout = 0;
> rfc.max_pdu_size= 0;
>
> - l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> -(unsigned long) , endptr - ptr);
> + if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
> + l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> +(unsigned long), endptr - ptr);
> + }
> break;
>
> case L2CAP_MODE_ERTM:
> @@ -3263,8 +3265,10 @@ static int l2cap_build_conf_req(struct l2cap_chan
> *chan, void *data, size_t data
> rfc.txwin_size = min_t(u16, chan->tx_win,
> L2CAP_DEFAULT_TX_WINDOW);
>
> - l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> -(unsigned long) , endptr - ptr);
> + if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
> + l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> +(unsigned long), endptr - ptr);
> + }
>
> if (test_bit(FLAG_EFS_ENABLE, >flags))
> l2cap_add_opt_efs(, chan, endptr - ptr);
> @@ -3295,8 +3299,10 @@ static int l2cap_build_conf_req(struct l2cap_chan
> *chan, void *data, size_t data
>L2CAP_FCS_SIZE);
> rfc.max_pdu_size = cpu_to_le16(size);
>
> - l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
> -
Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
I think in essence this is the same as my patch from Jan 2018 here: https://raw.githubusercontent.com/atar-axis/xpadneo/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch Right? That's maybe why I am in CC :D If yes, then I can fully confirm that this works as one would expect. Let me copy my patch description here: --- The current L2CAP implementation does not change any options if the other side respons with "unknown options", but does if "unaccepted options" is the answer. It is up to the implementation to decide on the effort spent on config negotiations, therefore the current implementation is correct at this point - but [...] devices like [the] Xbox One S controller [is] not useable this way. A workaround for many users therefore is to disable_ertm, since this is [in this case] the option which is unknown. I would prefer to try it again with altered options instead of globally disable ERTM. In result, I suggest the following patch. It simply adds a new case (L2CAP_CONF_UNKNOWN), which does nothing but falling through to L2CAP_CONF_UNACCEPT. --- Cheers, Florian Dollinger (atar-axis) On 21.03.19 00:08, Andrey Smirnov wrote: On Mon, Feb 18, 2019 at 8:57 PM Andrey Smirnov wrote: On Mon, Feb 18, 2019 at 4:58 AM Marcel Holtmann wrote: Hi Andrey, Due to: - current implementation of l2cap_config_rsp() dropping BT connection if sender of configuration response replied with unknown option failure (Result=0x0003/L2CAP_CONF_UNKNOWN) - current implementation of l2cap_build_conf_req() adding L2CAP_CONF_RFC(0x04) option to initial configure request sent by the Linux host. devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S controllers, will get stuck in endless connect -> configure -> disconnect loop, never connect and be generaly unusable. To avoid this problem add code to do the following: 1. Store a mask of supported conf option types per connection 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust connection's supported conf option types mask 3. Retry configuration step the same way it's done for L2CAP_CONF_UNACCEPT Signed-off-by: Andrey Smirnov Cc: Pierre-Loup A. Griffais Cc: Florian Dollinger Cc: Marcel Holtmann Cc: Johan Hedberg Cc: linux-blueto...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Everyone: I marked this as an RFC, since I don't have a lot of experience with Bluetooth subsystem and don't have hight degree of confidence about choices made in this patch. I do, however, thins is is good enough to start a discussion about the problem. can you take a btmon -w trace.log protocol trace so that I can see where it fails. This seems a really odd behavior of the Xbox controller. We have to be careful in not breaking Bluetooth qualification to just workaround some buggy remote device. Sure, n/p, both "failure" (behavior before this patch) and "success" (behavior with the patch) cases on my machine are available here: https://gist.github.com/ndreys/2b74094933601978e200af1ff0a55372 Let me know if that's not accessible to you. Marcel, did you have a chance to look at the logs? Thanks, Andrey Smirnov
Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
On Mon, Feb 18, 2019 at 8:57 PM Andrey Smirnov wrote: > > On Mon, Feb 18, 2019 at 4:58 AM Marcel Holtmann wrote: > > > > Hi Andrey, > > > > > Due to: > > > > > > - current implementation of l2cap_config_rsp() dropping BT > > > connection if sender of configuration response replied with unknown > > > option failure (Result=0x0003/L2CAP_CONF_UNKNOWN) > > > > > > - current implementation of l2cap_build_conf_req() adding > > > L2CAP_CONF_RFC(0x04) option to initial configure request sent by > > > the Linux host. > > > > > > devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S > > > controllers, will get stuck in endless connect -> configure -> > > > disconnect loop, never connect and be generaly unusable. > > > > > > To avoid this problem add code to do the following: > > > > > > 1. Store a mask of supported conf option types per connection > > > > > > 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust > > >connection's supported conf option types mask > > > > > > 3. Retry configuration step the same way it's done for > > >L2CAP_CONF_UNACCEPT > > > > > > Signed-off-by: Andrey Smirnov > > > Cc: Pierre-Loup A. Griffais > > > Cc: Florian Dollinger > > > Cc: Marcel Holtmann > > > Cc: Johan Hedberg > > > Cc: linux-blueto...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > --- > > > > > > Everyone: > > > > > > I marked this as an RFC, since I don't have a lot of experience with > > > Bluetooth subsystem and don't have hight degree of confidence about > > > choices made in this patch. I do, however, thins is is good enough to > > > start a discussion about the problem. > > > > can you take a btmon -w trace.log protocol trace so that I can see where it > > fails. This seems a really odd behavior of the Xbox controller. We have to > > be careful in not breaking Bluetooth qualification to just workaround some > > buggy remote device. > > > > Sure, n/p, both "failure" (behavior before this patch) and "success" > (behavior with the patch) cases on my machine are available here: > > https://gist.github.com/ndreys/2b74094933601978e200af1ff0a55372 > > Let me know if that's not accessible to you. > Marcel, did you have a chance to look at the logs? Thanks, Andrey Smirnov
Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
On Mon, Feb 18, 2019 at 4:58 AM Marcel Holtmann wrote: > > Hi Andrey, > > > Due to: > > > > - current implementation of l2cap_config_rsp() dropping BT > > connection if sender of configuration response replied with unknown > > option failure (Result=0x0003/L2CAP_CONF_UNKNOWN) > > > > - current implementation of l2cap_build_conf_req() adding > > L2CAP_CONF_RFC(0x04) option to initial configure request sent by > > the Linux host. > > > > devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S > > controllers, will get stuck in endless connect -> configure -> > > disconnect loop, never connect and be generaly unusable. > > > > To avoid this problem add code to do the following: > > > > 1. Store a mask of supported conf option types per connection > > > > 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust > >connection's supported conf option types mask > > > > 3. Retry configuration step the same way it's done for > >L2CAP_CONF_UNACCEPT > > > > Signed-off-by: Andrey Smirnov > > Cc: Pierre-Loup A. Griffais > > Cc: Florian Dollinger > > Cc: Marcel Holtmann > > Cc: Johan Hedberg > > Cc: linux-blueto...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > --- > > > > Everyone: > > > > I marked this as an RFC, since I don't have a lot of experience with > > Bluetooth subsystem and don't have hight degree of confidence about > > choices made in this patch. I do, however, thins is is good enough to > > start a discussion about the problem. > > can you take a btmon -w trace.log protocol trace so that I can see where it > fails. This seems a really odd behavior of the Xbox controller. We have to be > careful in not breaking Bluetooth qualification to just workaround some buggy > remote device. > Sure, n/p, both "failure" (behavior before this patch) and "success" (behavior with the patch) cases on my machine are available here: https://gist.github.com/ndreys/2b74094933601978e200af1ff0a55372 Let me know if that's not accessible to you. Thanks, Andrey Smirnov
Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
Hi Andrey, > Due to: > > - current implementation of l2cap_config_rsp() dropping BT > connection if sender of configuration response replied with unknown > option failure (Result=0x0003/L2CAP_CONF_UNKNOWN) > > - current implementation of l2cap_build_conf_req() adding > L2CAP_CONF_RFC(0x04) option to initial configure request sent by > the Linux host. > > devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S > controllers, will get stuck in endless connect -> configure -> > disconnect loop, never connect and be generaly unusable. > > To avoid this problem add code to do the following: > > 1. Store a mask of supported conf option types per connection > > 2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust >connection's supported conf option types mask > > 3. Retry configuration step the same way it's done for >L2CAP_CONF_UNACCEPT > > Signed-off-by: Andrey Smirnov > Cc: Pierre-Loup A. Griffais > Cc: Florian Dollinger > Cc: Marcel Holtmann > Cc: Johan Hedberg > Cc: linux-blueto...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > > Everyone: > > I marked this as an RFC, since I don't have a lot of experience with > Bluetooth subsystem and don't have hight degree of confidence about > choices made in this patch. I do, however, thins is is good enough to > start a discussion about the problem. can you take a btmon -w trace.log protocol trace so that I can see where it fails. This seems a really odd behavior of the Xbox controller. We have to be careful in not breaking Bluetooth qualification to just workaround some buggy remote device. Regards Marcel
[RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN
Due to:
- current implementation of l2cap_config_rsp() dropping BT
connection if sender of configuration response replied with unknown
option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
- current implementation of l2cap_build_conf_req() adding
L2CAP_CONF_RFC(0x04) option to initial configure request sent by
the Linux host.
devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S
controllers, will get stuck in endless connect -> configure ->
disconnect loop, never connect and be generaly unusable.
To avoid this problem add code to do the following:
1. Store a mask of supported conf option types per connection
2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust
connection's supported conf option types mask
3. Retry configuration step the same way it's done for
L2CAP_CONF_UNACCEPT
Signed-off-by: Andrey Smirnov
Cc: Pierre-Loup A. Griffais
Cc: Florian Dollinger
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc: linux-blueto...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Everyone:
I marked this as an RFC, since I don't have a lot of experience with
Bluetooth subsystem and don't have hight degree of confidence about
choices made in this patch. I do, however, thins is is good enough to
start a discussion about the problem.
Thanks,
Andrey Smirnov
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap_core.c| 58 ++-
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 093aedebdf0c..6898bba5d9a8 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -632,6 +632,7 @@ struct l2cap_conn {
unsigned intmtu;
__u32 feat_mask;
+ __u32 known_options;
__u8remote_fixed_chan;
__u8local_fixed_chan;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index f17e393b43b4..49be98b6de72 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3243,8 +3243,10 @@ static int l2cap_build_conf_req(struct l2cap_chan *chan,
void *data, size_t data
rfc.monitor_timeout = 0;
rfc.max_pdu_size= 0;
- l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) , endptr - ptr);
+ if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
+ l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long), endptr - ptr);
+ }
break;
case L2CAP_MODE_ERTM:
@@ -3263,8 +3265,10 @@ static int l2cap_build_conf_req(struct l2cap_chan *chan,
void *data, size_t data
rfc.txwin_size = min_t(u16, chan->tx_win,
L2CAP_DEFAULT_TX_WINDOW);
- l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) , endptr - ptr);
+ if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
+ l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long), endptr - ptr);
+ }
if (test_bit(FLAG_EFS_ENABLE, >flags))
l2cap_add_opt_efs(, chan, endptr - ptr);
@@ -3295,8 +3299,10 @@ static int l2cap_build_conf_req(struct l2cap_chan *chan,
void *data, size_t data
L2CAP_FCS_SIZE);
rfc.max_pdu_size = cpu_to_le16(size);
- l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) , endptr - ptr);
+ if (chan->conn->known_options & BIT(L2CAP_CONF_RFC)) {
+ l2cap_add_conf_opt(, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long), endptr - ptr);
+ }
if (test_bit(FLAG_EFS_ENABLE, >flags))
l2cap_add_opt_efs(, chan, endptr - ptr);
@@ -3550,11 +3556,47 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan
*chan, void *rsp, int len,
void *endptr = data + size;
int type, olen;
unsigned long val;
+ const bool unknown_options = *result == L2CAP_CONF_UNKNOWN;
struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
struct l2cap_conf_efs efs;
BT_DBG("chan %p, rsp %p, len %d, req %p", chan, rsp, len, data);
+ /* throw out any old stored conf requests */
+ *result = L2CAP_CONF_SUCCESS;
+
+ if (unknown_options) {
+ const u8 *option_type = rsp;
+
+ if (!len) {
+ /* If no list of unknown option types is
+* provided there's nothing for us to do
+*/
+ return -ECONNREFUSED;
+
