none
Bluetooth - Windows 10 revision 1803 - SPP QOS regression RRS feed

  • Question

  • Hello all,

    -------------------------------------------------------------------------
    Windows 10 revision 1803 bluetooth SPP QOS regression
    -------------------------------------------------------------------------

    Windows 10 revision 1803 has a newly introduced regression.
    This is in regard to the L2CAP negotiation which is use to bring up e.g. the RFCOMM protocol.

    1) When the L2CAP connection for PSM=3 is made, Windows proposes an MTU which can be used.
       It uses the "L2CAP configure" PDU for this. This OK.

    2) If the responder responds with options for QOS (as described in Core Spec 5.0, Vol A, Part A, Section 5.3),
       the Windows implementation end up with an "L2CAP REJECT" and the connection is unsuccessful.
       This was accepted by all previous versions of Windows 7/8/10.

    To illustrate the problem the following traces document the behavior (they can be viewed with the Frontline trace viewer):

    a) win10_1607_configure_qos_ok.cfa - this illustrates that version 1607 _does_ work if the QOS options are used.

    b) win10_1803_configure_qos_failure.cfa - this illustrates that version 1803 does _not_ work if if the QOS options are used.

    c) win10_1803_configure_no_qos_ok.cfa - this illustrates that version 1803 _does_ work if the QOS options are not used.

    This looks like a regression in version 1803 of Windows 10.

    Has anyone noticed this, and if so, have they found a work-around? Any device in the wild that tries to negotiate QOS is more or less bricked if using version 1803 (spring update).

    Traces are here: https://www.dropbox.com/s/6wqnhaty3n55n8w/win10_spp_failure.zip?dl=0

    Thanks,

    /pedro

    Monday, May 21, 2018 3:37 PM

Answers

  • Hi Soren and Pedro,

    The change is making its way up and should be available publicly soon through the Insider program.  We were able to get a hold of hardware that exhibited this issue and were able to confirm that the issue described in this thread has been addressed.

    The fix will be included in Insider Preview Build 17698 or later (depending on which build is made available).


    This posting is provided AS IS with no warranties, and confers no rights.

    • Marked as answer by donpedro2 Wednesday, June 20, 2018 8:35 PM
    Wednesday, June 20, 2018 4:50 AM
  • Hi Pedro,

    Thanks for bringing this to our attention.  There were some changes around how we validate our L2cap configuration parameters, but it looks like we are now also rejecting the parameters sent you us by your device in the config response.  Our Rfcomm profile implementation does not implement QOS, and it is by design that it rejects QOS configuration parameters, but for this specific case, it looks like we can relax this back as the device is only replying with the default link parameters.

    Regarding work arounds, this will only occur if a device replies with QOS parameters to a profile that does not support QOS, like Rfcomm.  Your specific device is only replying with the default parameters that are assumed by the link, so the work around, if you have access to the device code, would be to not reply with these parameters for the time being.

    I'll let you know when we have a fix in the Insider builds.


    This posting is provided AS IS with no warranties, and confers no rights.

    Tuesday, May 22, 2018 12:26 AM

All replies

  • Hi Pedro,

    Thanks for bringing this to our attention.  There were some changes around how we validate our L2cap configuration parameters, but it looks like we are now also rejecting the parameters sent you us by your device in the config response.  Our Rfcomm profile implementation does not implement QOS, and it is by design that it rejects QOS configuration parameters, but for this specific case, it looks like we can relax this back as the device is only replying with the default link parameters.

    Regarding work arounds, this will only occur if a device replies with QOS parameters to a profile that does not support QOS, like Rfcomm.  Your specific device is only replying with the default parameters that are assumed by the link, so the work around, if you have access to the device code, would be to not reply with these parameters for the time being.

    I'll let you know when we have a fix in the Insider builds.


    This posting is provided AS IS with no warranties, and confers no rights.

    Tuesday, May 22, 2018 12:26 AM
  • Hi Matthew,

    Thanks for looking into this.

    I am not sure what you mean when you state that your RFCOMM implementation does not implement QOS.

    It is true that QOS is optional in the SPP v1.2 spec:

    5.3.3 Quality of Service

    Negotiation of Quality of Service is optional in this profile.

    However, no matter if you choose to implement QOS for a given L2CAP channel or not, you must always reply properly for certain options.

    As it states in the core spec.

    L2CAP implementations are only required to support ’Best Effort’ service,

    support for any other service type is optional

    So _all_ variants of "best effort" must be supported. The other fields can be discarded in this case.

    Just wanted to make sure all cases would work if you are spinning an update for this :-).

    Thanks,

    /pedro

    Tuesday, May 22, 2018 10:45 AM
  • Best Effort is not QOS (it explicitly is the opposite) and is the default channel behavior when no parameters are configured to enable QOS.  I did not mean to imply that we do not support the QOS option in our L2cap implementation, but rather that our Rfcomm channel only supports Best Effort and will reject any attempts to enable QOS on the channel. 

    Regardless, neither side is requesting to enable QOS on the channel in this trace.  The only QOS parameters being sent here are in a Config Response sent from the remote device in reply to the Windows Config Request which did not request to enable QOS.  As I said in my first response, the device is replying with the default parameters (i.e. no QOS, Best Effort), which is what the link is already configured to use. 

    Note though that this behavior conflicts with the specification, as the response is not adjusting any of the already negotiated parameters:

    "Each configuration parameter value (if any is present) in a Configuration Response reflects an adjustment to a configuration parameter value that has been sent (or, in case of default values, implied) in the corresponding Configuration Request.”

     

    I would have expected the device to simply acknowledge the Config Response, rather than sending the channel defaults back, though doing so is harmless in the end.  Unfortunately, our channel is rejecting the config response as it is interpreting the QOS field in the response as an attempt to adjust the parameters from the defaults.  Relaxing this check to ignore redundant parameters that resolve back to the default channel parameters is definitely good to have and will bring us back in line with the previous release behavior.

     

    I will let you know once it’s in the Insider builds, and you can give it a try if you’re still blocked.  However, as I suggested in my previous response, if you need a work around, simply not replying with the default link parameters, which is redundant, will allow everything to continue working as it did before with identical channel parameters


    This posting is provided AS IS with no warranties, and confers no rights.



    Wednesday, May 23, 2018 2:12 AM
  • Hi Matthew,

    Thanks for the update.

    >> Best Effort is not QOS (it explicitly is the opposite)

    Exactly. Just wanted to make sure you still supported all the "non QOS" options in the QOS options. Contradictive (as you mentioned), but important for backwards compatibility.

    >> adjustment to a configuration parameter

    Yes, only adjustments should be sent. However this is an ancient device deployed over a decade ago (unfortunately in the tens-of-thousands). We are making sure new devices do not echo worthless information. I would note however, that many devices do this. Many devices e.g. echo the MTU even though they do not change it. Worthless, but as you point you point out, harmless.

    Thanks,

    /pedro

    Wednesday, May 23, 2018 11:00 AM
  • The MTU is a special case in the spec, as it is a non-negotiable parameter and also has its own backwards compatibility section, so it is auto accepted (assuming it's a valid value).

    Sounds like you cant work around it, so I'll let you know once it's available on the Insider builds for you to try out.


    This posting is provided AS IS with no warranties, and confers no rights.

    Wednesday, May 23, 2018 6:26 PM
  • Hi Matthew,

    Again, thanks for looking into this. Great dev. support!

    How is the build coming along? The number of affected users is rising by the day.

    Thanks,

    /pedro

    Friday, June 1, 2018 6:09 PM
  • Hi Matthew,

    Any ETA of this (approx) ?

    Affected user count is rising.

    Thanks,

    /pedro

    Wednesday, June 6, 2018 10:59 AM
  • I tested this with Windows 10 Insider preview Build 17686. The issue is still there. BT Pairing fails due to QOS parameter rejected.

    /Søren

    Tuesday, June 12, 2018 11:22 AM
  • Hi Soren and Pedro,

    The change is making its way up and should be available publicly soon through the Insider program.  We were able to get a hold of hardware that exhibited this issue and were able to confirm that the issue described in this thread has been addressed.

    The fix will be included in Insider Preview Build 17698 or later (depending on which build is made available).


    This posting is provided AS IS with no warranties, and confers no rights.

    • Marked as answer by donpedro2 Wednesday, June 20, 2018 8:35 PM
    Wednesday, June 20, 2018 4:50 AM
  • Hi Matthew,

    Excellent. I know allot of people who are going to be happy.

    Nice work & thanks for the assistance. Very professional.

    /pedro

    Wednesday, June 20, 2018 8:34 PM