[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] why multiple L2CAP-cons for one phys link ?



Again my question (nobody interested or nobody has answers???)

Question to Mathias and all other specialists:

In BT spec 1.0B, RFCOMM section 2.3.2 we read:

"[...] Note that each multiplexer session is using its own L2CAP channel ID 
(CID)."

For each phys. connection between two different BT-devices there is only
ONE   RFCOMM mux session, right?

In the drawing above (2.3.1) there is only one L2CAP connection for one
connection between two BT devices.

But what the Axis driver does is establishing a new L2CAP 
connection (different CIDs) for every new RFCOMM connection (DLCI). 

Why that? Any idea?

Heiko


---------------------------

Here is what bt_internal says after connecting two lines on the same 
baseband-connection:

[BT Interface]
line[0] state : BT_LOWERCONNECTED
line[1] state : BT_LOWERCONNECTED
line[2] state : BT_INACTIVE
line[3] state : BT_INACTIVE
line[4] state : BT_INACTIVE
line[5] state : BT_INACTIVE
line[6] state : BT_INACTIVE
BT CTRL state : BT_UPPERCONNECTED [1 open]

[BTMEM]
Buffer holds : 0
Bytes left : 2228

[RFCOMM]

line[0] mtu[127] dlci#0 state[CONNECTED]
line[0] mtu[127] dlci#2 state[CONNECTED]
line[1] mtu[127] dlci#0 state[CONNECTED]
line[1] mtu[127] dlci#2 state[CONNECTED]

[L2CAP]

local bd :[00:d0:b7:03:4c:22]

r_bd[00:d0:b7:03:4b:bf ]
lcid[65] rcid[65] state[OPEN] psm[RFCOMM]
remote_mtu[672] local_mtu [672] clnt[yes] link_up[yes]


r_bd[00:d0:b7:03:4b:bf ]
lcid[64] rcid[64] state[OPEN] psm[RFCOMM]
remote_mtu[672] local_mtu [672] clnt[yes] link_up[yes]
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com