]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Make sure RFCOMM multiplexor channel does not hang in DISCONNECTING
authorMaksim Yevmenkin <emax@FreeBSD.org>
Fri, 23 Apr 2004 20:21:17 +0000 (20:21 +0000)
committerMaksim Yevmenkin <emax@FreeBSD.org>
Fri, 23 Apr 2004 20:21:17 +0000 (20:21 +0000)
commit48bd0712bc11e05e5c4a6ad33438032eb0bd7b24
tree5f8877a798187f70ffdcb1bc55571951138f2138
parent666ea1b65fe1255c6408ed3b55a4458756c004d0
Make sure RFCOMM multiplexor channel does not hang in DISCONNECTING
state. Apparently it happens when both devices try to disconnect RFCOMM
multiplexor channel at the same time.

The scenario is as follows:

- local device initiates RFCOMM connection to the remote device. This
  creates both RFCOMM multiplexor channel and data channel;

- remote device terminates RFCOMM data channel (inactivity timeout);

- local device acknowledges RFCOMM data channel termination. Because
  there is no more active data channels and local device has initiated
  connection it terminates RFCOMM multiplexor channel;

- remote device does not acknowledges RFCOMM multiplexor channel
  termination. Instead it sends its own request to terminate RFCOMM
  multiplexor channel. Even though local device acknowledges RFCOMM
  multiplexor channel termination the remote device still keeps
  L2CAP connection open.

Because of hanging RFCOMM multiplexor channel subsequent RFCOMM
connections between local and remote devices will fail.

Reported by: Johann Hugo <jhugo@icomtek.csir.co.za>
sys/netgraph/bluetooth/socket/ng_btsocket_rfcomm.c