Re: [PATCH] Bluetooth: rfcomm: Accept any XON/XOFF char

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Frédéric,

On Mon, Mar 31, 2025 at 9:15 AM Frédéric Danis
<frederic.danis@xxxxxxxxxxxxx> wrote:
>
> The latest version of PTS test RFCOMM/DEVA-DEVB/RFC/BV-17-C
> (RFCOMM v11.7.6.3) used unusual chars for XON (0x28 instead of
> 0x11) and XOFF (0xC8 instead of 0x13) and expect a reply with RPN
> parameters set for XON and XOFF.
>
> Current btmon traces:
> > ACL Data RX: Handle 11 flags 0x02 dlen 18
>       Channel: 64 len 14 [PSM 3 mode Basic (0x00)] {chan 0}
>       RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
>          Address: 0x03 cr 1 dlci 0x00
>          Control: 0xef poll/final 0
>          Length: 10
>          FCS: 0x70
>          MCC Message type: Remote Port Negotiation Command CMD (0x24)
>            Length: 8
>            dlci 32
>            br 3 db 3 sb 0 p 0 pt 0 xi 0 xo 0
>            rtri 0 rtro 0 rtci 0 rtco 0 xon 40 xoff 200
>            pm 0xff7f
> < ACL Data TX: Handle 11 flags 0x00 dlen 18
>       Channel: 64 len 14 [PSM 3 mode Basic (0x00)] {chan 0}
>       RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
>          Address: 0x01 cr 0 dlci 0x00
>          Control: 0xef poll/final 0
>          Length: 10
>          FCS: 0xaa
>          MCC Message type: Remote Port Negotiation Command RSP (0x24)
>            Length: 8
>            dlci 32
>            br 3 db 3 sb 0 p 0 pt 0 xi 0 xo 0
>            rtri 0 rtro 0 rtci 0 rtco 0 xon 17 xoff 19
>            pm 0x3f1f
>
> Signed-off-by: Frédéric Danis <frederic.danis@xxxxxxxxxxxxx>
> ---
>  net/bluetooth/rfcomm/core.c | 20 ++++++--------------
>  1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index ad5177e3a69b..0c0525939aa0 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1562,23 +1562,15 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
>                 }
>         }
>
> -       if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XON)) {
> +       if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XON))
>                 xon_char = rpn->xon_char;
> -               if (xon_char != RFCOMM_RPN_XON_CHAR) {
> -                       BT_DBG("RPN XON char mismatch 0x%x", xon_char);
> -                       xon_char = RFCOMM_RPN_XON_CHAR;
> -                       rpn_mask ^= RFCOMM_RPN_PM_XON;
> -               }
> -       }

So is the assumption that we don't need to check the actual character
sent part of the spec? If it is then it is probably worth quoting it,
otherwise I'd update the check to include both old and new chars.

> +       else
> +               rpn_mask ^= RFCOMM_RPN_PM_XON;
>
> -       if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XOFF)) {
> +       if (rpn->param_mask & cpu_to_le16(RFCOMM_RPN_PM_XOFF))
>                 xoff_char = rpn->xoff_char;
> -               if (xoff_char != RFCOMM_RPN_XOFF_CHAR) {
> -                       BT_DBG("RPN XOFF char mismatch 0x%x", xoff_char);
> -                       xoff_char = RFCOMM_RPN_XOFF_CHAR;
> -                       rpn_mask ^= RFCOMM_RPN_PM_XOFF;
> -               }
> -       }
> +       else
> +               rpn_mask ^= RFCOMM_RPN_PM_XOFF;
>
>  rpn_out:
>         rfcomm_send_rpn(s, 0, dlci, bit_rate, data_bits, stop_bits,
> --
> 2.43.0
>
>


-- 
Luiz Augusto von Dentz





[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux