From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 15 21:17:51 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 7F790886 for ; Mon, 15 Oct 2012 21:17:51 +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 2C4CF8FC12 for ; Mon, 15 Oct 2012 21:17:50 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 7A7F85D48B; Mon, 15 Oct 2012 23:17:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id ptAoWsZ04TDY; Mon, 15 Oct 2012 23:17:43 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id B2B305D47B; Mon, 15 Oct 2012 23:17:43 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 5217C50830; Mon, 15 Oct 2012 23:17:43 +0200 (CEST) Message-ID: <507C7D76.4090303@incore.de> Date: Mon, 15 Oct 2012 23:17:42 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) 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> <507B0C57.7030506@incore.de> In-Reply-To: Content-Type: text/plain; charset=US-ASCII 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: Mon, 15 Oct 2012 21:17:51 -0000 Hi, > as I said, I think 672 is a bit low, though I used 4096 for NetBSD (with a > sysctl for runtime adjustment if necessary) and that is still potentially > prone to error with larger packets (L2CAP MTU between 48-65535 bytes is > valid) so I guess that requiring the application to set the buffer size is > best practice.. I agree. >> 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. > > does the ARP request get sent out? Yes and the arp answer comes in. >> I did nothing special with the tap interface, it is included in my >> "cloned_interfaces" in rc.conf and opened by btpand. >> >> Any ideas ? > > No, I confess. My problem was a phantom ! It seems to be normal behavior in any network and has nothing to do with btpand or tap interface. This was a little bit suprising to me but I have checked this on several networks. An explanation for this was given on freebsd-net some years ago titled Lost fragment when send to ip that need arp resolve. Thanks again for help! Andreas Longwitz