[Bluetooth] Correct RFCOMM channel MTU for broken implementations
commit98bcd08b5bfe78c1c9bda5768aa081e0fe4fcc4f
authorMarcel Holtmann <marcel@holtmann.org>
Fri, 14 Jul 2006 09:42:12 +0000 (14 11:42 +0200)
committerDavid S. Miller <davem@sunset.davemloft.net>
Mon, 24 Jul 2006 19:44:25 +0000 (24 12:44 -0700)
tree171c7984eeaade72d57a325ee26d55e4408bbdd1
parent2266d8886f64c66e0a4e61e3e1c19dbc27ed00d4
[Bluetooth] Correct RFCOMM channel MTU for broken implementations

Some Bluetooth RFCOMM implementations try to negotiate a bigger channel
MTU than we can support for a particular session. The maximum MTU for
a RFCOMM session is limited through the L2CAP layer. So if the other
side proposes a channel MTU that is bigger than the underlying L2CAP
MTU, we should reduce it to the L2CAP MTU of the session minus five
bytes for the RFCOMM headers.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
net/bluetooth/rfcomm/core.c