From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jan 3 15:20:10 2011 Return-Path: Delivered-To: freebsd-bluetooth@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62975106566C for ; Mon, 3 Jan 2011 15:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 368188FC08 for ; Mon, 3 Jan 2011 15:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p03FK6eo027617 for ; Mon, 3 Jan 2011 15:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p03FK6IM027615; Mon, 3 Jan 2011 15:20:06 GMT (envelope-from gnats) Date: Mon, 3 Jan 2011 15:20:06 GMT Message-Id: <201101031520.p03FK6IM027615@freefall.freebsd.org> To: freebsd-bluetooth@FreeBSD.org From: Iain Hibbert Cc: Subject: Re: kern/140590: [bluetooth] ng_ubt(4) ng_l2cap_process_cmd_rej warnings X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Iain Hibbert List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:20:10 -0000 The following reply was made to PR kern/140590; it has been noted by GNATS. From: Iain Hibbert To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/140590: [bluetooth] ng_ubt(4) ng_l2cap_process_cmd_rej warnings Date: Mon, 3 Jan 2011 14:40:47 +0000 (GMT) On Mon, 3 Jan 2011, FreeBSD bugmaster wrote: > p kern/140590 bluetooth [bluetooth] ng_ubt(4) ng_l2cap_process_cmd_rej warning the final piece of this PR is that a ng_btsocket_rfcomm_receive_dm: Got DM for non-existing dlci=18 warning is produced.. looking at the dump given: < ACL data: handle 42 flags 0x02 dlen 11 L2CAP(d): cid 0x0041 len 7 [psm 3] RFCOMM(d): UIH: cr 1 dlci 18 pf 0 ilen 3 fcs 0xce OBEX: Disconnect cmd(f): len 3 > ACL data: handle 42 flags 0x02 dlen 12 L2CAP(d): cid 0x0047 len 8 [psm 3] RFCOMM(d): UIH: cr 0 dlci 18 pf 1 ilen 3 fcs 0x8 credits 1 OBEX: Disconnect rsp(f): status 200 len 3 OBEX is disconnected < ACL data: handle 42 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3 we send a DISC(18) request to disconnect the channel > ACL data: handle 42 flags 0x02 dlen 8 L2CAP(d): cid 0x0047 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 18 pf 1 ilen 0 fcs 0xb2 < ACL data: handle 42 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 18 pf 1 ilen 0 fcs 0x98 they also do that, and we send a UA in response as is proper < ACL data: handle 42 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd and then we send DISC(0) to disconnect the session > ACL data: handle 42 flags 0x02 dlen 8 L2CAP(d): cid 0x0047 len 4 [psm 3] RFCOMM(s): DM: cr 1 dlci 18 pf 1 ilen 0 fcs 0x18 and this is the rogue DM - I guess that the other side had deleted the dlci handle when it sent the DISC so this is their response to our DISC(18) message.. The warning is printed because FreeBSD had legitimately decided that dlci 18 was closed (received DISC, sent UA) and therefore this DM is addressed to a vacant channel.. IMO FreeBSD did nothing really wrong there except warn about something that was not really a dire situation.. perhaps the _WARN should just be changed to _INFO to supress that in normal use? iain PS what was the remote device?