Bluetooth: rfcomm: fix modem control handling
Subsystems (3)
PATCH v2 1/1 Bluetooth: rfcomm: fix modem control handling
The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS).
This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS.
Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003.
---
Changes in v2
- fix a compilation issue discovered before sending v1 but never folded into the actual patch...
net/bluetooth/rfcomm/tty.c | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-)
net/bluetooth/rfcomm/tty.c +11 -15
@@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig)tty_port_tty_hangup (&dev->port, true); dev->modem_status = - ((v24_sig &RFCOMM_V24_RTC ) ? (TIOCM_DSR |TIOCM_DTR ) :0 ) | - ((v24_sig &RFCOMM_V24_RTR ) ? (TIOCM_RTS |TIOCM_CTS ) :0 ) | + ((v24_sig &RFCOMM_V24_RTC ) ?TIOCM_DSR :0 ) | + ((v24_sig &RFCOMM_V24_RTR ) ?TIOCM_CTS :0 ) | ((v24_sig &RFCOMM_V24_IC ) ?TIOCM_RI :0 ) | ((v24_sig &RFCOMM_V24_DV ) ?TIOCM_CD :0 ); }
@@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty)static int rfcomm_tty_tiocmget (struct tty_struct *tty) {struct rfcomm_dev *dev = tty->driver_data; +struct rfcomm_dlc *dlc = dev->dlc; +u8 v24_sig;BT_DBG ("tty %p dev %p" , tty, dev); -return dev->modem_status; +rfcomm_dlc_get_modem_status (dlc, &v24_sig); + +return (v24_sig & (TIOCM_DTR |TIOCM_RTS )) | dev->modem_status; }static int rfcomm_tty_tiocmset (struct tty_struct *tty,unsigned int set,unsigned int clear)
@@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsignerfcomm_dlc_get_modem_status (dlc, &v24_sig); -if (set &TIOCM_DSR || set &TIOCM_DTR ) +if (set &TIOCM_DTR ) v24_sig |=RFCOMM_V24_RTC ; -if (set &TIOCM_RTS || set &TIOCM_CTS ) +if (set &TIOCM_RTS ) v24_sig |=RFCOMM_V24_RTR ; -if (set &TIOCM_RI ) - v24_sig |=RFCOMM_V24_IC ; -if (set &TIOCM_CD ) - v24_sig |=RFCOMM_V24_DV ; -if (clear &TIOCM_DSR || clear &TIOCM_DTR ) +if (clear &TIOCM_DTR ) v24_sig &= ~RFCOMM_V24_RTC ; -if (clear &TIOCM_RTS || clear &TIOCM_CTS ) +if (clear &TIOCM_RTS ) v24_sig &= ~RFCOMM_V24_RTR ; -if (clear &TIOCM_RI ) - v24_sig &= ~RFCOMM_V24_IC ; -if (clear &TIOCM_CD ) - v24_sig &= ~RFCOMM_V24_DV ;rfcomm_dlc_set_modem_status (dlc, v24_sig);
Signature · 1 line
2.49.1
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1014980
---Test result---
Test Summary:
CheckPatch PENDING 0.56 seconds GitLint PENDING 0.34 seconds SubjectPrefix PASS 0.07 seconds BuildKernel PASS 26.60 seconds CheckAllWarning PASS 27.39 seconds CheckSparse PASS 30.70 seconds BuildKernel32 PASS 24.50 seconds TestRunnerSetup PASS 489.96 seconds TestRunner_l2cap-tester PASS 24.18 seconds TestRunner_iso-tester PASS 102.68 seconds TestRunner_bnep-tester PASS 6.05 seconds TestRunner_mgmt-tester FAIL 117.24 seconds TestRunner_rfcomm-tester PASS 9.33 seconds TestRunner_sco-tester PASS 14.40 seconds TestRunner_ioctl-tester PASS 11.28 seconds TestRunner_mesh-tester FAIL 11.43 seconds TestRunner_smp-tester PASS 8.48 seconds TestRunner_userchan-tester PASS 6.38 seconds IncrementalBuild PENDING 0.60 seconds
Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script Output:
##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner Output:
Total: 490, Passed: 482 (98.4%), Failed: 4, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.105 seconds LL Privacy - Add Device 2 (2 Devices to AL) Failed 0.171 seconds LL Privacy - Add Device 3 (AL is full) Failed 0.191 seconds LL Privacy - Set Device Flag 1 (Device Privacy) Failed 0.157 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 1.792 seconds Mesh - Send cancel - 2 Timed out 1.994 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series Output:
---
Regards,
Linux Bluetooth
This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:
Quoted 11 lines · On Thu, 23 Oct 2025 14:05:30 +0200 you wrote:
The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS).
This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS.
[...]
Here is the summary with links:
- [v2] Bluetooth: rfcomm: fix modem control handling
https://git.kernel.org/bluetooth/bluetooth-next/c/8d2c47aeb078
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Dear Johan,
Thank you for your patch.
Am 23.10.25 um 14:05 schrieb Johan Hovold:
Quoted 10 lines
The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS).
This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS.
Quoted 5 lines
Note that the bogus control of input signals in
tiocmset()is just dead code as those flags will have been masked out by the tty layer since 2003.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")
There is a linux-history git archive [1], if somebody wants dig further. But not relevant for the tag used by the stable folks.
Is there any way to test your change, to read DTR and RTS state?
Quoted 61 lines
Signed-off-by Johan Hovold <[email protected]>---
Changes in v2
- fix a compilation issue discovered before sending v1 but never folded into the actual patch...net/bluetooth/rfcomm/tty.c | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-)net/bluetooth/rfcomm/tty.c +10
-10@@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig)tty_port_tty_hangup (&dev->port, true); dev->modem_status = - ((v24_sig &RFCOMM_V24_RTC ) ? (TIOCM_DSR |TIOCM_DTR ) :0 ) | - ((v24_sig &RFCOMM_V24_RTR ) ? (TIOCM_RTS |TIOCM_CTS ) :0 ) | + ((v24_sig &RFCOMM_V24_RTC ) ?TIOCM_DSR :0 ) | + ((v24_sig &RFCOMM_V24_RTR ) ?TIOCM_CTS :0 ) | ((v24_sig &RFCOMM_V24_IC ) ?TIOCM_RI :0 ) | ((v24_sig &RFCOMM_V24_DV ) ?TIOCM_CD :0 ); }@@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty)static int rfcomm_tty_tiocmget (struct tty_struct *tty) {struct rfcomm_dev *dev = tty->driver_data; +struct rfcomm_dlc *dlc = dev->dlc; +u8 v24_sig;BT_DBG ("tty %p dev %p" , tty, dev); -return dev->modem_status; +rfcomm_dlc_get_modem_status (dlc, &v24_sig); + +return (v24_sig & (TIOCM_DTR |TIOCM_RTS )) | dev->modem_status; }static int rfcomm_tty_tiocmset (struct tty_struct *tty,unsigned int set,unsigned int clear)@@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsignerfcomm_dlc_get_modem_status (dlc, &v24_sig); -if (set &TIOCM_DSR || set &TIOCM_DTR ) +if (set &TIOCM_DTR ) v24_sig |=RFCOMM_V24_RTC ; -if (set &TIOCM_RTS || set &TIOCM_CTS ) +if (set &TIOCM_RTS ) v24_sig |=RFCOMM_V24_RTR ; -if (set &TIOCM_RI ) - v24_sig |=RFCOMM_V24_IC ; -if (set &TIOCM_CD ) - v24_sig |=RFCOMM_V24_DV ; -if (clear &TIOCM_DSR || clear &TIOCM_DTR ) +if (clear &TIOCM_DTR ) v24_sig &= ~RFCOMM_V24_RTC ;
net/bluetooth/rfcomm/tty.c static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne · line 1089
Quoted 10 lines
net/bluetooth/rfcomm/tty.c +1
-5-if (clear &TIOCM_RTS || clear &TIOCM_CTS ) +if (clear &TIOCM_RTS ) v24_sig &= ~RFCOMM_V24_RTR ; -if (clear &TIOCM_RI ) - v24_sig &= ~RFCOMM_V24_IC ; -if (clear &TIOCM_CD ) - v24_sig &= ~RFCOMM_V24_DV ;rfcomm_dlc_set_modem_status (dlc, v24_sig);
Kind regards,
Paul
[1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Quoted 11 lines · Paul Menzel
Am 23.10.25 um 14:05 schrieb Johan Hovold:
Quoted 10 lines
The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS).
This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS.
Quoted 8 lines
Quoted 5 lines
Note that the bogus control of input signals in
tiocmset()is just dead code as those flags will have been masked out by the tty layer since 2003.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")There is a linux-history git archive [1], if somebody wants dig further. But not relevant for the tag used by the stable folks.
Yeah, that's tree I use.
Quoted 1 line
Is there any way to test your change, to read DTR and RTS state?
This can be tested using the TIOCMGET and TIOCMSET (or TIOCMBIS/TIOCMBIC) ioctls. I use a custom c application, and I'm not aware of any particular application you can you use for testing if that's what you were after.
Johan