From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 12 22:28:59 2012 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5C8E453 for ; Fri, 12 Oct 2012 22:28:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtpout.wanadoo.co.uk (smtpout5.wanadoo.co.uk [80.12.242.80]) by mx1.freebsd.org (Postfix) with ESMTP id 80BF58FC16 for ; Fri, 12 Oct 2012 22:28:58 +0000 (UTC) Received: from galant.ukfsn.org ([109.249.105.184]) by mwinf5d63 with ME id ANMB1k0063yjrMH03NMCiJ; Sat, 13 Oct 2012 00:21:17 +0200 Received: by galant.ukfsn.org (Postfix, from userid 1000) id AB48E2600A0; Fri, 12 Oct 2012 23:21:52 +0100 (BST) Date: Fri, 12 Oct 2012 23:21:52 +0100 (BST) From: Iain Hibbert To: Andreas Longwitz Subject: Re: btpand problem In-Reply-To: <50782E05.5080005@incore.de> Message-ID: References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-bluetooth@freebsd.org X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:29:00 -0000 On Fri, 12 Oct 2012, Andreas Longwitz wrote: > > Is this more than one connection, can you show the entire dump? (the first > > one is a rsp from the other side, then it sends a req later..?) > > I have only one connection: the dump gives the output of the command > btpand -a panserver -d me -s NAP -i tap1. Full dump: yes, there are two L2CAP connections :) the first is to do the SDP query, then it sets up the BNEP link. And, it seems that the BNEP link has been set up with a MTU/MRU of 1691 as it should have.. > Yes, I used the code fragment > > { > uint16_t mtu; > socklen_t len = sizeof(mtu); > getsockopt(chan->fd, SOL_L2CAP, SO_L2CAP_OMTU,&mtu,&len); > log_err("writev: %m (mtu %d)\n", mtu); > } > > and found mtu=1691 in all cases (ok or failed), same for SO_L2CAP_IMTU. I see, so it seems that the kernel is returning EMSGSIZE when trying to send a packet that is greater than L2CAP_MTU_DEFAULT.. you could build the bluetooth netgraph code with debugging turned on, and see if that kicked anything out about where the error is returned from.. The most obvious place to look at could be ng_btsocket_l2cap_send(), if that is the one, is pcb->omtu the correct value? iain