Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Oct 2012 10:16:15 +0100 (BST)
From:      Iain Hibbert <plunky@rya-online.net>
To:        Andreas Longwitz <longwitz@incore.de>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: btpand problem
Message-ID:  <alpine.NEB.2.00.1210150936490.753@galant.ukfsn.org>
In-Reply-To: <507B0C57.7030506@incore.de>
References:  <507736A8.4050605@incore.de> <BDA3CA14-92C0-414E-9D55-E96EA7A73312@gmail.com> <5077490F.7010901@incore.de> <CAFPOs6pF51wy9PvKLn4-OnrOqo8hU1S=P5PzTFwgUppBjqAtuA@mail.gmail.com> <alpine.NEB.2.00.1210120949170.628@galant.ukfsn.org> <50782E05.5080005@incore.de> <alpine.NEB.2.00.1210122254010.965@galant.ukfsn.org> <CAFPOs6qWVAcSuPz6%2BB=3uq_KqCXa=YcXwx-PNncGVrbDE8AimQ@mail.gmail.com> <5079E8F7.5050903@incore.de> <alpine.NEB.2.00.1210140843330.548@galant.ukfsn.org> <alpine.NEB.2.00.1210140917360.673@galant.ukfsn.org> <507B0C57.7030506@incore.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.NEB.2.00.1210150936490.753>