Hello, I discovered some state transitions that does not comply with the specification.
However, I'm not sure whether it is a design choice (i.e., intended).
Specifically, l2cap_chan::state is transitioned from BT_CONFIG to BT_DISCONN by CONFIG_RSP as shown in the following code.
|
default: |
|
l2cap_chan_set_err(chan, ECONNRESET); |
|
|
|
__set_chan_timer(chan, L2CAP_DISC_REJ_TIMEOUT); |
|
l2cap_send_disconn_req(chan, ECONNRESET); |
|
goto done; |
|
} |
AFAIK,
BT_DISCONN state is corresponding to
WAIT_DISCONNECT of the speicification.
However,
BT_CONFIG cannot be transitioned to
WAIT_DISCONNECT by
CONFIG_RSP.
According to the figure from the specification, only CloseChannelReq or L2CAP_DisconnectReq can make a transition l2cap_chan::state from BT_CONFIG to BT_DISCONN.
I guess if the request is malformed, then channel is going to close.
But it is not specified in the standard document (i.e., Bluetooth Core Specification v5.3).
Is this intended behavior? (e.g., to protect host?)
Hello, I discovered some state transitions that does not comply with the specification.
However, I'm not sure whether it is a design choice (i.e., intended).
Specifically,
l2cap_chan::stateis transitioned fromBT_CONFIGtoBT_DISCONNbyCONFIG_RSPas shown in the following code.bluetooth-next/net/bluetooth/l2cap_core.c
Lines 4581 to 4587 in ed680f9
AFAIK,
BT_DISCONNstate is corresponding toWAIT_DISCONNECTof the speicification.However,
BT_CONFIGcannot be transitioned toWAIT_DISCONNECTbyCONFIG_RSP.According to the figure from the specification, only
CloseChannelReqorL2CAP_DisconnectReqcan make a transitionl2cap_chan::statefromBT_CONFIGtoBT_DISCONN.I guess if the request is malformed, then channel is going to close.
But it is not specified in the standard document (i.e., Bluetooth Core Specification v5.3).
Is this intended behavior? (e.g., to protect host?)