From owner-freebsd-bluetooth@FreeBSD.ORG Sun Oct 14 08:02:30 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 7E0C82D1 for ; Sun, 14 Oct 2012 08:02:30 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtpout.wanadoo.co.uk (smtpout3.wanadoo.co.uk [80.12.242.59]) by mx1.freebsd.org (Postfix) with ESMTP id E8A918FC14 for ; Sun, 14 Oct 2012 08:02:28 +0000 (UTC) Received: from galant.ukfsn.org ([109.249.238.94]) by mwinf5d37 with ME id Avum1k00622ti8l03vunTQ; Sun, 14 Oct 2012 09:54:51 +0200 Received: by galant.ukfsn.org (Postfix, from userid 1000) id 652E92600A0; Sun, 14 Oct 2012 08:55:33 +0100 (BST) Date: Sun, 14 Oct 2012 08:55:33 +0100 (BST) From: Iain Hibbert To: Andreas Longwitz Subject: Re: btpand problem In-Reply-To: <5079E8F7.5050903@incore.de> Message-ID: References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> <5079E8F7.5050903@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: Sun, 14 Oct 2012 08:02:30 -0000 On Sun, 14 Oct 2012, Andreas Longwitz wrote: > 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. Ah well IMO that default should be changed upwards slightly, since 672 is rather small for a buffer size.. 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 iain From owner-freebsd-bluetooth@FreeBSD.ORG Sun Oct 14 08:18:26 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 DF11C787 for ; Sun, 14 Oct 2012 08:18:26 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtpout.wanadoo.co.uk (smtpout3.wanadoo.co.uk [80.12.242.59]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFE48FC08 for ; Sun, 14 Oct 2012 08:18:25 +0000 (UTC) Received: from galant.ukfsn.org ([109.249.238.94]) by mwinf5d37 with ME id AwJP1k00922ti8l03wJPe3; Sun, 14 Oct 2012 10:18:24 +0200 Received: by galant.ukfsn.org (Postfix, from userid 1000) id 25A112600A0; Sun, 14 Oct 2012 09:19:11 +0100 (BST) Date: Sun, 14 Oct 2012 09:19:11 +0100 (BST) From: Iain Hibbert To: Andreas Longwitz Subject: Re: btpand problem In-Reply-To: Message-ID: References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> <5079E8F7.5050903@incore.de> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1863111016-1350202751=:673" 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 08:18:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1863111016-1350202751=:673 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 14 Oct 2012, Iain Hibbert wrote: > 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 regards, iain --0-1863111016-1350202751=:673 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ensure buffers are large enough Content-Disposition: attachment; filename=diff SW5kZXg6IGNsaWVudC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2J0cGFu ZC9jbGllbnQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAt dSAtcCAtcjEuMSBjbGllbnQuYw0KLS0tIGNsaWVudC5jCTMwIEphbiAyMDA5 IDIyOjIzOjIxIC0wMDAwCTEuMQ0KKysrIGNsaWVudC5jCTE0IE9jdCAyMDEy IDA4OjE1OjUwIC0wMDAwDQpAQCAtNDcsNyArNDcsNyBAQCBjbGllbnRfaW5p dCh2b2lkKQ0KIAlzdHJ1Y3Qgc29ja2FkZHJfbDJjYXAgc2E7DQogCWNoYW5u ZWxfdCAqY2hhbjsNCiAJc29ja2xlbl90IGxlbjsNCi0JaW50IGZkOw0KKwlp bnQgZmQsIG47DQogCXVpbnQxNl90IG1ydSwgbXR1Ow0KIA0KIAlpZiAoYmRh ZGRyX2FueSgmcmVtb3RlX2JkYWRkcikpDQpAQCAtOTcsNiArOTcsMTcgQEAg Y2xpZW50X2luaXQodm9pZCkNCiAJCWV4aXQoRVhJVF9GQUlMVVJFKTsNCiAJ fQ0KIA0KKwlsZW4gPSBzaXplb2Yobik7DQorCWlmIChnZXRzb2Nrb3B0KGZk LCBTT0xfU09DS0VULCBTT19SQ1ZCVUYsICZuLCAmbGVuKSA9PSAtMSkgew0K KwkJbG9nX2VycigiQ291bGQgbm90IHJlYWQgU09fUkNWQlVGIik7DQorCQll eGl0KEVYSVRfRkFJTFVSRSk7DQorCX0NCisJaWYgKG4gPCAobXJ1ICogMTAp KSB7DQorCQluID0gbXJ1ICogMTA7DQorCQlpZiAoc2V0c29ja29wdChmZCwg U09MX1NPQ0tFVCwgU09fUkNWQlVGLCAmbiwgc2l6ZW9mKG4pKSA9PSAtMSkN CisJCQlsb2dfaW5mbygiQ291bGQgbm90IGluY3JlYXNlIFNPX1JDVkJVRiAo ZnJvbSAlZCkiLCBuKTsNCisJfQ0KKw0KIAlsZW4gPSBzaXplb2YobXR1KTsN CiAJaWYgKGdldHNvY2tvcHQoZmQsIFNPTF9MMkNBUCwgU09fTDJDQVBfT01U VSwgJm10dSwgJmxlbikgPT0gLTEpIHsNCiAJCWxvZ19lcnIoIkNvdWxkIG5v dCBnZXQgTDJDQVAgT01UVTogJW0iKTsNCkBAIC0xMDcsNiArMTE4LDI3IEBA IGNsaWVudF9pbml0KHZvaWQpDQogCQlleGl0KEVYSVRfRkFJTFVSRSk7DQog CX0NCiANCisJbGVuID0gc2l6ZW9mKG4pOw0KKwlpZiAoZ2V0c29ja29wdChm ZCwgU09MX1NPQ0tFVCwgU09fU05EQlVGLCAmbiwgJmxlbikgPT0gLTEpIHsN CisJCWxvZ19lcnIoIkNvdWxkIG5vdCBnZXQgc29ja2V0IHNlbmQgYnVmZmVy IHNpemU6ICVtIik7DQorCQljbG9zZShmZCk7DQorCQlyZXR1cm47DQorCX0N CisJaWYgKG4gPCAobXR1ICogMikpIHsNCisJCW4gPSBtdHUgKiAyOw0KKwkJ aWYgKHNldHNvY2tvcHQoZmQsIFNPTF9TT0NLRVQsIFNPX1NOREJVRiwgJm4s IHNpemVvZihuKSkgPT0gLTEpIHsNCisJCQlsb2dfZXJyKCJDb3VsZCBub3Qg c2V0IHNvY2tldCBzZW5kIGJ1ZmZlciBzaXplICglZCk6ICVtIiwgbik7DQor CQkJY2xvc2UoZmQpOw0KKwkJCXJldHVybjsNCisJCX0NCisJfQ0KKwluID0g bXR1Ow0KKwlpZiAoc2V0c29ja29wdChmZCwgU09MX1NPQ0tFVCwgU09fU05E TE9XQVQsICZuLCBzaXplb2YobikpID09IC0xKSB7DQorCQlsb2dfZXJyKCJD b3VsZCBub3Qgc2V0IHNvY2tldCBsb3cgd2F0ZXIgbWFyayAoJWQpOiAlbSIs IG4pOw0KKwkJY2xvc2UoZmQpOw0KKwkJcmV0dXJuOw0KKwl9DQorDQogCWNo YW4gPSBjaGFubmVsX2FsbG9jKCk7DQogCWlmIChjaGFuID09IE5VTEwpDQog CQlleGl0KEVYSVRfRkFJTFVSRSk7DQpJbmRleDogc2VydmVyLmMNCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy91 c3Iuc2Jpbi9ibHVldG9vdGgvYnRwYW5kL3NlcnZlci5jLHYNCnJldHJpZXZp bmcgcmV2aXNpb24gMS4yDQpkaWZmIC11IC1wIC1yMS4yIHNlcnZlci5jDQot LS0gc2VydmVyLmMJMiBGZWIgMjAwOSAxODowODoyMiAtMDAwMAkxLjINCisr KyBzZXJ2ZXIuYwkxNCBPY3QgMjAxMiAwODoxNTo1MSAtMDAwMA0KQEAgLTE3 Nyw2ICsxNzcsMTggQEAgc2VydmVyX3JlYWQoaW50IHMsIHNob3J0IGV2LCB2 b2lkICphcmcpDQogCQlyZXR1cm47DQogCX0NCiANCisJbGVuID0gc2l6ZW9m KG4pOw0KKwlpZiAoZ2V0c29ja29wdChmZCwgU09MX1NPQ0tFVCwgU09fUkNW QlVGLCAmbiwgJmxlbikgPT0gLTEpIHsNCisJCWxvZ19lcnIoIkNvdWxkIG5v dCByZWFkIFNPX1JDVkJVRiIpOw0KKwkJY2xvc2UoZmQpOw0KKwkJcmV0dXJu Ow0KKwl9DQorCWlmIChuIDwgKG1ydSAqIDEwKSkgew0KKwkJbiA9IG1ydSAq IDEwOw0KKwkJaWYgKHNldHNvY2tvcHQoZmQsIFNPTF9TT0NLRVQsIFNPX1JD VkJVRiwgJm4sIHNpemVvZihuKSkgPT0gLTEpDQorCQkJbG9nX2luZm8oIkNv dWxkIG5vdCBpbmNyZWFzZSBTT19SQ1ZCVUYgKGZyb20gJWQpIiwgbik7DQor CX0NCisNCiAJbGVuID0gc2l6ZW9mKG10dSk7DQogCWlmIChnZXRzb2Nrb3B0 KGZkLCBTT0xfTDJDQVAsIFNPX0wyQ0FQX09NVFUsICZtdHUsICZsZW4pID09 IC0xKSB7DQogCQlsb2dfZXJyKCJDb3VsZCBub3QgZ2V0IEwyQ0FQIE9NVFU6 ICVtIik7DQo= --0-1863111016-1350202751=:673-- 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 From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 15 09:25:25 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 B7062296 for ; Mon, 15 Oct 2012 09:25:25 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtpout.wanadoo.co.uk (smtpout3.wanadoo.co.uk [80.12.242.59]) by mx1.freebsd.org (Postfix) with ESMTP id 2CB8D8FC0C for ; Mon, 15 Oct 2012 09:25:24 +0000 (UTC) Received: from galant.ukfsn.org ([109.249.107.220]) by mwinf5d44 with ME id BMRD1k0034lLfvR03MRD7v; Mon, 15 Oct 2012 11:25:17 +0200 Received: by galant.ukfsn.org (Postfix, from userid 1000) id F27B12600A0; Mon, 15 Oct 2012 10:16:15 +0100 (BST) Date: Mon, 15 Oct 2012 10:16:15 +0100 (BST) From: Iain Hibbert To: Andreas Longwitz Subject: Re: btpand problem In-Reply-To: <507B0C57.7030506@incore.de> Message-ID: References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> <5079E8F7.5050903@incore.de> <507B0C57.7030506@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: Mon, 15 Oct 2012 09:25:25 -0000 On Sun, 14 Oct 2012, Andreas Longwitz wrote: > 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. 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.. > 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? > 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.. I am not a networking expert :) btpand does change the address on the tap, so in the first instance the address will be unknown to the rest of the kernel I guess.. should it generate a notification of the address change somehow? iain 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 From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 18 16:36:01 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 57D5912E for ; Thu, 18 Oct 2012 16:36:01 +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 20CBB8FC08 for ; Thu, 18 Oct 2012 16:36:01 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so9190673pbb.13 for ; Thu, 18 Oct 2012 09:36:00 -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=OAJOoZt7gaVS8inkrK5NYzgKoggrTP29jsDRw4cpPj4=; b=Ud9NEciO+H+bxgmR9yoKl+UCBfABLlP5FQDFc4j3ntYUs1QYFyASil11B3GFSsdSoM FC1w4/WLjoNDEhRenv0m0E6HzO42DeXvjqqSu/cKSfP8+BmFigDLbSil07jeS9T5aDRl edoIWDbHHdzlF2pTeb4LUsNKJS5ijsEwcDyz15XWJz5u9E5z9vw33kHBxYjQFjGjcYAT GuSIfaKMd/flNbh13sWMP63mI+tsBMxKl2w6XfOgMrp79zN5FFDuJi97xDJjP+FuYQsF IOzn7JI+iy9SGHOsrWknfPBPC/07ybO1j0GvF2kpwNZJznaF3MxTdZAQr4sGhthdOjta dJhQ== MIME-Version: 1.0 Received: by 10.68.222.37 with SMTP id qj5mr66874914pbc.132.1350578160635; Thu, 18 Oct 2012 09:36:00 -0700 (PDT) Received: by 10.68.240.38 with HTTP; Thu, 18 Oct 2012 09:36:00 -0700 (PDT) In-Reply-To: <507C7D76.4090303@incore.de> References: <507736A8.4050605@incore.de> <5077490F.7010901@incore.de> <50782E05.5080005@incore.de> <5079E8F7.5050903@incore.de> <507B0C57.7030506@incore.de> <507C7D76.4090303@incore.de> Date: Thu, 18 Oct 2012 09:36:00 -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, 18 Oct 2012 16:36:01 -0000 On Mon, Oct 15, 2012 at 2:17 PM, Andreas Longwitz wrote: > 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! just in case Author: emax Date: Thu Oct 18 16:34:00 2012 New Revision: 241699 URL: http://svn.freebsd.org/changeset/base/241699 Log: make sure that socket's send and receive buffers are properly sized Submitted by: Iain Hibbert plunky at rya-online dot net MFC after: 3 weeks Modified: head/usr.sbin/bluetooth/btpand/client.c head/usr.sbin/bluetooth/btpand/server.c thanks max