| commit | 98bcd08b5bfe78c1c9bda5768aa081e0fe4fcc4f | |
| author | Marcel Holtmann <marcel@holtmann.org> | |
| Fri, 14 Jul 2006 09:42:12 +0000 (14 11:42 +0200) | ||
| committer | David S. Miller <davem@sunset.davemloft.net> | |
| Mon, 24 Jul 2006 19:44:25 +0000 (24 12:44 -0700) | ||
| tree | 171c7984eeaade72d57a325ee26d55e4408bbdd1 | treesnapshot (tar.gz zip) |
| parent | 2266d8886f64c66e0a4e61e3e1c19dbc27ed00d4 | commitdiff |
[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>
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 | diffblobblamehistory |