Revision 98bcd08b5bfe78c1c9bda5768aa081e0fe4fcc4f authored by Marcel Holtmann on 14 July 2006, 09:42:12 UTC, committed by David S. Miller on 24 July 2006, 19:44:25 UTC
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>
1 parent 2266d88