summaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth
diff options
context:
space:
mode:
authorGustavo F. Padovan <gustavo@las.ic.unicamp.br>2009-10-03 02:34:38 -0300
committerMarcel Holtmann <marcel@holtmann.org>2009-12-03 19:34:23 +0100
commit9f121a5a80b4417c6db5a35e26d2e79c29c3fc0d (patch)
tree8e01df10e3e640c0f76b4c3f380db351543900bb /include/net/bluetooth
parent889a3ca466018ab68363c3168993793bc2d984f1 (diff)
downloadop-kernel-dev-9f121a5a80b4417c6db5a35e26d2e79c29c3fc0d.zip
op-kernel-dev-9f121a5a80b4417c6db5a35e26d2e79c29c3fc0d.tar.gz
Bluetooth: Fix sending ReqSeq on I-frames
As specified by ERTM spec an ERTM channel can acknowledge received I-frames(the data frames) by sending an I-frame with the proper ReqSeq value (i.e. ReqSeq is set to BufferSeq). Until now we aren't setting the ReqSeq value on I-frame control bits. That way we can save sending S-frames(Supervise frames) only to acknowledge receipt of I-frames. It is very helpful to the full-duplex channel. ReqSeq is the packet sequence number sent in an acknowledgement frame to acknowledge receipt of frames up to (ReqSeq - 1). BufferSeq controls the receiver buffer, it is used to delay acknowledgement of new frames to not cause buffer overflow. BufferSeq value is not increased until frames are pulled by reassembly function. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'include/net/bluetooth')
-rw-r--r--include/net/bluetooth/l2cap.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 9516f4b..327eb57 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -324,7 +324,6 @@ struct l2cap_pinfo {
__u8 next_tx_seq;
__u8 expected_ack_seq;
- __u8 req_seq;
__u8 expected_tx_seq;
__u8 buffer_seq;
__u8 buffer_seq_srej;
OpenPOWER on IntegriCloud