From owner-freebsd-bluetooth@FreeBSD.ORG Wed Oct 10 07:25:48 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 69C7A27E for ; Wed, 10 Oct 2012 07:25:48 +0000 (UTC) (envelope-from gregg@gforcepr.com) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by mx1.freebsd.org (Postfix) with ESMTP id 17C658FC0A for ; Wed, 10 Oct 2012 07:25:47 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id q9A7PfWS006643 for ; Wed, 10 Oct 2012 03:25:41 -0400 Received: (qmail 7465 invoked by uid 0); 10 Oct 2012 07:25:41 -0000 Received: from unknown (HELO gforcepr.com) (gregg@gforcepr.com@95) by 0 with ESMTPA; 10 Oct 2012 07:25:41 -0000 Date: Wed, 10 Oct 2012 7:26:17 +0300 From: =?windows-1251?Q?=D1=EC=E5=F1=E8=F2=E5=EB=E8_GROHE?= Organization: tboprh X-Priority: 3 (Normal) Message-ID: <7276101151.20121010072617@gforcepr.com> To: freebsd-bluetooth@freebsd.org Subject: =?windows-1251?Q?=D1=EC=E5=F1=E8T=E5=EB=E8_=EE=EF=F2=EE=EC_=EF=F0=EE=E4=E0=E5=EC?= MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit 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: Wed, 10 Oct 2012 07:25:48 -0000 http://lovo6by5xr.site.aplus.net/0kapitan.php mail: info@groheopt.ru tel: 89266157076 Тимофей From owner-freebsd-bluetooth@FreeBSD.ORG Wed Oct 10 07:48:55 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 A11AC85E for ; Wed, 10 Oct 2012 07:48:55 +0000 (UTC) (envelope-from choliboy@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.206]) by mx1.freebsd.org (Postfix) with ESMTP id 536418FC0A for ; Wed, 10 Oct 2012 07:48:54 +0000 (UTC) Received: from interia.pl (unknown [200.75.54.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by poczta.interia.pl (INTERIA.PL) with ESMTPSA for ; Wed, 10 Oct 2012 09:24:35 +0200 (CEST) Date: Wed, 10 Oct 2012 2:24:56 +0700 From: =?windows-1251?Q?=D1=EC=E5=F1=E8=F2e=EB=E8_GROH=C5?= Organization: rovpweh X-Priority: 3 (Normal) Message-ID: <6596308900.20121010022456@interia.pl> To: freebsd-bluetooth@freebsd.org Subject: =?windows-1251?Q?=D1=EC=E5=F1=E8=F2=E5=EB=E8_=EE=EF=F2=EEM?= MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Interia-Antivirus: OK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1349853925; bh=TzSOeyAJdH2XVGt+ZIsqRIPaEoBdBBujHxYvaQmUpkA=; h=Received:Date:From:Organization:X-Priority:Message-ID:To:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding: X-Interia-Antivirus; b=IXAZ1skyf108SIfmbtVlHbcs8Go3Nsfoe9KOsXXH/mwpfaLeLs4St7NSPF54R+9i3 1thjqHkwnkdQgy+PEXA7ZzLJ9XzixpErMChiuX8EQNn3EaIIbeaexj0cKRo++8XiqA YjUNKRcUNyrjoMSrhO7s2yIJalOcLko8HvCPxLxQ= 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: Wed, 10 Oct 2012 07:48:55 -0000 http://www.jtmlandscapes.co.uk/0kapitan.php mail: info@groheopt.ru tel: 8-926-615-70-76 Тимофей From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 11 21:14:19 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 50573CA0 for ; Thu, 11 Oct 2012 21:14:19 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 101C78FC0A for ; Thu, 11 Oct 2012 21:14:18 +0000 (UTC) Received: from secmail.incore (inetdns.dmz [10.1.0.3]) by dss.incore.de (Postfix) with ESMTP id 28A175D3D8 for ; Thu, 11 Oct 2012 23:14:12 +0200 (CEST) Received: from lolap.longwitz (ip-2-203-147-109.web.vodafone.de [2.203.147.109]) by secmail.incore (Postfix) with ESMTPS id E93AF5C0E for ; Thu, 11 Oct 2012 23:14:11 +0200 (CEST) Message-ID: <507736A8.4050605@incore.de> Date: Thu, 11 Oct 2012 23:14:16 +0200 From: Andreas Longwitz User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-bluetooth@freebsd.org Subject: btpand problem Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 11 Oct 2012 21:14:19 -0000 Hi, I have the problem described in this list in May 2009 (btpand example) with FreeBSD 8.3. ping -s 635 panserver --> ICMP 677 --> nw=672 in bnep_send(), writev syscall is ok with iov[0].iov_len=9 and iov[1].iov_len=663. ping -s 636 panserver --> ICMP 678 --> nw=-1, errno=40 (EMSGSIZE) is not ok with iov[0].iov_len=9 and iov[1].iov_len=664. In the error case the trace written by hcidump is empty (no suprise). My tap interface has mtu=1500 < 1691 (checked in bnep_send). Where should I look next ? Andreas Longwitz From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 11 21:56:09 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 721C0B11 for ; Thu, 11 Oct 2012 21:56:09 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0DA8FC08 for ; Thu, 11 Oct 2012 21:56:09 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so2491788pbb.13 for ; Thu, 11 Oct 2012 14:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=3mYSfFBCqtQ3bibs3VTdNa/UP6AwKJ3elZzxYV4SkPQ=; b=Yyp5a43wAQRPzj0HI2bK2CyxUlRrFahVylGYVI+DbKtmxs6IQA53NKAJ94e9y8eItd BYzyAHTDWqamdrnWu5JCoHvxenMu9Qjcd3CtGnlaST/JTw0prMYJ9Sw3ZuBA/T3ZdCvn fYER/8UaDP2WQQo2hfxt3eSaW+Q7C/SJO7Wo1jfN3ZssM2q9gnKEzLRTuiPVnga6qPT2 SBIzKz4DMsjMO2GmAMj7aZ/eO11JOmY9YxNCEusH/PJjXfugsSSm1vHnyOBw1wfq+IoR wjJqeBq9sRDbd+XdUKi06aF117lw1zrtLhn59IC1KeH0kaaLBhx1vQe9xEE9LFF/SSaN dckg== Received: by 10.66.76.98 with SMTP id j2mr5666731paw.65.1349992569068; Thu, 11 Oct 2012 14:56:09 -0700 (PDT) Received: from [10.35.90.51] (mobile-198-228-222-198.mycingular.net. [198.228.222.198]) by mx.google.com with ESMTPS id qj6sm2508903pbb.69.2012.10.11.14.56.07 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 14:56:08 -0700 (PDT) References: <507736A8.4050605@incore.de> Mime-Version: 1.0 (1.0) In-Reply-To: <507736A8.4050605@incore.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A405) From: maksim yevmenkin Subject: Re: btpand problem Date: Thu, 11 Oct 2012 14:56:07 -0700 To: Andreas Longwitz 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: Thu, 11 Oct 2012 21:56:09 -0000 Hi! Can you tell what l2cap Mtu was negotiated on both ends? Thanks, Max On Oct 11, 2012, at 2:14 PM, Andreas Longwitz wrote: > Hi, >=20 > I have the problem described in this list in May 2009 (btpand example) wit= h FreeBSD 8.3. >=20 > ping -s 635 panserver --> ICMP 677 --> nw=3D672 in bnep_send(), writev sys= call is ok with iov[0].iov_len=3D9 and iov[1].iov_len=3D663. >=20 > ping -s 636 panserver --> ICMP 678 --> nw=3D-1, errno=3D40 (EMSGSIZE) is n= ot ok with iov[0].iov_len=3D9 and iov[1].iov_len=3D664. >=20 > In the error case the trace written by hcidump is empty (no suprise). > My tap interface has mtu=3D1500 < 1691 (checked in bnep_send). >=20 > Where should I look next ? >=20 >=20 > Andreas Longwitz > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@freebsd.or= g" From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 11 22:32:48 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 06E103F9 for ; Thu, 11 Oct 2012 22:32:48 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id B95298FC12 for ; Thu, 11 Oct 2012 22:32:47 +0000 (UTC) Received: from secmail.incore (inetdns.dmz [10.1.0.3]) by dss.incore.de (Postfix) with ESMTP id A3A3B5C090; Fri, 12 Oct 2012 00:32:46 +0200 (CEST) Received: from lolap.longwitz (ip-2-203-147-109.web.vodafone.de [2.203.147.109]) by secmail.incore (Postfix) with ESMTPS id 565895C1E; Fri, 12 Oct 2012 00:32:46 +0200 (CEST) Message-ID: <5077490F.7010901@incore.de> Date: Fri, 12 Oct 2012 00:32:47 +0200 From: Andreas Longwitz User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: maksim yevmenkin , freebsd-bluetooth@freebsd.org Subject: Re: btpand problem References: <507736A8.4050605@incore.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 11 Oct 2012 22:32:48 -0000 Thanks for quick answer ! > Can you tell what l2cap Mtu was negotiated on both ends? HCIDump - HCI packet analyzer ver 1.5 ... > ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 4 MTU 672 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 4 MTU 256 .... < ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0203 flags 0x0000 clen 4 MTU 1691 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(s): Config rsp: scid 0x0050 flags 0x0000 result 0 clen 4 MTU 1691 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0050 flags 0x0000 clen 4 MTU 1691 .... My panserver is an iPhone 4S in hotspot mode. >> >> I have the problem described in this list in May 2009 (btpand example) with FreeBSD 8.3. >> >> ping -s 635 panserver --> ICMP 677 --> nw=672 in bnep_send(), writev syscall is ok with iov[0].iov_len=9 and iov[1].iov_len=663. >> >> ping -s 636 panserver --> ICMP 678 --> nw=-1, errno=40 (EMSGSIZE) is not ok with iov[0].iov_len=9 and iov[1].iov_len=664. >> >> In the error case the trace written by hcidump is empty (no suprise). >> My tap interface has mtu=1500< 1691 (checked in bnep_send). >> Andreas Longwitz From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 11 22:39:54 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 49E7870D for ; Thu, 11 Oct 2012 22:39:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2A88FC14 for ; Thu, 11 Oct 2012 22:39:53 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so2521135pbb.13 for ; Thu, 11 Oct 2012 15:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/lmQARAj1NdCRne8pGt3Lo5A/KoTBRDQ//jPELlTnCY=; b=WAYGdyisMsD+K/QahHkRE60GgHPoPAcXtrMyhNB0smI4NhvcLRWd2UzoEKyyaSfI0G IS69azqOlgpRNrvoFI6xr4diKuU1Pj75hTSUlAeeXAy4lSRBcEp5/tRuMgUt1oljd/D6 HuG81cwb2tFdyaXjXlP16GHVeSpiUkAutdMdFDOVJM6YTx/gHOK+8Ku5PZZGBWjdh+gz O6X+olGAEXiXFvk31grxdt+TgMvksSJWwzO3ZO2xcqX4OhaT/ns7CjtYxj7K7HT6jOWE /3dkic9rDdKma11FCIZQP3wJVCaMFGjLcU0dm2O8Yczk8WR37MJgwpqN6wYy5WbpYzNy /ZBg== MIME-Version: 1.0 Received: by 10.68.222.37 with SMTP id qj5mr7687712pbc.132.1349995193681; Thu, 11 Oct 2012 15:39:53 -0700 (PDT) Received: by 10.68.240.38 with HTTP; Thu, 11 Oct 2012 15:39:53 -0700 (PDT) In-Reply-To: <5077490F.7010901@incore.de> References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> Date: Thu, 11 Oct 2012 15:39:53 -0700 Message-ID: Subject: Re: btpand problem From: Maksim Yevmenkin To: Andreas Longwitz Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 11 Oct 2012 22:39:54 -0000 On Thu, Oct 11, 2012 at 3:32 PM, Andreas Longwitz wrote: > Thanks for quick answer ! > >> Can you tell what l2cap Mtu was negotiated on both ends? > > HCIDump - HCI packet analyzer ver 1.5 > ... >> ACL data: handle 0x002a flags 0x02 dlen 18 > L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 4 > MTU 672 >> ACL data: handle 0x002a flags 0x02 dlen 16 > L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 4 > MTU 256 > .... > < ACL data: handle 0x002a flags 0x02 dlen 16 > L2CAP(s): Config req: dcid 0x0203 flags 0x0000 clen 4 > MTU 1691 >> HCI Event: Number of Completed Packets(0x13) plen 5 >> ACL data: handle 0x002a flags 0x02 dlen 18 > L2CAP(s): Config rsp: scid 0x0050 flags 0x0000 result 0 clen 4 > MTU 1691 >> ACL data: handle 0x002a flags 0x02 dlen 16 > L2CAP(s): Config req: dcid 0x0050 flags 0x0000 clen 4 > MTU 1691 > .... > > My panserver is an iPhone 4S in hotspot mode. well, it looks like your device told btpand(8) that it can not accept more than 672 bytes (default l2cap mtu) at a time. hence the emsgsize error, i.e. datagram, btpand(8) is trying to send, is too big for remote device to accept. quick fix would be to adjust mtu on the tap interface to make sure btpand(8) never tries to send more than 672 bytes of payload. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 12 09:03:14 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 65EBF103 for ; Fri, 12 Oct 2012 09:03:14 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtpout.wanadoo.co.uk (smtpout2.wanadoo.co.uk [80.12.242.42]) by mx1.freebsd.org (Postfix) with ESMTP id CEE138FC0A for ; Fri, 12 Oct 2012 09:03:13 +0000 (UTC) Received: from galant.ukfsn.org ([109.249.208.208]) by mwinf5d30 with ME id A8vY1k0074WKEX9038vZhU; Fri, 12 Oct 2012 10:55:36 +0200 Received: by galant.ukfsn.org (Postfix, from userid 1000) id 36C852600A0; Fri, 12 Oct 2012 09:56:18 +0100 (BST) Date: Fri, 12 Oct 2012 09:56:18 +0100 (BST) From: Iain Hibbert To: Maksim Yevmenkin Subject: Re: btpand problem In-Reply-To: Message-ID: References: <507736A8.4050605@incore.de> <5077490F.7010901@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, Andreas Longwitz 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 09:03:14 -0000 On Thu, 11 Oct 2012, Maksim Yevmenkin wrote: > On Thu, Oct 11, 2012 at 3:32 PM, Andreas Longwitz wrote: > > Thanks for quick answer ! > > > >> Can you tell what l2cap Mtu was negotiated on both ends? > > > > HCIDump - HCI packet analyzer ver 1.5 > > ... > >> ACL data: handle 0x002a flags 0x02 dlen 18 > > L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 4 > > MTU 672 > >> ACL data: handle 0x002a flags 0x02 dlen 16 > > L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 4 > > MTU 256 > > .... > > < ACL data: handle 0x002a flags 0x02 dlen 16 > > L2CAP(s): Config req: dcid 0x0203 flags 0x0000 clen 4 > > MTU 1691 > >> HCI Event: Number of Completed Packets(0x13) plen 5 > >> ACL data: handle 0x002a flags 0x02 dlen 18 > > L2CAP(s): Config rsp: scid 0x0050 flags 0x0000 result 0 clen 4 > > MTU 1691 > >> ACL data: handle 0x002a flags 0x02 dlen 16 > > L2CAP(s): Config req: dcid 0x0050 flags 0x0000 clen 4 > > MTU 1691 > > .... > > > > My panserver is an iPhone 4S in hotspot mode. 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..?) > well, it looks like your device told btpand(8) that it can not accept > more than 672 bytes (default l2cap mtu) at a time. hence the emsgsize > error, i.e. datagram, btpand(8) is trying to send, is too big for > remote device to accept. quick fix would be to adjust mtu on the tap > interface to make sure btpand(8) never tries to send more than 672 > bytes of payload. except that client_init() requires that the negotiated outgoing MTU be at least the BNEP minimum MTU (1691), and bnep_send will fail if the packet is larger than the channel MTU .. Andreas, can you add some debug to the end of bnep_send() something like if (nw == -1) { uint16_t mtu; socklen_t len = sizeof(mtu); getsockopt(fd, BTPROTO_L2CAP, SO_L2CAP_OMTU, &mtu, &len); log_err("writev failed: %m (mtu %d)\n", mtu); } ? iain From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 12 14:49:42 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 704D5782 for ; Fri, 12 Oct 2012 14:49:42 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id C42948FC1D for ; Fri, 12 Oct 2012 14:49:41 +0000 (UTC) Received: from secmail.incore (inetdns.dmz [10.1.0.3]) by dss.incore.de (Postfix) with ESMTP id 594D95C08E; Fri, 12 Oct 2012 16:49:40 +0200 (CEST) Received: from lolap.longwitz (ip-2-203-147-109.web.vodafone.de [2.203.147.109]) by secmail.incore (Postfix) with ESMTPS id 223605C28; Fri, 12 Oct 2012 16:49:38 +0200 (CEST) Message-ID: <50782E05.5080005@incore.de> Date: Fri, 12 Oct 2012 16:49:41 +0200 From: Andreas Longwitz User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Iain Hibbert Subject: Re: btpand problem References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 14:49:42 -0000 Hi, > 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: HCIDump - HCI packet analyzer ver 1.5 < HCI Command: Create Connection(0x01|0x0005) plen 13 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Role Change(0x12) plen 8 > HCI Event: Connect Complete(0x03) plen 11 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 < ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x004f > HCI Event: Max Slots Change(0x1b) plen 3 > HCI Event: Number of Completed Packets(0x13) plen 5 > HCI Event: Command Complete(0x0e) plen 6 > ACL data: handle 0x002a flags 0x02 dlen 10 L2CAP(s): Info req: dlen 2 < ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Info rsp: dlen 4 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0103 scid 0x004f result 0 status 0 < ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Config req: dcid 0x0103 flags 0x0000 clen 0 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(s): Config rsp: scid 0x004f flags 0x0000 result 0 clen 4 MTU 672 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x004f flags 0x0000 clen 4 MTU 256 < ACL data: handle 0x002a flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0103 flags 0x0000 result 0 clen 0 < ACL data: handle 0x002a flags 0x02 dlen 24 L2CAP(d): cid 0x103 len 20 [psm 1] SDP SSA Req: tid 0x0 len 0xf pat uuid-16 0x1116 (NAP) max 0xffff aid(s) 0x0004 (ProtocolDescList) cont 00 > HCI Event: Number of Completed Packets(0x13) plen 5 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 51 L2CAP(d): cid 0x4f len 47 [psm 1] SDP SSA Rsp: tid 0x0 len 0x2a cnt 0x27 srv rec #0 aid 0x0004 (ProtocolDescList) < < uuid-16 0x0100 (L2CAP) uint 0xf > < uuid-16 0x000f (BNEP) uint 0x100 < uint 0x800 uint 0x806 uint 0x8100 uint 0x86dd > > > cont 00 < ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x0103 scid 0x004f < ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Connect req: psm 15 scid 0x0050 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x0103 scid 0x004f > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0203 scid 0x0050 result 1 status 1 > HCI Event: Link Key Request(0x17) plen 6 < HCI Command: Link Key Request Reply(0x01|0x000b) plen 22 > HCI Event: Command Complete(0x0e) plen 10 > HCI Event: Encrypt Change(0x08) plen 4 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0203 scid 0x0050 result 0 status 0 < ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0203 flags 0x0000 clen 4 MTU 1691 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(s): Config rsp: scid 0x0050 flags 0x0000 result 0 clen 4 MTU 1691 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0050 flags 0x0000 clen 4 MTU 1691 < ACL data: handle 0x002a flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0203 flags 0x0000 result 0 clen 0 < ACL data: handle 0x002a flags 0x02 dlen 11 L2CAP(d): cid 0x203 len 7 [psm 15] BNEP: Control(0x01|0) Setup Req(0x01) size 0x02 dst 0x1116(NAP) src 0x1115(PANU) > HCI Event: Number of Completed Packets(0x13) plen 5 > HCI Event: Number of Completed Packets(0x13) plen 5 > ACL data: handle 0x002a flags 0x02 dlen 8 L2CAP(d): cid 0x50 len 4 [psm 15] BNEP: Control(0x01|0) Setup Rsp(0x02) res 0x0000 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 > HCI Event: Mode Change(0x14) plen 6 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 341 L2CAP(d): cid 0x203 len 337 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0800] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 41 L2CAP(d): cid 0x203 len 37 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0806] > HCI Event: Number of Completed Packets(0x13) plen 5 < ACL data: handle 0x002a flags 0x02 dlen 41 L2CAP(d): cid 0x203 len 37 [psm 15] BNEP: Compressed DestOnly(0x04|0) dst ff:ff:ff:ff:ff:ff [proto 0x0806] > HCI Event: Number of Completed Packets(0x13) plen 5 >> well, it looks like your device told btpand(8) that it can not accept >> more than 672 bytes (default l2cap mtu) at a time. hence the emsgsize >> error, i.e. datagram, btpand(8) is trying to send, is too big for >> remote device to accept. quick fix would be to adjust mtu on the tap >> interface to make sure btpand(8) never tries to send more than 672 >> bytes of payload. I did try mtu=650 on my tap interface, but then large http transfers are stalled after some seconds. I will check again when this actual problem is solved. > except that client_init() requires that the negotiated outgoing MTU be at > least the BNEP minimum MTU (1691), and bnep_send will fail if the packet > is larger than the channel MTU .. > > Andreas, can you add some debug to the end of bnep_send() something like > > if (nw == -1) { > uint16_t mtu; > socklen_t len = sizeof(mtu); > getsockopt(fd, BTPROTO_L2CAP, SO_L2CAP_OMTU,&mtu,&len); > log_err("writev failed: %m (mtu %d)\n", mtu); > } > > ? 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. Andreas Longwitz 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 From owner-freebsd-bluetooth@FreeBSD.ORG Fri Oct 12 23:53:33 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 EB8C3C48 for ; Fri, 12 Oct 2012 23:53:33 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA3218FC0C for ; Fri, 12 Oct 2012 23:53:33 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so3630456pbb.13 for ; Fri, 12 Oct 2012 16:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BLqeXH0Ze1sfviN9LVaTneBnLLG5V6NbowLq5j4TTD0=; b=yqoNj8CdkRN1dLNsxLmumOMjVhyKihKc0VKADR0Bj4bl2P9nNx9EoxS4N+CrrUrQBe EvIW5knRXmQbXLhHVxsws+2w6m/UAAvj5o7gRsi00Uys3+ku7sT9w3bze6PaXRz/i0KD 6IaD+LOVogOfXzsYkVE1O99IxrQqOgHauUdDjhxhHMHw/P0bwApDROAJo144pmWSiaY7 BANTAlAb+JcKeakfoVVWmZgzOSXVZrEOTrrBmXS/VfRaPBARKDzEh5BP3EbFqz91x60T nL5sP8pLxrpg42eAgUeMF6MiAK+3KXzGkXh+wDDhC9PknfOmXAa91H0aA49roi4bP9Iw yp5A== MIME-Version: 1.0 Received: by 10.66.77.199 with SMTP id u7mr15158196paw.7.1350086013405; Fri, 12 Oct 2012 16:53:33 -0700 (PDT) Received: by 10.68.240.38 with HTTP; Fri, 12 Oct 2012 16:53:33 -0700 (PDT) In-Reply-To: References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> Date: Fri, 12 Oct 2012 16:53:33 -0700 Message-ID: Subject: Re: btpand problem From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-bluetooth@freebsd.org, Andreas Longwitz 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 23:53:34 -0000 On Fri, Oct 12, 2012 at 3:21 PM, Iain Hibbert wrote: > 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? there should be sysctl knobs to increase debug level for sockets and ng messages for ng nodes. so, yes, please try to increase debug level for l2cap nodes and sockets and see if anything pops up thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Sat Oct 13 22:19:41 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 66A2CA7B for ; Sat, 13 Oct 2012 22:19:41 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1DAD78FC0A for ; Sat, 13 Oct 2012 22:19:40 +0000 (UTC) Received: from secmail.incore (inetdns.dmz [10.1.0.3]) by dss.incore.de (Postfix) with ESMTP id 1A4365D424; Sun, 14 Oct 2012 00:19:33 +0200 (CEST) Received: from lolap.longwitz (ip-2-204-14-210.web.vodafone.de [2.204.14.210]) by secmail.incore (Postfix) with ESMTPS id AD1C55C14; Sun, 14 Oct 2012 00:19:32 +0200 (CEST) Message-ID: <5079E8F7.5050903@incore.de> Date: Sun, 14 Oct 2012 00:19:35 +0200 From: Andreas Longwitz User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Maksim Yevmenkin Subject: Re: btpand problem References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 13 Oct 2012 22:19:41 -0000 Hi, >>> 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? > > there should be sysctl knobs to increase debug level for sockets and > ng messages for ng nodes. > > so, yes, please try to increase debug level for l2cap nodes and > sockets and see if anything pops up After increasing debug_level for net.bluetooth.l2cap from 3 --> 4 and adding a statement NG_BTSOCKET_L2CAP_INFO(..) in ng_btsocket_l2cap_send it was clear to me that in the case of the failed writev none of the debug statements triggers. This information pointed me to the possible solution of the problem. The reason for the EMSGSIZE error is the size of the send space reserved with soreserve() in ng_btsocket_l2cap_attach. After changing (in ng_btsocket_l2cap.h) the line #define NG_BTSOCKET_L2CAP_SENDSPACE NG_L2CAP_MTU_DEFAULT /* (64 * 1024) */ to #define NG_BTSOCKET_L2CAP_SENDSPACE (64 * 1024) the error is gone. Please verify if this correction is suitable. Andreas Longwitz