Hi Marcel, On Fri, Sep 13, 2013, Marcel Holtmann wrote: > > @@ -5304,6 +5305,9 @@ static inline void l2cap_le_sig_channel(struct l2cap_conn *conn, > > > > l2cap_raw_recv(conn, skb); > > > > + if (hcon->type != LE_LINK) > > + return; > > + > > However I do have a question here. Can we just drop the packet or > should we even in this case return invalid CID. What does the core > spec. recommend in this case? I faced this issue at the last UPF and had to do some thinking about it as well as discuss it with some other stack developers. The conclusion was that dropping is the right thing since on non-LE links this is in practice an unknown CID and unknown data. The core spec doesn't explicitly say that data should be dropped in this case (it doesn't say anything about responding either). Instead, the LE signaling channel is simply not defined for non-LE links (the exact words in the spec are "not available" and "not supported"). It's like you'd receive data on any unknown CID. Responding something on it would be just as bad behavior as the peer sending the initial command. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
