From owner-freebsd-bluetooth@FreeBSD.ORG Sun Oct 14 19:02:44 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 9AB3FED2 for ; Sun, 14 Oct 2012 19:02:44 +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 50FE18FC08 for ; Sun, 14 Oct 2012 19:02:44 +0000 (UTC) Received: from secmail.incore (inetdns.dmz [10.1.0.3]) by dss.incore.de (Postfix) with ESMTP id 6D7E85C08E; Sun, 14 Oct 2012 21:02:43 +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 25F245C28; Sun, 14 Oct 2012 21:02:43 +0200 (CEST) Message-ID: <507B0C57.7030506@incore.de> Date: Sun, 14 Oct 2012 21:02: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: Iain Hibbert Subject: Re: btpand problem References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> <5079E8F7.5050903@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: Sun, 14 Oct 2012 19:02:44 -0000 Hi, thanks for the patch. >> but, btpand should also ensure that the buffer sizes are suitable. The >> server_init() function already does this in FreeBSD, though I also added >> some code to increase the RCVBUF size in NetBSD code, and also added (but >> didn't yet commit) the similar for client code.. I will prepare a patch > > patch for btpand attached I tried your patch and it works, I do not need the kernel patch for the default size of NG_BTSOCKET_L2CAP_SENDSPACE anymore. Now I describe another problem with my ping test, I am not sure if this problem concerns btpand too. If the ICMP packet must be fragmented, then the first fragment ist lost on the tap interface (and can not be found by tcpdump running on this tap) if an ARP request is necessary. ping -c 1 -s 1400 panserver works all the time, ping -c 1 -s 1600 panserver only works if the ip address of panserver is in the arp cache. I did nothing special with the tap interface, it is included in my "cloned_interfaces" in rc.conf and opened by btpand. Any ideas ? Andreas Longwitz